Subject: Re: Suggestion for an objectoriented ffs extension
To: None <current-users@NetBSD.ORG>
From: der Mouse <mouse@Collatz.McRCIM.McGill.EDU>
List: current-users
Date: 09/19/1995 08:44:10
>>> an additional flag for directories that make this directory
>>> "special files only".  [...]  There should be a additional entry in
>>> the directory inode that links to a executable that tests files

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

For changing an existing file, yes.  It would perhaps also be possible
to do something related when creating a new file.

It would also break some filesystem semantics that have been in UNIX
since day one, namely, that when you do something, it's done, and other
processes can see it.  For example, when you create a file with open(),
it's there in the directory.  For example, when you write to a file
with write(), the change is there in the file for others to read().

This is the sort of thing I was talking about when I said "completely
redesigning lots of other filesystem semantics".  I am very suspicious
of introducing fundamental semantic changes; such changes have a
tendency to break things in ways that aren't obvious until much later.
Look at what happened with symlinks: nobody noticed how badly the new
semantics interacted with sticky directories until the new code was out
in the real world and it was much too late to reverse the change.

>> 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, [...]
> 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?

I think it would be.  You are welcome, of course, to prove me wrong by
generating a spec firm enough to be implementable.  I'd be interested
in seeing any attempt at such a spec, successful or failed.

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu