On 4/12/2013 16:32, Quoth Edward Diener:
Would symlinks even solve that issue? I could be wrong, but I would think that a tool or editor that followed the delete-move pattern would break symlinks just as easily as hardlinks, unless they explicitly followed the symlink to the "real" file and used that path in the delete-move. (And at least on Windows, most programs are not symlink-aware, partly because links are fairly rare.)
The delete-move pattern does not break symlinks. Since a symlink is only a pointer to another full file name, as long as the name remains the same after the delete-move the symlink still works correctly.
I was thinking of edits in the location where the symlinks appear to be, not where they point to. Possibly this isn't the scenario that people are most worried about though.
Although it's true that symlinks are more obvious as such, so that might possibly encourage people to edit the "real" file instead of the linked version.
The grammar above is confusing. If you edit the file by specifying the symlink location you are editing the "real" file.
AFAIK, if a symlink-unaware editor/script issues an "rm path-user-entered" (or equivalent API as part of a semi-atomic replace) then that will delete the symlink if that happens to be what is actually at the path-user-entered. It will not follow the symlink and delete the "real" file, and so they'll be left with duplicate unlinked files again. It's only safe if the path-user-entered is the "real" (target) path, not the symlink (or if the editor itself or something between the user and the editor follows the symlink first). And hardlinks are not safe either way around. That's what I was referring to above.
Let's get Modular Boost working correctly for programmers now by replacing the "b2 headers" command with one that uses symlinks rather than hardlinks. Then if we want to consider header file placement we can do that as a further chore in the future.
Definitely. Making "b2 headers" create symlinks is still probably the best option, as that will defend against git updates and *most* user edits. It won't help if users are editing the files directly in boost/ (using something that uses the delete-move pattern) but that should be the less common case and there probably isn't much that can be done about that short of retraining.