igug@ingr.com (Igug Moderator) (05/26/89)
Would someone clarify something for me? Over a period of time I understand that a directory file will continue to grow as new inode slots are added. When the files in a directory get deleted and the inode is nulled out, the size of the directory yet remains the same. Fine, now when I begin to add files again are the old slots, that were nulled, reused in the same sequence? Also, will I encounter 'file system indirection' only when I access a file that has its inode in the 321st slot? Also, can I look at a directory file with fsdb and can anyone recommend a good book that covers use of fsdb. Thanks
linwood@b11.ingr.com (Linwood Varney) (05/31/89)
In article <5434@ingr.com> igug@ingr.com (Igug Moderator) writes: >Over a period of time I understand that a directory file will continue >to grow as new inode slots are added. When the files in a directory >get deleted and the inode is nulled out, the size of the directory yet >remains the same. Fine, now when I begin to add files again are the >old slots, that were nulled, reused in the same sequence? When a file is created, the first nulled out entry is used. >Also, will I >encounter 'file system indirection' only when I access a file that has >its inode in the 321st slot? What do you mean by file system indirection. the first 64 directory entries are stored in 1 logical block (1K) of data on the disk. the next 64 in another and so on. After 10 logical blocks are used, a file system indirect block has to be read to get to the next 512 (1K) blocks. This is the struct for System V 1K File Systems. Fast File Systems look much different. >Also, can I look at a directory file with fsdb and can anyone recommend >a good book that covers use of fsdb. The easiest way to look at directories is with od -c first 2 bytes, inode number, next 14 bytes, file name. 16 bytes per record. - linwood
goldfarb@farbmac.UUCP (Benjamin I. Goldfarb) (06/01/89)
In article <1545@doctor.ATT.COM>, bmadhyan@doctor.ATT.COM (Bharat Madhyani ) writes: > Every directory entry is 16 bytes long. First 2 bytes are for the inode# > and the rest of the bytes (i.e 14) are for the filename. In Unix no > filename can exceed more than 14 characters. If the filename is less > than 14 characters , it is appended by null characters. Funny. I was just sitting here on my Berkeley 4.3 system editing a file called ThisGuysGotANarrowViewOfUnix, which sorta exceeds 14 characters, and when I did an ls it sorta appeared in its entirety. Is my UNIX brain-damaged? (All right, guys...no comebacks about Berkeley bogosity!) For your enlightenment, Bharat: Berkeley has allowed 255 character file names since 4.2 whether anybody likes it or not. Portability is obviously compromised when file names longer than 14 characters are used but that still doesn't validate your incorrect statement. -- ------------------------------------------------------------------------------ Ben Goldfarb uucp: {decvax,peora}!ucf-cs!farbmac!goldfarb Department of Computer Science Internet: goldfarb%farbmac.uucp@ucf-cs.ucf.edu University of Central Florida BITNET: GOLDFARB@UCF1VM