On Tue, Dec 17, 2002 at 10:24:32AM -0500, Greg Troxel wrote:
> rolling back to and old DATA/LOG/venus.cache, I find that running 'md5
> *' in the directory fetches the new files and not the old, and file
> contents are ok.
> 
> Doing 'touch a' (does not exist on server) works, but 'cfs fr .'
> causes venus to print '..2/2 records, result = Operation already in
> progress' and VIOC_SYNCCAACHE returns EINVAL.  At this point, the new
> file is not in the directory as shown by ls -l
> touch a results in the can't create error above.

There is a counter that is stored in RVM which gives every reintegration
a unique identifier. If there were reintegrations after you backed up
the LOG/DATA and venus.cache files, then the server will assume that new
reintegrations are already committed and it will return EALREADY. As a
result the client will drop the operations.

As a result the client cache becomes out of sync with the server state.
You have that newly created file locally, and it is a child of the
directory. However the directory version vector is different, so the
client refetched the servers' view on the world. Then when you try to
recopy the file the directory entry can be created, but there is
already an FSO with the same name hanging off the directory.

This is kind of hard to fix as we can't tell how far to bump that
counter. This looked like a reasonable approach at first, but there are
some other solutions that may be more viable in the long run.

Jan