Re: [boost] Hard link support for boost.filesystem

From: Beman Dawes (bdawes_at_[hidden])
Date: 2003-12-01 12:47:05

At 02:02 AM 11/30/2003, Jeremy Maitin-Shepard wrote:

 >I wrote some code to show how hard link support could be added to the
 >boost.filesystem library.  It is included in the attached patches.
 >
 >The patches add three functions to operations.hpp and
 >operations_posix_windows.cpp:
 >
 >bool equivalent(path const &lhs, path const &rhs);
 >
 >Tests if the two arguments refer to the same file.  This is useful even
 >outside the context of hard links, since it avoids the problem of
 >having to compare paths syntactically.  Throws if either of the paths
 >does not exist or is inaccessible.

My understanding, based on posts to 
microsoft.public.win32.programmer.kernel, is that there is no way on 
Windows to implement this function such that it will work reliably. The 
dwVolumeSerialNumber/nFileIndexHigh/nFileIndexLow technique you use was 
specifically mentioned as unreliable. I forget the exact case, but it was 
something like network files, non-NTFS file systems, or perhaps the 
combination of both.

I'd love to be proved wrong about that. If you have your code running on 
Windows, could you give it a try to say a floppy or CD-ROM across a network 
share? I'm concerned that one or more of the dwVolumeSerialNumber, 
nFileIndexHigh, or nFileIndexLow members aren't filled in properly.

 >unsigned int link_count(path const &ph);
 >
 >Returns the number of hard links to the file specified by the
 >argument.  (On platforms that do not support hard linking, this always
 >returns 1.)  Throws if the path does not exist or is inaccessible.

What are some use cases for this function? Do they degrade gracefully on 
platforms which don't support hard linking? Do they degrade gracefully on 
platforms which support hard linking on some file systems and not others?

 >void link(path const &existing_path, path const &new_path);
 >
 >Creates a hard link from `new_path' to the file referred to by
 >`existing_path'.  Throws if `existing_path' does not exist, if
 >`new_path' does exist, or if the operation fails for any of a variety
 >of reasons.

There are many platforms and file systems which don't support hard linking. 
Windows doesn't every support hard links for directories, IIRC, and even 
POSIX doesn't require support, again IIRC. Thus I've got serious concerns 
about supplying something that is very likely to not be portable. I 
considered limiting the hard links to files (and not directories). But it 
seems a tricky feature with only mildly compelling uses.

 >Note that the code in the attached patches has not been tested on
 >Windows, and due to the use of CreateHardLink, it may be the case that
 >it does not compile or run on versions of Windows older than Windows
 >2000.

Or file systems other than NTFS even on modern Windows?

 >It would be convenient if there were a way to provide a unique
 >identifier for a file, for use in an associative container.
 >Unfortunately, although Windows does provide a 64-bit identifier for a
 >file, the documentation indicates that these identifiers are only valid
 >while there is an open handle to the file.  I suppose it would be
 >possible to keep an open handle to the file as part of the identifier,
 >but such a system seems highly resource intensive.

While it would be nice, I don't think such a feature would be worthwhile 
unless it worked portably across a very wide spectrum of operating systems 
and file systems.

If we had some way to force operating systems and file systems to provide 
the features we would like, then Boost.Filesystem would quickly acquire a 
long list of additional functionality. But in the real world that isn't 
possible. The practical threshold in my mind is POSIX + Windows. If some 
potentially useful feature can be implemented such that it's behavior is 
portable to those two operating systems and their common file systems, I'm 
willing to add it. But if portable behavior between POSIX and Windows isn't 
possible, I think such functionality is highly questionable unless there is 
a safe fall-back implementation.

--Beman