Re: [boost] Re: Design for a file system library

From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-02-23 19:50:40

At 04:29 PM 2/23/2002, mfdylan wrote:
 >--- In boost_at_y..., Beman Dawes <bdawes_at_a...> wrote:
 >> I've written a design document for a file system library. See
 >>
 >http://groups.yahoo.com/group/boost/files/filesystem/filesystem_librar
 >y_design.htm
 >>
 >> It is still rough, but should serve to focus discussions.
 >>
 >> Comments appreciated.
 >>
 >> --Beman
 >
 >Let's hope we can get enough momentum going this time to get
 >something concrete done :o)
 >Some things I've added to my own filesystem implementation:
 >
 >* permissions/file ownership.  Difficult because this is a highly non-
 >portable concept in general, yet essential because there are enough
 >common characteristics that require platform-specific implementations
 >that should in a library.  To prove it was possible I've written NT
 >implementations for chown*, owner, group, chmod, mode, and access
 >that do (nearly) all the nearly ACL manipulations.  Some are
 >impossible, some are just (IMO) pointless, so for instance you can't
 >make a file readable by everyone except the owner like you can under
 >UNIX (ok, now someone tell me why you would want to).  They use
 >strings to represent user and group names which under NT means you
 >need to include the domain name (my own computer at work has
 >two 'dylan' users, one for the local domain, and one for the network
 >domain).  I use a set of 'permission' tags more or less like POSIX
 >(owner_readable, group_writeable, other_executable).
 >Anyone who has written code to manipulate NT ACL's would probably
 >agree a much simpler interface is needed to perform reasonably common
 >operations (such as making a file only writable by its owner).  Oh
 >and the read-only attribute is also accounted for (and set, if you
 >try to chmod() to just "all_read").

Have you looked at the way attributes are handled in Dietmar's and Jan's 
submissions? See their entries in 
http://groups.yahoo.com/group/boost/files/filesystem/

 >Anyone know anything about file system security under MAC?
 >
 >* copying a file - extremely common operation, but requires writing
 >code under POSIX, NT has CopyFile.  Moving a file often involves
 >copying then deleting when the built-in OS move functionality doesn't
 >allow it.
 >
 >It seems from your initial writings you are thinking along the lines
 >of a set of namespace-scope functions that operate on std::strings.
 >This is essentially what I have currently (although they accept my
 >pathname class, which allows passing in a string).

Yes. Non-member functions seem appropriate.  They can be extended later 
with minimal effect on existing code.

 >I also want to try a design whereby an object represents a file or
 >directory which has various members to represent the various
 >operations that can be performed on it.

I gave that a lot of thought too, but keep coming back to the simplicity of 
free functions.  That approach interoperates well with the current standard 
library, and native platform API's, too.

Thanks for the feedback,

--Beman