[daip] Zap issue
Eric Greisen
egreisen at nrao.edu
Thu Jan 31 18:27:28 EST 2013
Doug Gobeille wrote:
> Dearest DAIP,
>
> When trying to zap to pesky files, I receive the following messages:
>
> >getn 1
> AIPS 1: Got(1) disk= 1 user=3666 type=UV 19980511.CH
> <http://19980511.CH> 0.1
> >zap
> AIPS 1: ZDESTR: FILE DA01:UVD001001.2TU; IN USE. IERR= 3
> AIPS 1: FAILED TO DESTROY UV IMAGE FILE: CATNO= 1 DISK= 1
> AIPS 1: NO DESTROY
> >getn 3
> AIPS 1: Got(1) disk= 1 user=3666 type=UV 19980511.UVFIX.1
> >zap
> AIPS 1: NX FILE VERSION 1 DID NOT SELF-DESTRUCT ON COMMAND
> AIPS 1: ZDESTR: FILE DA01:UVD003001.2TU; IN USE. IERR= 3
> AIPS 1: FAILED TO DESTROY UV IMAGE FILE: CATNO= 3 DISK= 1
> AIPS 1: NO DESTROY
> >
>
>
> Their statuses are clear and I have run clrstat on them multiple times
> to be certain.
It sounds as if the files are still locked (in a UNIX sense) by some
process which could be still running or could be long gone. I have a
tool I use sometimes to explore this but I don't thing we distribute it.
We used to see this a lot when we ran on one computer but had data files
on another computer. File locking across NFS was decidedly prone to
leaving locks when processes died, esp when they died with a kill -9.
Our setup here goes to considerable lengths to avoid this cross-computer
disk usage, but it i allowed and sometimes used and has not been
problematical of late.
One solution which should release file locks is to reboot your computer.
To avoid that drastic solution, another thing I do is rename the
locked file to something that will not bother aips and then clean up
what will clean up. An rm on the new names surprisingly works sometimes
right off or after a delay.
Eric Greisen
More information about the Daip
mailing list