On Wed, May 16, 2007 at 08:55:06AM -0400, Jan Harkes wrote:
> On Wed, May 16, 2007 at 09:29:28AM +0200, u+codalist-p4pg_at_chalmers.se wrote:
> > For such and similar reasons I would love, say, having an option of
> > "the files right now in the cache shall be there forever".
> 
> Not making such files candidates for cache replacement is not that hard.

A good starting point!

> The final update method is to write the new file and then rename it over
> the old one. Now the pinning mechanism would have to know that the new
> file name is interesting enough to demand fetch. Also we don't actually
> see the individual operations that led to the new server state on the
> client so really for a client this would look similar to the first case.

:(
with these limitations at least I'd like the file to keep it pinned
status after replacement?

So, it is hard to make file replacement painless, but I can accept this,
given that replacement by itself is prone to disasters,
race conditions apply as well to file collections and Coda can not protect
from fetching, say, a changed config file which points out
objects we never had (nor fetched before disconnection).

That is another reason why it can be undesirable to refresh files
when they are not used - it may break an otherwise usable file collection,
say by extending the set of files referred by each other.
The hoard set must be expanded to account for that, but we do not know
unless we use the files again, possibly being disconnected at that time.

> > I think a similar result can be achieved by making a lookaside cache
> > of Venus cache. What happens if I hardlink the container files
> > into a shadow tree? If Venus does not notice that, it would allow
> > a space-efficient preservation of current cache for lookaside.
> 
> Venus doesn't unlink container file when they are reused, it simply
> truncates the existing ones. So it won't break hardlinks.

Ok, I lose grossly here - but you mentioned that pinning down the cache
contents might be doable anyway?

Thanks Jan,
Rune