On Fri, Dec 4, 2009 at 2:58 AM, OvermindDL1 <overminddl1@gmail.com> wrote:
I think the primary concern is that while the filesystem might support hard or soft links now, existing programs do not, and presumably, if somebody's backup -- or another other -- program chokes on Boost, user will blame us. However, I don't use Windows enough to be able to decide. I'm happy to implement whatever the concensus here might be.
I don't think backup programs need to do anything special for symbolic links. Worst case scenario, when backing up the (buggy) program simply opens the file and reads data from it, and backups up that data. So it backups up the full data twice. Then when restoring the file it didn't know it was a symlink so it makes a copy on restore. The biggest danger in not checking whether something is a link or regular file is on deletion. But for symbolic links, when you delete a file through standard APIs it deletes the link and not the target. You actually have to *try* to delete the target if that's what you want. Junctions can be problematic in Windows if you're not careful, but those are only for directories, and we aren't worried about those for the sake of this, just file symlinks.
I would certainly be up for hard links (I use them heavily already elsewhere and have never seen an odd issue yet), they work on Win2k and up at least. Hard links on windows require NTFS (who isn't...) and have two file descriptors that point to the same data chunk. Every program that does not specifically know how to look for hard links just thinks they are two separate files with no relation.
Hard links are an alternative that I wouldn't be too unhappy with. The only weirdness with hard links is that it's not obvious by looking at the size of something that it's a hard link, so an unknowing user would look at the two files and think it's still taking up twice as much space as necessary. Personally, I'd suggest symlinks on Vista+ and hard links on XP- Zach