Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!cwjcc!gatech!hubcap!ncrcae!ncrlnk!uunet!auspex!guy
From: guy@auspex.UUCP (Guy Harris)
Newsgroups: comp.unix.wizards
Subject: Re: minimal loss of information when deallocating inodes?
Message-ID: <804@auspex.UUCP>
Date: 5 Jan 89 08:14:27 GMT
References: <88Dec24.170417est.38019@neat.ai.toronto.edu> <981@vsi.COM> <2424@aimt.UU.NET>
Reply-To: guy@auspex.UUCP (Guy Harris)
Organization: Auspex Systems, Santa Clara
Lines: 27

>A pointer to the appropriate section in the SVID would be most
>reassuring.

The SVID doesn't say anything about the format of the file system on
disk; the 4.2BSD file system can be used in a SVID-compliant
implementation (yes, 255-character file names and all), as can, say, the
Apollo file system (they've said their SR10.1 release, or whatever the
number is, passed the SVVS).  As such, you're not likely to get any
reassurances from the SVID about what a system'll do to the mode field
of the inode... 

>Assurances from a few wizards would be somewhat less reassuring, but
>would definitely be appreciated.

...however, since it says that either 0 or 0100000 represent plain
files, and since in both the V7/S5 and 4.2BSD file systems

	1) an all-zero mode field indicates an unused inode

and

	2) 0100000 in the upper 4 bits of the mode field indicate a
	   plain file,

non-buggy systems using either of those file systems will put 0100000
field of the inode if you do a "mknod" with either 0 or 0100000 in the
upper 4 bits of the mode.