Possible copy bug
Jason Quinn wrote on Apr 30, 2006
I may have found a bug in IRAF's copy command. I've noticed that copy corrupts some gzipped files. For instance, try downloading and copy'ing table.2.gz from
http://vizier.cfa.harvard.edu/viz-bin/ftp-index?/ftp/cats/J/A%2bA/424/919/x70z02
Notice the file size increases by 1 after a copy. The UNIX cp command does not corrupt the file allowing gunzip to run without a premature end of file error. Some of the other files from the URL such as table.10.gz and table.16.gz exhibit the same behavior. Ideas?
Jason
http://vizier.cfa.harvard.edu/viz-bin/ftp-index?/ftp/cats/J/A%2bA/424/919/x70z02
Notice the file size increases by 1 after a copy. The UNIX cp command does not corrupt the file allowing gunzip to run without a premature end of file error. Some of the other files from the URL such as table.10.gz and table.16.gz exhibit the same behavior. Ideas?
Jason
Mike Fitzpatrick wrote on Apr 30, 2006
This is a side-effect of the size of an SPP character (two bytes) meaning that iraf file i/o can't write an odd number of bytes to a file. In most cases the extra NULL is harmless but this is one case where a host program doesn't like it (another being some tasks reading the GIF images produced by EXPORT, however there a "null extension" is actually in the gif spec but rarely implemented as legal).
Changing the size of an spp char is a one-line change, but after 20 years there may be untold numbers of unintended consequences in other tasks. OTOH, we're in good shape to start using unicode chars in the system 8-) Simplest thing is to just use 'cp' for binary files, it's a default foreign task and is readily available.
-Mike
P.S. Note: This isn't a file corruption of any kind, it is just that there is an extra NULL byte on the file in the event the input file was an odd size.
Changing the size of an spp char is a one-line change, but after 20 years there may be untold numbers of unintended consequences in other tasks. OTOH, we're in good shape to start using unicode chars in the system 8-) Simplest thing is to just use 'cp' for binary files, it's a default foreign task and is readily available.
-Mike
P.S. Note: This isn't a file corruption of any kind, it is just that there is an extra NULL byte on the file in the event the input file was an odd size.
Jason Quinn wrote on Apr 30, 2006
fitz
This is a side-effect of the size of an SPP character (two bytes) meaning that iraf file i/o can't write an odd number of bytes to a file.
Thank you, Mike. Wow! I consider myself pretty good at IRAF and I can't believe that I never noticed this or that it never caused me a problem before. Hmmm... I better doublecheck some of my scripts.
fitz
we're in good shape to start using unicode chars in the system
Until that happens, perhaps the help file for copy should include a BUGS section.
Big thanks,
Jason
Last post on Apr 30, 2006