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

From: Jan Langer (jan_at_[hidden])
Date: 2002-02-24 19:43:53

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.

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

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

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

>I've written Win32 implementations for all of the above, POSIX
>implementations are trivial.

i'm currently doing the trivial posix implementations.

>The problem with attributes as I mentioned in another post is that
>you need a way to specify upfront exactly which attributes you want
>and request them all in one go.  Some attributes might be expensive
>to determine, others might be better grabbed all in one go, according
>to the platform and whether the files are local or remote.
>One way is using some sort of type list, but this isn't terribly
>amenable to determining at runtime whether a certain attribute is
>needed.  Furthermore the syntax is bound to be awkward.
>Another possibility is something like:
>
>attribute_set attr = attributes(pathname);
>attr.require<owner>();
>attr.require<group>();
>attr.require<size>();
>string s = attr.get<owner>();
>...
>
>where the 'require' calls are an optional hint to optimise the
>eventual request, made through a get() call (which would request all
>the information hinted at and cache).
>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.
this isn't far away from my proposal. i'll work on separating the
directory_iterator completely from the attribute_set.

-- 
jan langer ... jan_at_[hidden]
"pi ist genau drei"