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

From: Jeremy Maitin-Shepard (jbms_at_[hidden])
Date: 2003-11-24 18:07:41

"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.  Indeed, boost filesystem could support the
creation of them (as symlinks).  One caveat is that only "absolute"
symlinks of this type are supported (and they are only supported for
directories).

As far as supporting the creation of hard links and getting the link
count, I would desire such functionality in boost.filesystem.

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).

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.

-- 
Jeremy Maitin-Shepard