Neville Smythe wrote: > Actually I just did a hex dump of the 8MB file saved from the 1 card > stack; and lo! it has an EOF at about the 28KB position, at which > point BBEdit stops dumping the file; up to that point it appears to be > the correct data for a 1 card stack, no extraneous garbage. But the > system reports it as an 8MB file. Doesn’t that mean the file was not > closed correctly by the save stack command, or that compact stack is > not working correctly to reduce the internal memory and save stack is > blindly writing bytes beyond the EOF, so either way it is a bug?
Possibly. Or it may be an error in the disk driver or a corruption in the file system.
EOF is not normally written to a file (at least not since the old CP/M days). My understanding is that modern file systems allow the OS to know where the file ends by the length record in the inode; EOF is sent only as a flag by the OS during read operations.
I wonder if BBEdit's issue is that it's reading the file as text rather than binary, in which case it may be interpreting some binary elements as the OS-defined EOF constant.
If you read the stack file as binary in LC what is the length of the data? -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ____________________________________________________________________ ambassa...@fourthworld.com http://www.FourthWorld.com _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
