> 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;
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