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
>> know what the relevant runtime calls are, but I have a utility that
>> them. When you do a dir on a directory which has some they show up as
>> <JUNCTION> instead of <DIR> see following:
>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
>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!
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk