iesdp project data should not contain symbolic links

[Argent77]

https://github.com/Gibberlings3/iesdp/blob/master/_data/file_formats/spl_v1/feature_block.yml is currently stored as a symbolic link.

Symlinks are handled badly on Windows platforms and may cause issues when performing operations that directly or indirectly involve these files. I'd recommend to turn it into a regular file.

[lynxlynxlynx]

Then we'd have to maintain two identical files, which sounds silly and is probably the reason why @burner1024 chose this approach.

Is this a hypothetical problem?

Git can handle this properly, so I don't see a big issue. On a filesystem with no support, the link file will have different content, so it will be obviously wrong to edit.

[Argent77]

Is this a hypothetical problem?

It's a real problem (although it probably doesn't occur very often).

Windows doesn't preserve links on copy operations or move operations across partition boundaries, and will be automatically turned into regular files. In my case it happened when I moved the local repo to another drive because of a disk upgrade.

Also from what I've read, symlink support for git on Window must be explicitly enabled or symlinks will be turned into special text files (which apparently could cause issues with some git clients).

[lynxlynxlynx]

I'm surprised you actually had a link, as the docs make it sound quite unlikely. But anyway, I think the occasional pain for contributors on windows is the lesser evil. YAML doesn't provide any inclusion mechanism either.

[rubyFeedback]

Is this a hypothetical problem?

I am using mostly Linux, but when I copy data from Linux to Windows, Windows causes issues.

For instance, I once had a symlink from a directory called C++ or so, called c++ or c (the symlink
I think was c++, lower case). I then could not copy the directory onto windows because windows
automatically claimed that symlink was a system file (which was clearly wrong). So I had to change
my scripts to delete symlinks, because windows is really bad at handling symlinks.

I am mentioning this just as an example - windows is really a pain in regards to symlinks (and
in general, anyway; things that are trivial on Linux are hard or impossible on Windows).

On a filesystem with no support, the link file will have different content, so it will be obviously
wrong to edit.

This assumes that windows silently ignores it. But as my example showed of a symlink called
c++, windows simply assumes things that are often, in my opinion, wrong. It may not be a
issue that affects many people, but it is indeed the case so that windows is handling symlinks
badly.