
On Tue, Nov 24, 2009 at 10:16 AM, Zachary Turner <divisortheory@gmail.com>wrote:
On Tue, Nov 24, 2009 at 7:35 AM, Beman Dawes <bdawes@acm.org> 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