dillon@EDEN.BERKELEY.EDU (Matt Dillon) (12/21/88)
What happens when you SetComment() a comment that is larger than the field can hold on the file inode? In my case it created a spectacular crash when I got a directory after doing the SetComment() (which worked). *C-R-A-S-H*, reboot (asked for kickstart, in fact), chug chug chug, disk-validator run run run. ok, all done. cd to the directory, Dir .... *C-R-A-S-H*, reboot chug chug chug ... no disk-validator this time. Hmmm.... Time for DiskED DiskED: search through and find the directory. Look at the hash table, find the file in question. "GEE, it looks like the filesystem blithly copied the too-large comment out into the filename and remaining fields of the file header!" (actually, my exact words were more colorful). Well, that is what caused the first crash ... totally destroyed checksum and whatever other fields are at the end of a file header. The disk validator fixed the checksum and those fields, but DID NOT fix the filename! Not only was the BCPL length of the filename x67, but now the hash value was all wrong (of course) and thus Delete could not delete it. Ok, modify the filename to "A" (0165), move the file header pointer in the directory's hash table to the right place and delete the file. Back to normal. (1) SetComment() shouldn't let you do that. (2) The Disk-Validator should check for impossible filename lengths, but more especially, should make sure the HASH VALUE corrosponds to the filename. P.S. Good Job to C-A on the 1.3 enhancer kit! I like the revised autodocs and the printer driver examples! -Matt
w-colinp@microsoft.UUCP (Colin Plumb) (12/21/88)
Gee, and I was just wondering about this! If someone tries to set a filename or comment that's too long, should you: - return an error - truncate it, change it, and return an error, or - truncate it, change it, and return no error? Also, how doess one interrogate to find the longest legal filename length? As part of the error passed back on failure or truncation would be fine in most cases. -- -Colin (uunet!microsof!w-colinp)
andy@cbmvax.UUCP (Andy Finkel) (12/23/88)
In article <8812210016.AA07200@eden.berkeley.edu> dillon@EDEN.BERKELEY.EDU (Matt Dillon) writes: > > What happens when you SetComment() a comment that is larger than >the field can hold on the file inode? In my case it created a spectacular >crash when I got a directory after doing the SetComment() (which worked). > > (1) SetComment() shouldn't let you do that. Fixed in the FastFileSystem. *poof* :-) -- andy finkel {uunet|rutgers|amiga}!cbmvax!andy Commodore-Amiga, Inc. "Possibly this is a new usage of the word 'compatible' with which I was previously unfamiliar" Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) (12/23/88)
:In article <8812210016.AA07200@eden.berkeley.edu> dillon@EDEN.BERKELEY.EDU (Matt Dillon) writes:
:>
:> What happens when you SetComment() a comment that is larger than
:>the field can hold on the file inode? In my case it created a spectacular
:>crash when I got a directory after doing the SetComment() (which worked).
:>
:> (1) SetComment() shouldn't let you do that.
:
:Fixed in the FastFileSystem. *poof* :-)
:--
:andy finkel {uunet|rutgers|amiga}!cbmvax!andy
When was it fixed? I am now using the release FFS... it is possible
I was using a late omega when the problem occured.
-Matt