[Raw Msg Headers][Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: malformed i-node-names at "TRANSPORT" directory ...



On Fri, Sep 01, 2000 at 01:24:28PM +0200, Arnt Gulbrandsen wrote:
> Matti Aarnio <mea@nic.funet.fi>
> >   However I don't know any LOCAL filesystems which exhibit this behaviour,
> >   and I do believe that even NFS is sane in this regard.
> >   Any other possibilities ? Anyone ?
....
> rename() and stat() can go wrong IRC, of course, and need result
> checking.  The link()/unlink() pair aren't ever going to be tested,
> I'd guess, so keep it simple.
> 
> (Do I even understand the problem correctly?)

	Maybe, close to.
	I just would like to minimize directory access syscalls to
	POSTOFFICE/ filepaths, which means  stat()  is no good,
	fstat() is better (open filehandle, and all that).

	Do keep in mind that all this is hearsay from comments that
	exist at zmailer 2.2.1 libc/mail.c  (yes, THAT old..)

	Therefore I would like to know if there really exists such
	monsters, and how come  rename()  won't preserve i-node
	while link()/unlink() will ?

	I can imagine many filesystems at which link()/unlink() won't
	work, and where the i-node number depends on where on the disk
	the directory entry for it is located at so that it changes at
	every rename() when e.g. BTREE is reorganized or file is moved
	from one storage partition (server) to another.  But then such
	systems are NOT suitable for POSTOFFICE to begin with..
	(AFS, CODA, possibly MS NTFS to name a few.)

	... I take that back a bit.  The message submission is the only
	phase in the system which makes such file systems unsuitable.
	Latter router and scheduler will preserve the numeric string
	representing the unique file identity.
	(Performance may also be bad - at least at AFS and CODA for
	 POSTOFFICE like operations, but that is irrelevant here.)

	For message submission some method could be found that creates
	unique numeric strings (possibly recurring, like i-node numbers,
	but unique for the message lifetime) in some platform specific way.
	Current one assumes certain class of UNIX local filesystems.

	What *must* be guaranteed is that the same name won't recur
	while the message is in processing, although not in any of
	$POSTOFFICE/router*/ dirs.

	System needs more work if the basic rule of "work files are
	named with all decimal number characters" should be relaxed.


>  --Arnt

-- 
/Matti Aarnio	<mea@nic.funet.fi>