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

From: Beman Dawes (bdawes_at_[hidden])
Date: 2003-11-24 20:06:27

At 06:07 PM 11/24/2003, Jeremy Maitin-Shepard wrote:
 >"Victor A. Wagner, Jr." <vawjr_at_[hidden]> writes:
 >
 >> There _is_ a mechanism for creating hard links to directories on 
NTFS.  I
 >don't
 >> know what the relevant runtime calls are, but I have a utility that
 >creates
 >> them.  When you do a dir on a directory which has some they show up as
 >> <JUNCTION> instead of <DIR> see following:
 >[snip]
 >
 >My understanding is that junctions are effectively symbolic links,
 >rather than hard links.

My understanding is that junctions aren't hard links. I don't know enough 
about them to have an opinion as to how close they are to the POSIX 
symlink.

 >As far as dealing with symlinks, the most consistent way to deal with
 >them might be for size, last_write_time, etc. to operate on the symlink
 >file directly, rather than on the file to which it points.  In order to
 >operate on the file to which it points, the symlink would have to be
 >dereferenced (either using a function, such as "dereference" or
 >"resolve," or an overloaded operator *).  Although this syntax might be
 >more consistent, the problem with it is that the more common operation
 >is to access the file to which the symlink points, and this operation
 >would be more verbose.
 >
 >This dereference operation could return the path to which the symlink
 >points, or a proxy object that could possibly allow for more efficient
 >operations.  Furthermore, as a convenience, this dereference operation
 >could be applied to a non-symlink path, in which case it would just act
 >as the identity function.
 >
 >An additional operator that returned the contents of the symlink (rather
 >than the resultant path).  Specifically, a symlink at /bar/foo/baz that
 >points to /bar/foo/foobar would dereference to /bar/foo/foobar, but the
 >operation that returns the contents of the symlink might return just
 >"foobar".  If the symlink pointed to an absolute path, (which it always
 >would on Windows) this operation would be equivalent to the dereference
 >operation.  A name such as "resolve_relative" or "dereference_relative"
 >could be given to such an operation.
 >
 >One rationale for providing symlink functionality, despite the
 >complexity, is that it would allow for the creation of a more preserving
 >"copy_directory" function.  (Of course, permissions and other attributes
 >are a separate matter).
 >

Explicit dereferencing would be awfully cumbersome. People using O/S's 
which natively support symbolic links would likely view it as a giant step 
backward for them. Plus there would be interoperability problems - programs 
using Boost.Filesystem wouldn't work the way other programs worked.

 >On an unrelated note, perhaps this has already been discussed, but
 >remove_recursive seems like a better name than remove_all.  Also
 >current_directory and initial_directory seem like better names than
 >current_path and initial_path.

Those were the original names. But then someone pointed out that these 
functions return full paths, not just a single directory!

--Beman