On Tue, Nov 24, 2009 at 7:35 AM, Beman Dawes <bdawes@acm.org> wrote:
On Sat, Nov 21, 2009 at 6:46 PM, variadic.template < variadic.template@googlemail.com> 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