Boost logo

Boost :

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


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

Boost list run by bdawes at, gregod at, cpdaniel at, john at