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

From: Victor A. Wagner, Jr. (vawjr_at_[hidden])
Date: 2003-11-24 19:05:07

I don't know what understanding you have, but here's from the horse's 
mouth: (I've always felt the hard/soft link names were somewhat 
problematic).  I do know these "work" and that find_first and find_next 
tell you the things found are directories (i.e. all of my treewalk 
utilities work with them).

Hard Links and Junctions

A hard link is the file system representation of a file by which more than 
one path references a single file in the same volume. Many changes to that 
file are instantly visible to applications that access it through the hard 
links that reference it. However, the directory entry size and attribute 
information is updated only for the link through which the change was made.

For example, in a system with the C: and D: drives defined and the \\fred 
share mapped to Z: the following reference is permitted as a hard link.

    * C:\dira\ethel.txt linked to C:\dirb\dirc\lucy.txt

The following are not:

    * C:\dira linked to c:\dirb
    * C:\dira\ethel.txt linked to D:\dirb\lucy.txt

A junction(also called a soft link) differs from a hard link in that the 
storage objects it references are separate directories, and a junction can 
link directories located on different local volumes on the same computer. 
Otherwise, junctions operate identically to hard links.

Given the conditions in the example above, the following references are 
permitted as junctions:

    * C:\dira linked to C:\dirb\dirc
    * C:\dirx linked to D:\diry

The following are not:

    * C:\dira\one.txt linked to C:\dirb\two.txt
    * C:\dir1 linked to Z:\dir2

At Monday 2003-11-24 16:07, you 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.  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
>_______________________________________________
>Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Victor A. Wagner Jr.      http://rudbek.com
The five most dangerous words in the English language:
               "There oughta be a law"