iraf.net

Vinay,> imdir was set to "." (as far as I recall) -- it may have gotten
> "translated" to the full path name?Yes, relative pathnames like "." are expanded before they get written
into the header file. In any event, this agrees with the observed
behavior.> We weren't running ccdproc, but we did use an IRAF/Unix shell window
> combination to, e.g., obtain the file lists, rename the directories,
> etc. The temporary directory that had been created during the initial
> imcopy was deleted from the Unix shell. This is a possible source of
> the data loss (e.g., mistyped directory names? -- but there should have
> been other consequences to such a damnfool action that we do not see, so
> I do not understand how). Unfortunately we do not have the command
> history for this window.At this point it may unfortunately be impossible to sort out the precise
sequence of events. We've all certainly typed commands with unintended
results - it's good to at least be able to figure out the cause after
the fact, but some things remain mysteries...>> Were these names similar to the previous night's images?
>
> yes.Ok, that allows for a number of possible problems that wouldn't
otherwise be possible.> You are right, the first rfits did result in an error, and the second
> one had the arguments input at the prompts. But I believe the same
> arguments were input again -- i.e., not tmp3.lst, but tmp2.lstI guess I'm still confused then, since this would appear to provide
rfits with an input list of .imh images, not FITS. This would generate
some obvious error, though - I don't see any way that this would hurt
your images.>> There's also some possible confusion over the file lists. You issued
>> the imcopy and wfits commands in one directory which presumably
>> contained the three files tmp1.lst, tmp2.lst and tmp3.lst - but then
>> moved to the other directory and issued the rfits and imrename commands
>> using the same filenames. Is it possible that these generically named
>> files existed in both directories, but with different contents? If
>
> yes, and indeed the first tmp1.lst was overwritten. But the ones used
> with the final rfits are as given.Ummm - the "overwritten" is a problem here, since the imclobber behavior
shouldn't be possible with this version of IRAF.Ok, another rather obscure possibility has arisen. Mark says:>> What version of IRAF?
>
> Probably 2.10.2, but perhaps 2.10.4-p2.IRAF v2.10.2 is quite ancient at this point. It turns out that v2.10.3
introduced a fix (several years ago...) for a rather obscure bug that was
only possible if IRAF commands were combined with commands at the Unix
level. It is possible that your combination of commands triggered this,
although this is by no means certain. Note that even if this bug were
involved that we have been unable to construct a scenario for removing
your images that wouldn't have generated numerous error messages.Let me describe the bug and you guys can comment on whether this may
have occurred. Information to know: IRAF tasks run in subprocesses
of the CL. These subprocesses are maintained in a process cache in
between task executions - the programs don't just run and vanish, they
are woken up repeatedly as IRAF commands are issued.Now then, the CL has to pass information to the subprocesses, specifically
the current working directory. As you issue "cd" commands to the CL, the
CL passes the command on to the subprocesses. The nature of the bug was
that in some circumstances the "cd" command would not be acted on
immediately by the subprocess, but would wait for the next task to be
issued that required that subprocess.There is no problem with this in most circumstances since the cd command
would still be issued in each subprocess immediately before the next
task execution. However, if at the same time host level commands have
deleted directories that form part of the path that this pending cd
command depends on, the cd command would generate an error in the
subprocess when the command was finally acted upon. The result of this
error could be (depending on the precise directory tree and cd command)
that the subprocess would be in a different directory than intended.Note that your example showed that you relied on "pwd" and "ls" to list
the location in the directory tree. These are not IRAF commands, but
rather are foreign tasks executed in a Unix shell. If you had executed
the corresponding IRAF commands "path" and "dir", you might well have
noticed a problem with an unintended directory location (assuming the
system subprocess wasn't located in a different place than the images
package or dataio package subprocesses).I presume you see how being in the wrong directory might result in data
being lost - especially if two different subdirectories contain images
with the same names (I think that is what you are saying). However, I
don't see how these images would be deleted without generating error
messages unless either imdelete was used directly, or the imclobber
feature was available. Neither of these cases seems to apply.Do I think this is what happened? Not with any high reliability. Do I
have a better answer? Not at this point. But with commands being issued
in multiple windows, any number of even more unusual scenarios could be
constructed.Can you folks confirm whether you were observing with IRAF v2.10.2 under
SunOS or with IRAF v2.10.4-p2 under Solaris? If the latter, this peculiar
problem would not have been possible.Rob