Re: [boost] [filesystem] proposal: treat reparse files as regular files

Subject: Re: [boost] [filesystem] proposal: treat reparse files as regular files
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-08-04 18:14:48

On 4 Aug 2015 at 12:40, Gavin Lambert wrote:

> > Fixed. Each reference page now links to related types too.
> 
> They still seem to be missing on the function reference pages (I checked 
> https://boostgsoc13.github.io/boost.afio/doc/html/afio/reference/functions/enumerate/enumerate_6_max_items_first_throwing.html), 
> which is probably where they'd be the most useful.

It's actually there, it's just the docs generation tooling has 
collapsed the paragraphs into a single large paragraph. I'll look 
into a workaround after I've ported AFIO onto the new APIBind based 
multi-abi implementation of Boost.Monad.

> I'm used to the style of the Boost.Asio docs (eg. 
> http://www.boost.org/doc/libs/1_58_0/doc/html/boost_asio/reference/async_read/overload1.html), 
> where all the types are linked directly in the method description.  (Of 
> course, mostly they're templates, but still...)

I don't think the Boost.Geometry doxygen to qbk tool AFIO uses can do 
this.

For Boost.Monad I'm sticking to a pure doxygen solution. I've wasted 
a lot of blood and sweat for little gain on AFIO's BoostBook 
documentation, and doxygen I think is a much more complete 
documentation tool than it once used to be.

It would be really great if someone could skin doxygen to output 
something very close to BoostBook's output as I find doxygen's 
default HTML output pretty awful, but I suspect many of us will need 
to adopt doxygen first to generate the pressue for someone to do the 
skinning work.

> > I would prefer to not report something as a symlink when target()
> > won't work with it. So you now have an additional stat_t flag called
> > st_reparse_point which is always the FILE_ATTRIBUTE_REPARSE_POINT
> > flag.
> 
> I guess that depends on usage cases -- if it's most common to write code 
> like if (type() == symlink_file) { do something with target(); } then 
> you have a point.  Although code that has sufficient error checking 
> should be able to cope with the idea of a symlink that has an unreadable 
> target.
> 
> But it seems odd to me to claim that a file is *not* a symlink just 
> because you're told that it's a type of symlink that you don't know how 
> to read.

I'd like to think AFIO's symlinks are "POSIX(-y) symlinks".

> Having said that, I don't know how common custom symlinks are in the 
> wild, or if they even exist at all.
> 
> > AFIO is a bit caught here too actually. If you're enumerating a
> > directory you have no easy way of disambiguating between a symlink to
> > a directory and a symlink to a file. You basically have to try
> > opening it as a directory, and if it errors out you then open it as a
> > file.
> >
> > Windows does supply what kind of symlink it is without additional
> > syscalls, but POSIX does not. You'd have to do two syscalls per entry
> > to disambiguate which is very costly for something so niche.
> 
> Perhaps rather than just having symlink_file, Filesystem should have 
> symlink_file, symlink_directory, and symlink_entry?  POSIX would return 
> the latter (indicating that it's unknown whether it's a file or 
> directory) while Windows would return one of the first two.  This would 
> still allow code to be written in a reasonably platform-independent manner.
> 
> Another option might be for stat_t to have a field that contains the 
> OS-native flags, so that on Windows the DIRECTORY flag could be examined 
> directly.  This might also allow for other esoteric attributes 
> (COMPRESSED, ENCRYPTED, NOT_CONTENT_INDEXED, etc) to be inspected/set as 
> desired, although that's probably more useful in Filesystem rather than 
> AFIO.  Although I think this is uglier than the above for the 
> enumeration case.

Given the Filesystem TS has shipped, I'd say that moment has passed.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/