kevin@kosman.UUCP (Kevin O'Gorman) (12/09/89)
I sent some stuff to another machine, all packed up in a .ZOO archive. BRIK says the checksums are the same, but the other machine gets a bunch of odd errors unpacking the archive. There are no troubles with the disk, but ZOO reports a fatal error, or disk full condition. The 386 is running 3.xx MSDOS, but a version that supports large disk partitions, and in fact the partition in which this was done is about 500K, with 200K actually in use. I don't remember for sure, but I think this copy of ZOO.EXE is one gleaned from c.b.i.p. some time ago. Anybody know why this is happening, or what I can do about it?
jdreyer@pdp8.East.Sun.COM (Jonathan Dreyer - Sun BOS PC Distributed Systems) (12/14/89)
In article <1046@kosman.UUCP> kevin@kosman.UUCP (Kevin O'Gorman) writes: >ZOO reports a fatal error, or disk full condition. > >The 386 is running 3.xx MSDOS, but a version that supports large >disk partitions, and in fact the partition in which this was done >is about 500K, with 200K actually in use. > >Anybody know why this is happening, or what I can do about it? Some PC-NFS customers ran into a similar problem with Zoo 2.01 writing to NFS drives on certain servers. The problem turned out to be how PC-NFS and Zoo conspired to blow away the results of a DOS FreeSpace (function 36h) call. This call returns (for our purposes) the number of sectors in an allocation unit in AX, the sector size in CX, and the number of free allocation units in BX. To find the amount of free space you must multiply the three numbers together. Unfortunately Zoo was doing the first multiplication (AX * CX) in a 16-bit short. In our case this was not a good idea because with this server the result was always zero, so Zoo always reported "not enough room" or some such. (The interesting part fell off the end of the word). Given that your DOS has been modified to allow large partitions, it's possible that it has the same problem. We solved the problem in PC-NFS by ensuring that AX * CX fits into a word, but ideally Zoo should do the entire multiplication in a long. Rahul knows of this problem, and I imagine the fix will come out in the next rev of Zoo. By the way, Zoo's behavior regarding the computation of free space is sanctioned by none other than the DOS tech ref, so one might argue that the fault is with PC-NFS and your DOS, not with Zoo, but Zoo might as well obey the robustness principle here. (un Jon Dreyer Sun Microsystems jdreyer@east.sun.com ) ( 508-671-0385 Two Federal Street sun!suneast!jdreyer un) Billerica MA 01821 "I have no claim."