Re: [boost] [filesystem]: infinite-recursion with symlink

Subject: Re: [boost] [filesystem]: infinite-recursion with symlink
From: Zachary Turner (divisortheory_at_[hidden])
Date: 2009-11-24 10:16:01

On Tue, Nov 24, 2009 at 7:35 AM, Beman Dawes <bdawes_at_[hidden]> wrote:

> On Sat, Nov 21, 2009 at 6:46 PM, variadic.template <
> variadic.template_at_[hidden]> wrote:
>
> > While playing around with boost::filesystem and the
> > recursive_directory_iterator, I'm
> > running into a infinite-recursion caused by symlinks. Not following
> > symlinks
> > would be, a solution, of course,
>
>
> That's the usual solution. Use the no_push() member to tell the
> recursive_directory_iterator no to recurse into a directory.
>
>
> > but...
> > So, is there a way to ascertain the path where the symlink is aiming at?
> >
>
> Version 3, in the sandbox, has just such a feature.
>
>
> > And a second question: I didn't find anything about permission-handling -
> > are there any plans? In my eyes, this is something essential
> > for a filesystem-library.
> >
>
> Not at the moment. We haven't figured out how to abstract away the
> differences between POSIX and Windows approaches to permissions. Any ideas
> appreciated.
>

I'm not sure there really is a way, because the two methods are not
functionally equivalent, and in fact are quite different.  i.e. windows ACLs
can represent permissions that are not semantically representable in the
unix model.  In the filesystem library I've developed in-house my plan for
implementing permissions is to just make a typedef called something like
filesystem::permissions that resolve to opaque structures on both platforms,
and then have APIs like filesystem::windows::allow_permission(),
filesystem::windows::set_owner(), filesystem::posix::user_permissions(read |
write | group), etc.

Is this Filesystem V3 going to support any of the following (and is there an
estimated release date, even if it's highly speculative)?

a) timestamp operations
b) cross-platform create/open of files
c) windows junctions and symlinks
d) unix block/char devices, sockets, and pipes

create/open is the biggest gaping hole in the current FS library in my
opinion.  you often just need a handle and want to customized the way in
which it's opened.  with my code you can do soemthing like:

filesystem::handle handle;      /* opaque structure, only understood by the
filesystem api */
filesystem::object_info info;    /* boost variant, internal type depends on
type of filesystem object */

filesystem::create_file(
         path,
         link_open_target,  /* follow symlinks */
         only_dir,               /* fail unless this is a directory handle
*/
         flags::async | flags::direct | flags::bypass_security,        /*
open for async direct i/o and disable any kernel security checking */
         &handle,              /* have the function return the handle (this
can be null if not interested) */
         &info;                  /* have the function return object info
(this can be null if not interested) */
);

handle then is an opaque object that can be used by other filesystem apis
like timestamp operations etc, and info is a boost::variant whose type
depends on whether it's a directory, junctino, symlink, pipe, etc.

I've solved all of the above problems in a cross-platform way in my own
in-house api but it might be difficult to integrate any of what i've done
into an interface consistent with the current filesystem library.  if you
want any of this code though let me know.

Zach