On Wed, Jul 13, 2005 at 12:13:34PM -0600, Patrick Walsh wrote:
> On Tue, 2005-07-12 at 15:09 -0600, Patrick Walsh wrote:
> 
> > # ls -l remupd/isched.ppi
> > lrwxr-xr-x    1 admin    65534          36 Jul 12 13:09
> > remupd/isched.ppi -> @7f000001.00000cc4.00009933_at_director
...
> 	I have some more information to add.  I can actually delete the problem
> files.  So in the above example, I can do the following:
> 
> # rm remupd/isched.ppi
> # ls -l remupd/isched.ppi

I guess I should have noticed this earlier. Those files are in fact not
conflicts, because we not only use a special link target, but also
unusual mode bits

lr--r--r--  1 root nogroup 29 Jul 13 16:42 foo -> @7f000492.00000173.00016c8f_at_coda.cs.cmu.edu

My guess is that the actual conflict is wherever these are copied from.

> 	The script that gets run regularly is some variation of the following.
> It downloads virus updates to a temp directory and moves it to coda:
> 
> /bin/rm -rf $codadir/update.last
> /bin/mv $codadir/update $codadir/update.last
> /bin/mv $tempdir/$subdir $codadir/update
> 
> 	That's basically it.  There are a couple of similar scripts that act on
> different directories.  It's possible they could be running at the same
> time though I don't think this typically happens.  
> 
> 	The conflicts come back quite reliably after I delete them (which is to
> say, on the next update).

Is the tempdir in coda? If there is a conflict, mv probably fails to
rename the object and falls back on copy/unlink, and the unlink will
fail as well.

So the next time around the conflicts in the temp directory are still there.

Jan