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

From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-02-25 10:39:34

At 01:32 AM 2/25/2002, mfdylan wrote:

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

That's the trouble with "move"; it is so generic it can be confusing.  But 
it is certainly OK for now as a working name.

 >  Under POSIX it would mean
 >calling rename() and if that fails, copy then remove.  NT
 >has "MoveFile" has builtin.

I know, but the question isn't how to implement on specific systems, but 
how to specify in a way that will be portable to most operating systems.

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

How absolute() does its job internally is an implementation detail; that 
isn't a good argument for exposing getcwd/chdir.

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

Everything you at talking about is non-portable.  "." for example. Fine if 
you want to do that in your own program, but I'd like that sort of 
non-portable thinking not to seep into the interface.

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

I'm not ready to think in terms of code yet; I don't fully understand the 
attribute/permissions/etc requirements yet.

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

Reinventing a common need may cut dependencies, but that isn't likely to 
fly with something as basic as time, IMO.

--Beman