In message <20937.852201353@heron.pst.cfmu.eurocontrol.be>  Jim Reid wrote:
> >>>>> "Stefan" == Stefan Grefen <grefen@hprc.tandem.com> writes:
> But you can diddle this with utimes or fiddling with the TOD clock.

Sorry, that wouldn't work. utimes can't modify st_ctimespec. Playing
with TOD involves root priveliges. So I don't consider it here.

> 
>     Stefan> A more convenient way to do that, would be to return the
>     Stefan> inode-generationnumber in the result of readdir().
> 
> That introduces other security holes. Once the generation number is
> known - I know BSD fills it in for the stat struct - you can forge NFS
> file handles.

If knowing the generation number is a security hole a lot of things are
broken. security by information hiding is bad practice. If you're concerend 
about security forget NFS in the first place.
There are a lot easier methods to get NFS filehandles than to reverse
engineer the source .... 

> 
>     Stefan> The goal should be to enhance the definition of an inode
>     Stefan> (which is included in the readdir() result) to uniqly
>     Stefan> define a file (on the disk AND in the time-domain).  This
>     Stefan> can easily be done by adding the msec time at the time of
>     Stefan> creation to the inode (plus workarounds for reboots,
>     Stefan> broken clocks etc.) and a machine or disk ID to avoid
>     Stefan> problems moving disks, between machines.
> 
> This is getting very, very silly. There's nothing wrong with the way
> an inode is just now. LEAVE IT ALONE.

There are a few shortcomings in the current definition of the inode-number.
(I should have written inode-number not inode ....). One is that a soon as 
the kernel gives you one (let's say through readdir()) there is NO guratee
this information is valid when your program examines it.
HSM system have run into that problem a long time ago, as the files may
actually not reside on disk (but in secondary (tape)storage, and may take
hours to come back to disk).

> 
> Also, you don't seem to have thought through your suggestion. [inodes
> don't have a creation time, unless you consider the 4.4BSD di_gen
> field of a dinode as such.] What do you do about files restored from
> backups: will they get the creation time the backup was restored or the
> one when the original file was created?

I was talking about the inode-number and you could expand it to a handle 
containing various things. Using the creation timestamp as a part of a unique 
handle is common procatice for such things (Unitree,DCE, ....)

> 
>     Stefan> Than add operations that can work on this handles (either
>     Stefan> by using a a NOIO open or be different/additional
>     Stefan> arguments to existing systemcalls).  A very elegant
>     Stefan> solution would be a unique-inode-filesystem.  You could
>     Stefan> even use sh,ls and rm than to securely remove files: (lets
>     Stefan> assume -I means display unique-inode).
> 
>     Stefan> This would only remove the file /tmp/xx which existed at
>     Stefan> the time of the ls.  Regardless if it is issued
>     Stefan> immediately or a year after the ls.
> 
> If you want that sort of functionality, put it in the applications
> which need it. It doesn't belong in the filesystem. Once upon a time
> UNIX was a simple OS which just did what it was told. Some people seem
> to have lost sight of that stunningly elegant concept.

Once upon a time disk were small, machines were slow and memory always
full. Do you want that back too? 
Some of those holes are actually 'usable' only because the machines became 
too fast.
On the other hand once upon a time (nearly) every things was file, and
a ufs-namespace object. Want to give away sockets???

We need to address those fundamental problems, and there is NO way to keep
the state of a filesystem-object stable until a user programm does something
to it, without major headaches (Holding a kernel-lock on a file and exiting
to user-land opens a pandaora-box of deadlocks ...).
Making the inode-number a unique handle solves the problem without those 
side-effects.
Also it can be done without changing to much code. It is just additional
information.

Stefan

--
Stefan Grefen                                Tandem Computers Europe Inc.
grefen@hprc.tandem.com                       High Performance Research Center
You should never bet against anything in science at odds of more than
about 10^12 to 1.
                -- Ernest Rutherford