I have almost successfully backed up and restored venus state, after
applying Jan's suggested change.  I had to restructure code slightly;
it would be nice to have this change in CVS, even if the ifdef default
is the other way, to make it easy to change.

However, after this change, all is not well.  I was able to read files
from the cache, but when trying to mv the diff into
/coda/home/gdt/PATCHES/CODA, it appeared in my local fs, but not on
the server, even after 'cfs fr .'  Touching a file on another client
caused the directory to revert to the server's view of things (files
from before, plus newly touched file, but not locally added patch
files).

Afte mucking about some, I got a fatal venus error on the
backup-restore client:

gdt 282 ~/%co/PATCHES/CODA > cp ~/fuzzy-inodes .
10:14:07 fatal error -- fsobj::dir_Create: (fuzzy-inodes, 7f000001.3fe6.9a97) Create failed!
10:14:07 RecovTerminate: dirty shutdown (1 uncommitted transactions)
coda_unmount: active = 1, vflush active 0
cp: ./fuzzy-inodes: Operation not supported by device

This was after copying it in, 'touch a' on the server, which caused it
to disappear from the directory.

So there is still some inode dependency, I think.

after venus -init, all was ok again.

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.

Are there inodes in the rvm representation of directories?





Index: coda-src/venus/fso_cachefile.cc
===================================================================
RCS file: /coda-src/coda/coda-src/venus/fso_cachefile.cc,v
retrieving revision 4.43
diff -u -r4.43 fso_cachefile.cc
--- coda-src/venus/fso_cachefile.cc	3 Jun 2002 14:33:23 -0000	4.43
+++ coda-src/venus/fso_cachefile.cc	17 Dec 2002 13:07:02 -0000
@@ -101,12 +101,31 @@
 
 int CacheFile::ValidContainer()
 {
-    int code = 0;
+    int code = 0, valid = 0;
     struct stat tstat;
     
     if (inode == (ino_t)-1)
         return 0;
-    int valid = (code = ::stat(name, &tstat)) == 0 &&
+
+    code = ::stat(name, &tstat);
+
+#ifndef STRICT_INODES
+    /*
+     * We intentionally don't require inodes to match so that untarring a
+     * saved tarball of DATA, LOG and the cache hierarcy can restore
+     * a host to a previous state.  This enables bandwidth-poort hosts
+     * to remember the effects of hoard walking when recovering from
+     * various kinds of venus lossage as an alternative to -init.
+     */
+    if (tstat.st_ino != inode) {
+        Recov_BeginTrans();
+        RVMLIB_REC_OBJECT(inode);
+        inode = tstat.st_ino;
+        Recov_EndTrans(MAXFP);
+    }
+#endif /* STRICT_INODES */
+
+    valid = code == 0 &&
 #if !defined(DJGPP) && !defined(__CYGWIN32__)
       tstat.st_uid == (uid_t)V_UID &&
       tstat.st_gid == (gid_t)V_GID &&






        Greg Troxel <gdt_at_ir.bbn.com>