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

From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-02-24 21:22:40

At 07:43 PM 2/24/2002, Jan Langer wrote:

 >On Sun, 24 Feb 2002, mfdylan wrote:
 >>--- 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/
 >>
 >>Btw these are the functions I have currently.  I like the idea of
 >>unifying the attribute set/get interface however, so I will almost
 >>definitely change this.
 >
 >i assume your name_t is just for simplicity and is actually
 >basic_string.
 >
 >>bool exists(name_t name);
 >
 >i'm not sure whether this should be an attribute or a free function. the
 >requirements say its a free function and i'd IMO prefer that.

It seems to me that it should be a free function.

The actual signature I'm assuming for all these free functions is the form:

template< typename CharT >
bool exists( const basic_string<CharT> & x );

Where x is path, dirpath, filepath, dirname, filename, or name, as defined 
in the requirements.  So for exists(), the argument is "path", since it can 
be a directory or file path.  The semantics are much clearer that way.

 >>bool remove(name_t name);

No return.  Should throw if error.  Other than exists(), all the free 
functions should throw on error.

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

 >>bool mkdir(name_t name);

Let's use real names.  make_directory in this case.

 >>bool copy(name_t source, name_t dest);
Wasn't in the requirements, but probably useful enough to justify.

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

 >
 >this seems to be a good set for the free functions for directory and
 >file operations. some of them are already mentioned in the
 >requirements. i am going to implement them for posix (its quite
 >easy).
 >
 >>size_type size(name_t name);
 >>bool readable(name_t name);
 >>bool writeable(name_t name);
 >>bool executable(name_t name);
 >>time_type modified(name_t name);
 >>time_type accessed(name_t name);
 >>bool is_directory(name_t name);
 >>bool chown(name_t name, string_t owner, string_t group);
 >>bool chmod(name_t name, int mode);
 >>string_t owner(name_t name);
 >>string_t group(name_t name);
 >>int mode(name_t name);
 >
 >>[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.

 >>struct time_type
 >>{
 >>	time_type(time_t secs = 0, long nsecs = 0) :
 >>		m_secs(secs), m_nsecs(nsecs)
 >>	{ }
 >>	time_t seconds() const { return m_secs; }
 >>	long nanoseconds() const { return m_nsecs; }
 >>	operator time_t () const { return m_secs; }
 >>private:
 >>	time_t m_secs;
 >>	long m_nsecs;
 >>};
 >
 >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.

--Beman