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
>> 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
>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
>> >know which attributes should be supported at all and which
>> >of accessing them is used, its too early to think about details.
>> Agreed. Rather than proposing signatures, work on filling out
>> 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
>> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk