[daip] Phantom undeletable SN table

[Eric Greisen]

On 07/30/2014 12:02 AM, Juan-Carlos Algaba-Marcos wrote:
> Dear Daip gurus,
> I was running FRING in AIPS (31DEC11) while, for other reasons, the
> computer (mac OS Lion) crashed. As a result, the task was left active
> but not running anymore. After I CLRSTATed the involving files and
> reseted AIPS, there seemed to still be some FRING process which I found
> by with
> ps -elf | grep FRING
> A 'kill' didn't work, so I restarted the computer. After this,
> unfortunately, there was sill some SN table that had been created by the
> task. Although the uvdata was fine, as I tried to inspect the SN table
> (e.g, by SNPLT), I got the following error:
> localh> SNPLT1: Task SNPLT  (release of 31DEC11) begins
> localh> SNPLT1: ZERROR: ON FILE DA0E:SND002007.00A;
> localh> SNPLT1: ZERROR: IN ZEXIS2 ERRNO = 5 (Input/output error)
> localh> SNPLT1: TABINI: I/O ERROR FROM ISTAB ON SN
> localh> SNPLT1: ERROR   3 OPENING SN TABLE NO.   7
> localh> SNPLT1: NO DATA SELECTED
> localh> SNPLT1: Purports to die of UNNATURAL cause
> I assume this is because the header of the SN7 was created but it
> contains just a dummy file, so I proceeded to delete it, which I could not:
>  >getn 2;inext 'sn';invers 7;extdest
> AIPS 1: ZOPEN: STILL WAITING FOR FILE DA0E:UVD002001.00A;
> I thus decide to copy the uvdata and the safe tables somewhere else and
> zap the entire file.
>  >getn 2;zap
> AIPS 1: Got(1)   disk=14  user=  10   type=UV   R13360A.MSORT.1
> AIPS 1: SN FILE VERSION  7 DID NOT SELF-DESTRUCT ON COMMAND
> AIPS 1: Destroyed  1 extension files of type SN
> AIPS 1: Destroyed UV image file: catno=      2 disk=14
> AIPS 1: NO DESTROY
> Following some other daip message, I have tried to locate the
> corresponding table outside AIPS. I checked the AIPS data area
> ls -la SND002*.00A*
> ls: SND002008.00A;: Input/output error
> -rw-rw-r--@ 1 xxxxxxx  xxxxx  10240 Jul 30 12:23 SND002007.00A;
> ie, a table SN7 in catalog 2, disk 10 (matching the problematic SN
> table) that apparently I cannot touch. Shall I treat this as an
> unmovable corrupted file system, or is there a way I can get rid of it
> inside/outside AIPS? I don't fancy the idea of having a catalog ID in
> AIPS with corrupted unusable data.
> Thank you very much,

Apparently the "crash" did not cause your computer to reboot and I 
suspect you did not do a full reboot (or it did not do what it should). 
  In any case, the file lock has remained on that disk file from a 
no-longer existing process.  You cannot delete the file, but you can 
re-name it:

mv SND002007.00A\;  SNlocked.00A.old

for example.

This will not interfere with normal aips usage and the data area will 
remain functional.

Eric Greisen