[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