Re: Design for a file system library

From: mfdylan (dylan_at_[hidden])
Date: 2002-02-24 20:32:52

--- In boost_at_y..., Jan Langer <jan_at_l...> 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.
> 
Actually currently it's my own pathname class that I mentioned in 
another post.  But essentially it is a string.  They are not 
templated currently, on the original assumption that file system 
support is either ANSI or Unicode depending on the platform.  I don't 
really like this idea though, I'd prefer templated functions with 
explicitly specialised functions for char and wchar_t in a source 
file.

> >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.
> 
> >bool remove(name_t name);
> >bool copy(name_t source, name_t dest);
> >bool move(name_t source, name_t dest);
> >string_t getcwd();
> >bool chdir(name_t name);
> >bool mkdir(name_t name);
> 
> 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).
> 
getcwd is a problem though because how do you select whether you want 
string or wstring...

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

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

Because Win32 supports down to 100 nanoseconds.  This is actually 
based on the POSIX timespec struct (used by nanosleep, for 
instance).  POSIX seconds only resolution can be a real pain 
actually, especially for modification times.
 
> >I've written Win32 implementations for all of the above, POSIX
> >implementations are trivial.
> 
> i'm currently doing the trivial posix implementations.
> 
> >This is fairly pointless for POSIX of course, where stat() returns
> >basically everything and has no options to specify which bits of 
data
> >you do and don't want.  But for instance under NT, looking up an
> >account name for a file owner can be a slow operation (I've seen it
> >pause for 2 seconds on a regular LAN, no idea why).  Also a lot of 
NT
> >security calls have a flags parameter that allows you to specify
> >which bits of information you actually want.  I would be extremely
> >interested to hear from someone with MacOS experience on this 
matter.
> 
> require() looks IMO very good.
> perhaps we can make require(), get() and set() free functions which 
take
> either basic_string or attribute_set. this would also make user 
defined
> attributes easier.

How would the interface actually look in that case?

> this isn't far away from my proposal. i'll work on separating the
> directory_iterator completely from the attribute_set.
> 

Did you look at the filefinder in the files section?  It uses a win32 
emulation of glob() to provide a simple implentation of a class that 
can be used to iterate through directories with wildcard matching.
The version in there is not quite right I think, because 
technically '*' under glob only returns files *not* beginning with 
a '.', you have to use .* or *.* to get *all* files.
The iterator type is just a cosnt char**, which is problem if we want 
wchar_t support obviously.

Dylan