Re: link() security

["H. Peter Anvin" <hpa@zytor.com>]

Followup to:  <s5g3cxwk8bv.fsf@egghead.curl.com>
By author:    "Patrick J. LoPresti" <patl@curl.com>
In newsgroup: linux.dev.kernel
> > 
> > It depends on your access patterns.  Newer news server use what I
> > would classify as custom filesystems (which is what binary databases
> > are, by and large) rather than "single files."
> 
> Exactly.  Although I would go farther.
> 
> I would not be at all surprised if a traditional news spool worked
> just fine on a "real" high-performance file system; i.e., one whose
> lookup/creat/unlink was not linear in the number of directory entries.
> I wonder how well an old-fashioned news spool would perform on XFS,
> for instance.
> 
> "One file per message" has many advantages, both for news and for
> mail.  The biggest advantage is conceptual simplicity.  It is really
> nice when you can use traditional Unix tools (like grep, mv, rm) to
> fix things when they break.  Because they always break, sooner or
> later.
> 
> Sure, you may wind up with 50,000 files in one directory.  But I would
> rather rely on the filesystem wizards to deal with that than switch to
> some obscure custom database format.  Maybe that's just me...
> 

I think the biggest problem with the one-file-per-message format is
that you still want to maintain some kind of metadata (.overview
files.)  This is cached information, but still needs to be maintained,
so you don't end up opening up every file to get the overview data.
With a application-specific store, you can make that more explicit.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<amsp@zytor.com>