[daip] OBIT

[Bill Cotton]

"EG" == Eric Greisen <egreisen at nrao.edu> writes:

EG> I have encountered 2 issues with OBIT:
EG> 1. The file sizes are exact in UV data files.  Thus they are not an 
EG> integer times 1 kilobyte as assumed in all of AIPS.  I ran the task
EG> MOVE to copy a data set - it uses the file size as returned by ZEXIST 
EG> and it failed to copy 832 bytes.  When I ran UVCOP instead it made a 
EG> file 5120 bytes larger than the one made by MOVE or 4288 than the one 
EG> made by OBIT.  It would be convenient if OBIT rounded file sizes up to N 
EG> * 1024 bytes.

   Yes, Obit doesn't have the concept of modcomp blocks (except for image 
files of course).  I was just looking at the file padding routine and I don't 
understand how I've been getting away with it for images, it uses a 32 bit 
integer for the desired size of the file in bytes.  This would have to 64 
bits to use for uv data.  I'll look into to adding this for uv data.  
   Do you pad tables?


EG> 2. The permissions on the files written by OBIT are still
EG>       -rw-r--r--
EG> which makes it hard for me to read a user's files.  I have looked at the 
EG> AIPS file permissions things.  AIPS sets umask 002 which means that 
EG> "other" will not have write permission.  In ZCREA2 we do
EG>          if ((fd = open
EG>              (pathname, O_CREAT | O_EXCL | O_WRONLY, PMODE)) == -1) {
EG> and
EG> #define PMODE (S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP | S_IROTH | S_IWOTH)

   This one bites me as well, you can't really get users to set the umask 
properly.  Unfortunately, I use fopen and friends for file I/O which doesn't 
have this capability and defaults to 666 or umask.  I'll have to see if there 
is a  portable way to set the umask from the open routine.  cfitsio has it's 
own way of doing everything so I'm not sure how to do this for FITS.

-Bill

EG> which would put on rw for everybody (except umask stops the other write).

EG> Point 2 affects me mostly and so is not so urgent but you might wish to 
EG> consider it.  Point 1 could be bad for users although it is not likely 
EG> to be.

EG> Thanks

EG> Eric