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

From: Walter Landry (wlandry_at_[hidden])
Date: 2003-11-30 23:11:57

Jeremy Maitin-Shepard <jbms_at_[hidden]> wrote:
> Walter Landry <wlandry_at_[hidden]> writes:
> 
> > Jeremy Maitin-Shepard <jbms_at_[hidden]> wrote:
> >> Walter Landry <wlandry_at_[hidden]> writes:
> > The default should be to resolve symlinks, much like POSIX stat.
> > Since it is mostly POSIX programmers who are going to have to deal
> > with symlinks, it is best not to make defaults gratuitously different.
> 
> But other POSIX calls (and other functions in the boost filesystem
> library) don't resolve symlinks, such as remove, rename.

Actually, the boost filesystem library always calls stat() instead of
lstat().  The only time it doesn't resolve symlinks is when it punts
to ANSI C functions like remove and rename.

Also, looking at the mail you just posted for hard link support, you
decided to resolve symbolic links.  equivalent(), for example, needs
to be modified to account for symbolic links.

> I think it is clear that exists(ph) returning false if ph is a symlink
> that points to a non-existent file will be confusing.

That is what stat() returns.  For people dealing with filesystems with
symbolic links, it isn't that confusing.

> And if exists has different defaults from other query functions, it
> will also be confusing.

If we're just talking about query functions, then there can be no
argument.  In Unix, stat() and lstat() give all of the information
about files.

> > As for the choice of names, we could make an enum or typedef with
> > whatever name you like.  Then we could have something like
> 
> >   last_write_time(ph,dont_resolve)
> 
> This works, but the syntax still seems a lot more awkward than the
> syntax I suggested.

I think that my syntax is less awkward.  It even uses one less
character (not that that really matters).

> Also, I don't like the idea that the syntax is less uniform and each
> of these query functions have to be modified to deal with symbolic
> links.

I'm not sure what you mean by "less uniform".  In any case, modifying
these query functions is going to have to happen anyway.  Whether it
is in the function or elsewhere.

> If the dereference function, when applied to a non-symbolic link, is
> just the identity function, it wouldn't be particularly difficult to
> use.

It makes the whole function less transparent.  With the extra default
argument, I can guess what is going on without even looking at the
function definition.  With your syntax, I am tempted to look up the
definition of dereference().

Regards,
Walter Landry
wlandry_at_[hidden]