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