symbolic links while building boost
I use Windows primarily, and typically after building boost, there are two copies of each library. One with the version extension such as -1_41, and the other without. My understanding is that the one without the version number is supposed to be a symlink to the one with the version number on platforms such as linux, but that on Windows it is just a copy of the file due to poor support for symlinks in windows. My question is whether there has been any talk of changing this. Windows has supported first class symlinks since Vista, so it would seem possible to have Vista and beyond actually use this functionality and create real symlinks. Thoughts? Zach
Zachary Turner wrote:
I use Windows primarily, and typically after building boost, there are two copies of each library. One with the version extension such as -1_41, and the other without. My understanding is that the one without the version number is supposed to be a symlink to the one with the version number on platforms such as linux, but that on Windows it is just a copy of the file due to poor support for symlinks in windows.
My question is whether there has been any talk of changing this. Windows has supported first class symlinks since Vista, so it would seem possible to have Vista and beyond actually use this functionality and create real symlinks.
Zachary, there was no talk about this. Somebody previously suggested using hard links on NTFS, if available, but that did not lead anywhere. 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. - Volodya
On Fri, Dec 4, 2009 at 12:42 AM, Vladimir Prus <vladimir@codesourcery.com> wrote:
Zachary Turner wrote:
I use Windows primarily, and typically after building boost, there are two copies of each library. One with the version extension such as -1_41, and the other without. My understanding is that the one without the version number is supposed to be a symlink to the one with the version number on platforms such as linux, but that on Windows it is just a copy of the file due to poor support for symlinks in windows.
My question is whether there has been any talk of changing this. Windows has supported first class symlinks since Vista, so it would seem possible to have Vista and beyond actually use this functionality and create real symlinks.
Zachary,
there was no talk about this. Somebody previously suggested using hard links on NTFS, if available, but that did not lead anywhere.
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 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.
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
participants (3)
-
OvermindDL1 -
Vladimir Prus -
Zachary Turner