(Illustration by Gaich Muramatsu)
On Fri, Jan 10, 2003 at 10:27:56AM -0800, Rod Van Meter wrote: > > We cannot twiddle active files and directories into dangling symlinks. > > So if there is some process that has it's current working directory in > > /coda/rdv/nokia, or is caching open file handles, Coda can't turn the > > object into a conflict. Often 'lsof | grep /coda' will show what > > processes are holding references to files in Coda. > > Doesn't return anything in /coda (just the usual stuff in /usr/coda). Strange, I don't know why the dangling symlink isn't showing. It could be that the kernel is caching too much, you could try cfs er /coda/rdv/nokia ls /coda/rdv/nokia The 'er' or 'endrepair' will trigger venus to send a downcall that invalidates the cached state in the kernel for that directory. In any case, this 'conflict' is possibly caused by the fact that resolution is disabled for this volume. Because it is a directory operation that failed and volumes that have resolution disabled have a stricter than usual consistency test for the storeid of a directory. I'm not sure how to create a good testcase, but reenabling resolution for that volume with volutil setlogparms <volid> reson 4 will switch it back to the weaker consistency test. The problem with enabling resolution on singly replicated volumes is that when the 2nd phase of the 2 phase commit (the COP2 message) is omitted, the volume builds up a resolution log. This log is never truncated because there will never be a server-server conflict to resolve. > I created this set of files (actually copied them from somewhere else) > all at the same time, and the sync failed partway through. So some of > them are stored on the server and are visible on the desktop, but most > of them are only on the laptop. The CML accurately reflects the set of > files that have not been pushed to the server yet. If 'cfs er' makes the dangling symlink visible, you should be able to use repair. The client won't reintegrate until the repair has at least forced the conflicting operations through (preserveall), or discarded them (discardlocal). If you can't get the symlink to show up, 'cfs purgeml /coda/rdv/nokia' will discard the CML and allow you to get back to Connected mode. Ofcourse all of the queued up changes will be lost, so you might want to make a backup copy of the checkpointed tarball before purging the CML. JanReceived on 2003-01-10 14:23:47