search

Gibberlings3 / iesdp

Jekyllized version of IESDP with imported history
https://gibberlings3.github.io/iesdp/
19 stars 22 forks source link

iesdp project data should not contain symbolic links #160

Open Argent77 opened 1 year ago

Argent77 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 9 months ago

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.