From: Jeremy Maitin-Shepard (jbms_at_[hidden])
Date: 2003-11-29 20:38:12
Walter Landry <wlandry_at_[hidden]> writes:
> Jeremy Maitin-Shepard <jbms_at_[hidden]> wrote:
>> Walter Landry <wlandry_at_[hidden]> writes:
>> > Right. Not thinking straight. Having an is_symbolic_link() function
>> > is certainly still required. However, I think that my proposed syntax
>> > would resolve the problem of whether a particular function should
>> > resolve symlinks or not.
>> As additional property functions (like last_write_time) are added, it
>> will be necessary to add such checks to each function. Furthermore, I
>> think the resultant syntax is much less clear than the syntax I
>> proposed, namely, a "dereference" or "resolve" function (or operator).
>> At least to me, exists(*ph) or exists(resolve(ph)) or
>> exists(dereference(ph)) is _much_ clearer than exists(ph, true),
>> and similarly, last_write_time(*ph) or last_write_time(resolve(ph))
>> than last_write_time(ph, true).
> 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.
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. And if exists has
different defaults from other query functions, it will also be
> As for the choice of names, we could make an enum or typedef with
> whatever name you like. Then we could have something like
This works, but the syntax still seems a lot more awkward than the
syntax I suggested. 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.
If the dereference function, when applied to a non-symbolic link, is
just the identity function, it wouldn't be particularly difficult to
-- Jeremy Maitin-Shepard
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk