valerie@.cs.umass.edu (Valerie Caro) (11/02/90)
I have written a program that converts a data file in one format to another format. The source file is a KBVISION Tokenset file and the output format is an ISR2 frame file. (If these terms don't mean anything, that is ok - they are two different, but conceptual simular DB files used in computer vision research.) My program uses a supplied library to read in the KBVISION file and uses fwrite() to write out the output file. The program works fine on a Sun4 runninf SunOS 4.1. The problem is on the DECStation. We have three DECStation 5000/200s running Ultrix 4.0. Each machine has a local disk and the disks are cross mounted with NFS. We also have a 12 member VAXCluster (mostly VAXStation 2000s, with 2 MVIIs and a VAXStation 3100). Some of the VAXes run UCX and all of the VMS user disks are NFS exported and mounted on the DECStations. When I run the program on one of the DECStations with the output file on a NFS mounted VMS disk, the program works correctly and produces a corectly sized output file, which can be successfully read in by the ISR2 system. When I set the output to a local disk, I get a file that is slightly shorter and at least the beginning of the file is crupted. When I set the output to a NFS mounted disk on one of the other DECStations, the file is even shorter and is also crupted. I am pretty sure it is not my program, since it works perfectly on the Sun4 and on the DECStation when the output file is in a NFS mounted VMS file system. I am not much of a UNIX user (been using VMS for some time now and only started using UNIX recently) and don't have the slightest idea where to look. Robert Heller ARPANet: Heller@CS.UMass.EDU BITNET: Heller@UMass.BITNET BIX: locks.hill.bbs GEnie: RHeller FidoNet: 1:321/153 (Locks Hill BBS, Wendell, MA) CompuServe 71450,3432 Local PV VAXen: COINS::HELLER UCC Cyber/DG: Heller@CS
heller@cs.umass.edu (From the screen of Deneva...) (11/12/90)
To: mjr@decuac.DEC.COM (I tried to send this direct, but it kept coming back - it seems that "decuac.DEC.COM" is down. I don't know were else to send it to. I'm hoping that mjr is reading comp.unix.ultrix on some machine somewhere.) >> Uhm, are the data blocks being written some kind of C-type data >>structures ? If you write code like: >> >>struct ff { >> int x2; >> char tag; >>} xx; >> >>write(fd,&xx,sizeof(xx)); No, this is not what I am doing. Most of the fwrite()'s are actually writing one byte at a time. I know about byte order and variations in sizeof(int) - the code is explicitly written to normalize this. The only time I'm calling fwrite() with a size greater than one is when I'm writing arrays of either characters (ASCII strings) or arrays of unsigned bytes (generally arrays of bits that have been built with the "correct" bit and byte order). For everything else I am using these functions: write_byte8(file,value) FILE *file; unsigned char value; { if (fwrite(&value,1,1,file) < 1) return(0); else return(1); } write_byte16(file,value) FILE *file; short int value; { if (!write_byte8(file,(value & 0x00ff))) return(0); if (!write_byte8(file,((value >> 8) & 0x00ff))) return(0); return(1); } write_byte32(file,value) FILE *file; long int value; { if (!write_byte8(file,(value & 0x00ff))) return(0); if (!write_byte8(file,((value >> 8) & 0x00ff))) return(0); if (!write_byte8(file,((value >> 16) & 0x00ff))) return(0); if (!write_byte8(file,((value >> 24) & 0x00ff))) return(0); return(1); } write_float32(file,value) FILE *file; float value; { union { long int l; float f; } fl_union; fl_union.f = value; return(write_byte32(file,fl_union.l)); } I know that this is not real effiencient, but this is portable and byte order independent (the only non-portable function is write_float32() - this would only be a problem if I were to run this on a VAX - all of the other machines involved (TI Explorer LISP machines, Suns, and DECStations) use the same sort of FP rep. - IEEE - we won't be running this code on a VAX, since the KBV package is not available (and probably won't ever be available) on VAXes). All of the higher level structures beyond ASCII strings and arrays of bytes, are written out piecemeal using the above functions. What is real strange is the fact the files are different on different file-systems, even when the program is run on the SAME machine, without re-compiling or re-linking. That is, fwrite() is behaving differently depending on where it is writing to, not where it is writing from. The implication is that the problem is in the file-system, kernel, or device driver. If this is the case, then we could come in one morning and find ourselves with a bunch of trashed file-systems. A very scary thought... Robert Heller ARPANet: Heller@CS.UMass.EDU BITNET: Heller@UMass.BITNET BIX: locks.hill.bbs GEnie: RHeller FidoNet: 1:321/153 (Locks Hill BBS, Wendell, MA) CompuServe 71450,3432 Local PV VAXen: COINS::HELLER UCC Cyber/DG: Heller@CS