imcopy/copy protect bug
Jason Quinn wrote on Oct 24, 2011
I noticed that doing an "imcopy" or a "copy" on protected image does not copy the protection even though the help file for "protect" says, "File protection is preserved when a file is copied or renamed". At least at some point in the past, copying the protection was the expected behavior. The imrename command does preserve the protection.
Cheers,
Jason
STEPS to produce:
protect somefile.fits
imcopy somefile.fits newfile.fits
Cheers,
Jason
STEPS to produce:
protect somefile.fits
imcopy somefile.fits newfile.fits
Mike Fitzpatrick wrote on Oct 24, 2011
There are actually two problems here: The IRAF kernel didn't properly implement protection in the case of a file copy (and hasn't going as far back as v2.8), the second is that protection for images is done in the image kernel and the FITS kernel doesn't do this except in the case of file overwrites.
I've fixed the kernel bug so that when copying files the protection is preserved as intended (for FITS files using COPY instead of IMCOPY will do this as well). However, adding protection to the FITS kernel is a little trickier and since this isn't critical I've decided to put it off to the new version of the FITS kernel being developed. IMRENAME uses a different method to rename the files which is why it works.
I've fixed the kernel bug so that when copying files the protection is preserved as intended (for FITS files using COPY instead of IMCOPY will do this as well). However, adding protection to the FITS kernel is a little trickier and since this isn't critical I've decided to put it off to the new version of the FITS kernel being developed. IMRENAME uses a different method to rename the files which is why it works.
Jason Quinn wrote on Oct 24, 2011
fitz
There are actually two problems here: The IRAF kernel didn't properly implement protection in the case of a file copy (and hasn't going as far back as v2.8), the second is that protection for images is done in the image kernel and the FITS kernel doesn't do this except in the case of file overwrites.
I've fixed the kernel bug so that when copying files the protection is preserved as intended (for FITS files using COPY instead of IMCOPY will do this as well). However, adding protection to the FITS kernel is a little trickier and since this isn't critical I've decided to put it off to the new version of the FITS kernel being developed. IMRENAME uses a different method to rename the files which is why it works.
If this has been the behavior for so long, then life is apparently okay without it. It raises the question if protection should be preserved under a copy. An alternative solution is to simply decide that protection is not preserved. This has the added advantage of keeping past behavior. Perhaps just changing the help file for protect would be an easier solution. Is there a rational or design criteria why protection should be preserved under a copy?
Jason
Jason
Mike Fitzpatrick wrote on Oct 24, 2011
The rationale is probably as ancient as "that was the behavior under VMS on which the idea was based". In any case, protection for copy was implemented in the kernel, just incorrectly. Fixing this is probably harmless since it only affects those files explicitly covered by PROTECT. The only other place file protection is still used is for .imh files, but that's handled by the image kernel.
Your reasoning, though, is why I decided it wasn't critical to fix the image protection for this next release.
Your reasoning, though, is why I decided it wasn't critical to fix the image protection for this next release.
Last post on Oct 24, 2011