On Fri, 2003-01-10 at 08:33, ext Jan Harkes wrote:
> On Thu, Jan 09, 2003 at 02:28:56PM -0800, Rod Van Meter wrote:
> > On Thu, 2003-01-09 at 14:08, ext Jan Harkes wrote:
> > > Not sure what 198 is, but reintegration failed. The first entry in
> > > /usr/coda/spool/500/developers_rdv@_coda_rdv.cml should be the operation
> > > that is causing the problem.
> > > 
> > 
> > [rdv_at_localhost rdv]$ more !$
> > more /usr/coda/spool/500/developers_rdv\@_coda_rdv.cml
> > Create  /coda/rdv/nokia/la4a58~1.txt
> > Store   /coda/rdv/nokia/la4a58~1.txt (length = 97994)
> > Create  /coda/rdv/nokia/la4a5b~1.txt
> > Store   /coda/rdv/nokia/la4a5b~1.txt (length = 25423)
> > Create  /coda/rdv/nokia/la4e38~1.txt
> > Store   /coda/rdv/nokia/la4e38~1.txt (length = 29806)
> > ...
> > 
> > (there are a couple of dozen files with these goofy names -- don't ask.)
> 
> Actually I will ask. Are you by any chance exporting /coda through a
> Samba or NFS daemon?

No, they are locally created files.

The file name mangling, if you must know, came from accidentally
trashing a PointSec encrypted NTFS partition on my drive, and only being
able to recover it through a special DOS boot that could read the
encryption and the NTFS -- but only with DOS-like mangled names.  Sigh. 
I haven't finished unmangling them yet.

> 
> 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).

> 
> > The set of files is still small enough that I can see that there are no
> > conflicts.  Everything in the pending .cml is above everything that
> > already exists, alphabetically, except for the creation of a subdir, so
> > it's easy to verify visually.  (In fact, seems likely that, for some
> > reason, this failed partway through the whole set, which gave me this
> > ordering; they should have all been created at the same time.)
> 
> Ehh, you mean all of these files are already present on the server? In
> that case we are looking at an old checkpoint. You should be able to
> refresh it with 'cfs ck /coda/rdv'
> 

No, no, the files are definitely still stuck on the laptop.  They
haven't gone to the server and aren't visible on the desktop (client
#2).

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.

		--Rod