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
> # cfs fl remupd
>         DANGER:   these files will be lost, if disconnected
>         Do you really want to do this? [n] y
>         Fools rush in where angels fear to tread ........
> # cfs fl .
>         DANGER:   these files will be lost, if disconnected
>         Do you really want to do this? [n] y
>         Fools rush in where angels fear to tread ........
> # ls -l remupd/isched.ppi
> lrwxr-xr-x    1 admin    65534          36 Jul 12 13:09
> remupd/isched.ppi -> @7f000001.00000cc4.00009933_at_director
> # ls -l remupd/data.tag
> -rw-rw-r--    1 admin    65534         110 Jun  8  2004 remupd/data.tag
> # lsof |grep remupd
> (no output)
> # cfs br remupd/isched.ppi
> remupd/isched.ppi isn't inconsistent
> 
> 
> 	Any new thoughts?  I tried this process on the client that's writing
> the files as well as on a client that just reads them.  Same effect.

	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
#

	So they definitely don't seem to be actual conflicts.  Somewhere
they're being marked as conflicts though.  I don't know how to recover
from this in a non-destructive way.  And I'd love to know why they're
being flagged as conflicts in the first place.  

	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 there anything we can try that might reduce the chance of conflicts
in this case?  Or is there anything I can do to help pinpoint where the
problem is?

-- 
Patrick Walsh
eSoft Incorporated
303.444.1600 x3350
http://www.esoft.com/