Boost logo

Boost :

Subject: Re: [boost] [filesystem] proposal: treat reparse files as regular files
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2015-08-03 00:38:10

On 3/08/2015 13:43, Niall Douglas wrote:
> On 3 Aug 2015 at 11:28, Gavin Lambert wrote:
>>> Actually no - AFIO can only read the target for reparse points it
>>> knows about.
>>> I committed a fix for this earlier today. It reports reparse points
>>> symlinks. Everything else is reported normally.
>> Granted I'm not familiar with AFIO's APIs,
> There is a single page "cheat sheet" at

It would be nice if this included hyperlinks for the local types. I
have no idea what a directory_entry looks like.

(And even after manually navigating around the docs until I found,
I still have no idea what those fields actually *mean*. Only because
you mentioned it below did I also find,
which is more descriptive. Although I later went back and noticed I
overlooked fetch_lstat on directory_entry. Another case where
hyperlinks would have been nice.)

>> but wouldn't it make the most
>> sense to report other name surrogates as symlinks as well (via an "is
>> this a symlink" or "get file type" method), but then if queried for the
>> target of an unknown symlink type it will return/throw a "not supported"
>> error?

Using the above vocabulary, it seems to me that:

   - enumerate() / lstat() should be able to report all name surrogates
as symlinks, however that is currently done (presumably via st_type ==
symlink_file). Other reparse types should be reported as regular

   - symlink() should be able to open unknown symlinks (since that's
just a flag to CreateFile).

   - rmsymlink() should be able to delete unknown symlinks.

   - target() should work for the known symlink types and fail "not
supported" (or similar) for the other name surrogate types, and fail
"invalid operation" (or similar) for any non-reparse file or
non-name-surrogate type.

Does that sound reasonable?

I suppose another variant on this would be to report known-type symlinks
as st_type == symlink_file, unknown-type name surrogates as st_type ==
type_unknown, and any other reparse point as st_type ==
regular_file/directory_file. This would have the advantage of hinting
whether target() is likely to work, but the disadvantage of being a bit

(On a peripherally related note, it seems odd that Boost.Filesystem's
file_type appears to lack a way to express "a symlink to a directory",
which should be opened as a directory instead of as a file. Is this a
POSIX limitation, that you're required to inspect the target to
determine whether it's a file or directory? I know that Windows
provides this up-front, both for junctions and for actual symlinks,
which in turn means that if you do want to follow directory symlinks
then you can just open them as regular directories without fanfare. Of
course, that's also partly why symlinks are discouraged on Windows,
because naive enumeration code will follow them by default and hilarity
can ensue.)

> I am not adverse to adding a "st_reparse_point" field to stat_t. This
> would let client code do its own detection on Windows. Does this work
> for you?

I don't personally have a use case, so I can't really answer the last
question. As I said I'm coming at this thread from a design standpoint
rather than a practical one. (And the original focus of the thread was
on Filesystem rather than AFIO.)

Having said that, more information never hurts; but I think this should
be in addition to the behaviour described above, not instead of it.

Boost list run by bdawes at, gregod at, cpdaniel at, john at