Re: [boost] Filesystem attributes

From: Jan Langer (jan_at_[hidden])
Date: 2002-03-04 05:50:53

On Mon, 4 Mar 2002, Dietmar Kuehl wrote:
>The file_rep (it may, of course, be called differently, as may the other
>types be called differently, eg. "basic_string" rather than "filename")
>is basically an attribute cache. It is used at least to retrieve all
>attributes at once for reading. Whether it is used to prevent
>write-through is a different issue: There are arguments both ways. When
>writing data into a cache rather than to the actual entity, it may
>easily result in surprising behavior. Basically, a cache should be
>transparent to users and this is often non-trivial to achieve. For
>example, assume that "/tmp" is the current working directory:
>
>    dir_entry f1("./foo");
>    dir_entry f2("/tmp/foo");
>    set(user_read, *f1, true);
>    set(user_read, *f2, false);
>    std::cout << get(user_read, *f1) << "\n";
>
>Does this print "0" or "1"? I would expect "0" but I'm about 100% sure
>that a cached implementation would write "1". ... and the result after
>this code would be either the original state if we require an explicit
>"commit" and "1" if the destructor commits the change implicitly.
>However, I would the access attribute to be "0" because this was the
>latest change.

but to make this example work like you want, it is required to do also
reads uncached and then we would need no dir_entry at all. i think
modifying the same file in parallel with two dir_entries or similar
things should be prohibited.

>Actually, I just wanted to point out the attribute cache has to be
>invalidate (or to be updated) when the directory iterator is moved
>forward. I would definitely bundle a file_rep with a directory iterator,
>BTW, because it would otherwise mean that for file attribute access
>(like eg. "is_directory()") it would be necessary to create a
>dir_entry.
>
> > your approach seems to mean that a directory iterator points to an
> > attribute cache.
>
>Yes, that's correct. ... and even more, I think this is the correct
>approach :-) You have to put the attribute cache somewhere. Options
>are the dir_it or a newly created dir_entry. I think going over a
>dir_entry makes things considerably more inconvenient while the extra
>cost of having a dir_it store both the iteration status and the
>attribute cache is rather low.

now, we have the focus on the right thing. why does it cost more? your
approach does create an attribute cache at every iteration cycle.
independent from the fact whether the user wants an attribute cache to
be set up or not.
while my approach needs the explicit creation of an attribute cache. if
the user just searches a file by name it will be quite easy and cheap.
if he doesn't create a cache he can be sure what will be done.
this design will IMO be much clearer.

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