> 
> > imagine the following:
> 
> > an additional flag for directories that make this directory "special
> > files only".  This means only files with certain characteristics are
> > allowed to be copied into this directory.  There should be a
> > additional entry in the directory inode that links to a executable
> > that tests files [...]  For changing the content of a file there
> > should be a mechanism that tests the new file before writing it back
> > overloading the open() calls.
> 
> This sounds nice, but it borders on impossible to implement.
> 
> For one thing, at the point where the directory entry is created - ie,
> inside open() - the file contents are not yet available for checking;

wouldn't it be possible to duplicate the (existing) file at the open()
call and do all write() that are needed on this "backup" then check
the file with the close() call?
you see what i mean? is it silly?

> in many cases they haven't yet been computed.  (For example, when tar
> is extracting an archive, it (usually) opens the created file before
> it's read all the data blocks that make up its contents.)
> 
> And as for modifying an existing file, this is done via open(), write()
> (usually multiple write()s), close().  Where in this sequence would the
> checking be done?  In order to check the final file contents, it has to
> be done inside close()...but at that point, not much can be done but
> blow the file away if it doesn't conform.  Besides, it's then trivial
> to defeat the checks by just holding the file open.
> 
> In short, it sounds good but I don't think it's possible to firm up the
> semantics to the point of having an implementable spec, at least not
> without completely redesigning lots of other filesystem semantics.
> 
> 					der Mouse
> 
> 			    mouse@collatz.mcrcim.mcgill.edu
> 

of course there are many things to do, handle several fileaccesses at 
the same time and so on. But would it really be so hard?
ciao
Carsten