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

Subject: Re: [boost] [filesystem]: infinite-recursion with symlink
From: Beman Dawes (bdawes_at_[hidden])
Date: 2009-11-24 17:03:38

On Tue, Nov 24, 2009 at 10:16 AM, Zachary Turner <divisortheory_at_[hidden]>wrote:

> On Tue, Nov 24, 2009 at 7:35 AM, Beman Dawes <bdawes_at_[hidden]> wrote:
>
> > > 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.

Cygwin attempts to map the traditional Posix permissions functionality onto
Windows. With Cygwin 1.7, now in beta, they are also mapping ACL's onto
Windows. While that approach may not supply all the features of Windows, it
does seem to provide enough functionality to be useful.

>  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.
>

Boost.Filesystem has always resisted doing that. There is still
functionality other functionality that has been requested I'd like to work
on first.

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

The V3 library code is about ready for a beta. I'm working on docs now. I'm
semi-aiming for a January 1st beta release.

>
> a) timestamp operations
>

Which specific timestamp operations do you need? Last write time is already
supported.

> b) cross-platform create/open of files
>

Nothing planned, beyond the current <fstream> support.

> c) windows junctions and symlinks
>

Supported in V3.

> d) unix block/char devices, sockets, and pipes
>

Nothing planned in Boost.Filesystem. Several other Boost libraries already
have at least some support for these.

>
> 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.
>

Nothing like that planned at the moment.

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.
>

What I'd be most interested in is motivation and use cases. I need to better
understand the need before I start thinking about code.

Thanks,

--Beman