Re: [boost] Filesystem: remove_all should not follow symlinks

From: Jeremy Maitin-Shepard (jbms_at_[hidden])
Date: 2003-11-26 14:43:23

"Victor A. Wagner, Jr." <vawjr_at_[hidden]> writes:

> I believe we have exactly the same situation here.  We're worried about the
> exact semantics of how *nix does things (about which _I_ couldn't give a flying
> <insert 3rd favorite expletive here>).  I really don't.  I want the ability to
> say to the filesystem: "in the future when someone says "blahblah" you should
> instead refer to "halbhalb" ".  And it shouldn't matter whether I'm talking
> files or directories or volumes or whatever.
> I don't care if we use hardlinks, softlinks, reparsepoints, or what.  It would
> be NICE (very nice) if after we do this, the OS believed the alias as well, and
> that other programs attempting to use files and directories would accept our
> fictions as reality also.

It is necessary to make a distinction between hard links and symbolic
links because they do not work the same way; it is not merely a matter
of "implementation" or "internal representation."  If you hard link A to
an existing link/file B, then move or remove B, A will still be valid.
If you symbolically link A to an existing link/file B, then move or
remove B, A will not be valid.  Furthermore, if you hard link A to B,
then remove B and create a new file at that location, A will continue to
refer to the data of the old B, while if a symbolic link were used, it
would refer to the new file.  Symbolic links have the advantage that
they can refer to files or directories that are on a different
filesystem, while hard links can only be between files on the same
filesystem.  Also, in writing various types of software, specifically
backup software, it is useful to be able to obtain the link count for a
file (as well as the inode number, but that is another issue).  Clearly,
if the boost filesystem library attempts to blur the distinction between
hard links and symbolic links, not only will it lead to confusion, but
it will simply not be usable in certain applications.

On Windows NT, since it is only possible to create symbolic links
("junctions") between directories, and only possible to create hard
links between files, a single function would suffice.  POSIX
implementations, however, allow symbolic links between files, and
possibly allow hard links between directories.  Thus, a single function
would not suffice for POSIX platforms, and thus linking functionality
in a boost filesystem library that did not make the distinction between
hard links and symbolic links would be rather useless.

-- 
Jeremy Maitin-Shepard