minimal loss of information when deallocating inodes?
Robert Breckinridge Beatie
breck at aimt.UU.NET
Thu Jan 5 06:41:46 AEST 1989
In article <981 at vsi.COM>, friedl at vsi.COM (Stephen J. Friedl) writes:
>
> It seems to me that marking the mode field to zero is sufficient
> for this, as any other kind of file has at least one high-order
> bit set (even regular files). This is from <sys/stat.h> from
> System V:
>
> #define S_IFMT 0170000 /* type of file */
> #define S_IFDIR 0040000 /* directory */
> #define S_IFCHR 0020000 /* character special */
> #define S_IFBLK 0060000 /* block special */
> #define S_IFREG 0100000 /* regular */
> #define S_IFIFO 0010000 /* fifo */
>
> Comments?
Not so much a comment as a question. I was looking into this question
the other day and was not able to find a completely satisfactory answer.
According to the SVID MKNOD(BA_OS)
The mode of the new file is initialized from the argument
_mode_. Where the value of _mode_ is interpreted as follows:
0170000 file type; one of the following:
0010000 FIFO-special
0020000 character-special
0040000 directory
0060000 block-special
0100000 or 000000 ordinary-file
^^^^^^
(Unfortunately, I wasn't able to find anything more useful.)
Now it doesn't say anything about the mode parameter being placed
directly into the di_mode field of the disk inode, but it doesn't
say that it won't either. Well, I assumed that calling mknod with
the mode field set to 000xxxx creates a file with mode equal to
010xxxx and that inodes whose di_mode field are zero are in fact
unallocated since that seems to be the case on most systems I've
checked. But is there any guarantee that on a "normal" system V
file system this assumption won't blow up in my face.
A pointer to the appropriate section in the SVID would be most
reassuring. Assurances from a few wizards would be somewhat less
reassuring, but would definitely be appreciated.
--
Breck Beatie (408)748-8649
{uunet,ames!coherent}!aimt!breck OR breck at aimt.uu.net
"Sloppy as hell Little Father. You've embarassed me no end."
More information about the Comp.unix.wizards
mailing list