Re: Design for a file system library

From: mfdylan (dylan_at_[hidden])
Date: 2002-02-25 01:32:30

--- In boost_at_y..., Beman Dawes <bdawes_at_a...> wrote:
> At 07:43 PM 2/24/2002, Jan Langer wrote:
> 
>  >>bool remove(name_t name);
> 
> No return.  Should throw if error.  Other than exists(), all the 
free 
> functions should throw on error.
> 

I agree actually, I was being lazy more than anything.

>  >>bool move(name_t source, name_t dest);
> 
> Not sure if this should be called rename or move.  Specs need to be 
worked 
> out if the target is a different volume than source.
> 
move is generic enough to cover both, IMO.  Under POSIX it would mean 
calling rename() and if that fails, copy then remove.  NT 
has "MoveFile" has builtin.

>  >>bool mkdir(name_t name);
> 
> Let's use real names.  make_directory in this case.
> 
Fair enough, although avoiding abbreviations entirely might not be 
feasible.

>  >>string_t getcwd();
>  >>bool chdir(name_t name);
> 
> No, not without a lot of discussion.  Go back and read the 
> requirements.  Globals are too evil to just casually toss into the 
hat.
> 
But absolutely necessarily.  You can't implement absolute() with it.  
I guess if the only access to the current working dir is by calling 
absolute(".") I'd live with it but I wouldn't be happy.
chdir is useful for a few limited purposes, as long as you ensure all 
relative paths are kept to one thread.  It's also useful when forking 
child processes, but in that case you need a specialised interface, 
because under NT you have to do it quite differently. I already 
started work on a class for forking subprocesses, not sure if I 
posted anything here.

>  >
>  >>[permission details]
>  >
>  >these should be implemented as attributes but since we actually 
don't
>  >know which attributes should be supported at all and which 
mechanism
>  >of accessing them is used, its too early to think about details.
> 
> Agreed.  Rather than proposing signatures, work on filling out 
Jan's 
> attribute table is what is needed now.
> 
We still need agreement on what form owners and groups should take.
I just finally completed my code for properly determining the fully 
qualified owner and groupname for *any* file, and as far as I can 
tell, you actually need the filename in order to do it.  It's over 
200+ lines of code and includes:

* getting security descriptor
* getting 'owner' or 'group' SID from security descriptor
* working out full path for filename
* if in form 'x:\...' then check if drive type is local, if not:
*  try to resolve substituted drive letters to network drives
*  look up mapped drives to find UNC name, get server from that
* look up the account and domain name on that server from the SID
* if domain name is built-in domain, use server name instead

This allows you to map \\XYZ\share to drive z: then substitute drive 
y: for z:\test then chdir to y: and determine that the owner 
for "file.txt" is XYZ\\joe_bloggs.  
Note that even NT explorer gets it wrong - try accessing the 
properties of y:\file.txt in explorer and checking the owner (or even 
the pemissions), and explorer tells you "No network provided accepted 
the given path".  It's actually just the subst that fools it, 
everything else works.

Btw Win9x does have some support for file security via the NetAccess* 
calls but I don't see any great need to support it (it presumably 
only works on remote filesystems that have security).

>  >
>  >why should nanoseconds be supported? i just don't have an opinion
>  >on this.
> 
> Seems like we should hold off on time until Jeff Garland and his 
group get 
> their time library proposal done.

I thought about that but do we want/need that sort of dependency?

Dylan