Re: Design for a file system library

From: mfdylan (dylan_at_[hidden])
Date: 2002-02-23 16:29:20

--- 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").
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).
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.  A separate global object can 
represent the cwd if necessary.

Dylan

*) to implement chown under NT means you have to pretend to be 
restoring the file from backup :o)