Re: Design for a file system library

From: mfdylan (dylan_at_[hidden])
Date: 2002-02-23 21:31:36

--- In boost_at_y..., Beman Dawes <bdawes_at_a...> wrote:
> At 04:29 PM 2/23/2002, mfdylan wrote:
> 
> 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/
> 
I thought creating uid and gid types as well but they wouldn't be 
much use if you couldn't get "string" forms of them for display.
It would also be difficult to code a uid/gid type under NT that could 
act in a similar manner to POSIX, where it is guaranteed to be an 
integral type (hence you can do numerical comparisons etc).
NT has a "SID" which you can certainly test for equivalence etc., but 
you can't easily serialise it as any thing other than the string 
form.  That's why I felt sticking to a string was the safest, more or 
less the same reasoning behind using strings to represent pathnames.

One thing that concerns me with separating out attributes to the 
degree they are in the document you mention is efficiency: with some 
filesystems, especially network file systems, it can be a potentially 
time-consuming operation just to modify a file attribute.  Therefore 
some scheme of accessing/modifying a set of attributes all at once is 
really necessary.

At any rate I'm more than happy to contribute my code for simulating 
POSIX files mode with NT ACL's and allowing access/modification of 
file ownership/group.  The one thing it still needs is error handling 
(currently it simply returns false if anything goes wrong).  It also 
uses _alloca extensively (given it's supposed to be VC only code this 
wasn't a big issue, but if we want to compile on other Windows 
compilers it might be).  

Dylan