(Illustration by Gaich Muramatsu)
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/Received on 2005-07-13 14:15:38