>> funlink makes no sense, unless [...]
> I've wanted an fclri(fd)

This actually isn't as impossible as you make it sound.  Just provide a
new vnode flag - VCLEARED, say - which is set on the vnode.  The
underlying inode (or whatever, for other filesystems) is then blown
away.  (This may require a new VOP_*.)  Attempts to do anything with a
VCLEARED vnode error out.

>> I've often wanted open-with-no-access in conjunction with fchdir().
>> This is because you need only execute access to set your cwd to a
>> directory, but there's no way to get an fd on a mode-111 directory.
> Playing the Daemon's advocate, here...
> What use is a descriptor into a directory you can't read?

You can access things through it.  This is the difference between the
0444 and 0111 bits on a directory, basically.

> What's the point of fchdir(dd->fd) if you can't figure out where
> you're going from there?

Presumably you already *know* where you're going from there.  For
example, if you wish to save your current directory for a later return,
open(".",O_NULL,0) is just what you want.  If the directory is 111, you
can't open it O_RDONLY, but it does make sense to want to return to it
(for example, to interpret later command-line arguments).

> You may as well use chdir(dir).

Only if (a) you have a path that refers to it and (b) you can walk that
path.  Either or both of these may be false.

>> I can't see any use for opening a symlink except use of write() to
>> atomically make the link point somewhere different, and I'd prefer
>> to do that by making symlink() do that when the link already exists
>> and some appropriate condition is met.
> That's a dicey proposition.

Oh, certainly.  That's one reason I haven't implemented it myself.  But
now that symlink mode bits (optionally) mean something, there's no
meaning attached to the 0222 bits, and this seems like the logical
thing for them to mean....

>>> Of course, you'll want to be able to fcntl(fd,F_SETFL,O_RDWR) or
>>> something equivalent, to upgrade your access mode on a file you
>>> opened with O_NULL.
>> The security weenie in me is _really_ unsure that the ability to
>> increase the access modes on an open fd is a good idea.
> Nah.  fd's are inevitably associated with vnodes (which don't get
> freed until the last close()); if the vnode doesn't map out to the
> appropriate permissions, the fcntl() would fail.

That doesn't make it ok.  If I run "foo < z.1 > z.2", it *really*
disturbs me to think that the process can use that read-only fd I give
to it to write....

>>> Finally, we discussed about saving _and restoring_ the state of a
>>> process, another hack that he did once to preserve a long-winded
>>> calculation from the service shutdown of a big unix computer.
>> I did this once, long long ago, [...].  As for the open file
>> descriptor question, I punted - I made the relevant call fail unless
>> the process had no fds open.
> Yeah, there's just no way to restore fd state from saved state,

Especially for fds open on things other than files, like sockets or
ttys or tapes or ....

> "{,f}chmod(path, mode);" certainly codes easier than 
> "setfopt({path,fd}, SFO_CHMOD|SFO_{PATH,DESC}, mode)".

> And "getfopt(path, SFO_NOFOLLOW|SFO_PATH, sp);" vs "lstat(sp);"?  Or
> "setfopt(fd, SFO_DESC|SFO_CHDIR, dir)" vs "fchdir(fd);"???

> [I hope it's obvious why the SFO_PATH and SFO_DESC would be necessary
> in the aforementioned cases.]

Actually, it would have to be

	setfopt(SFO_CHMOD|SFO_{PATH,DESC},{path,fd},mode)
and
	setfopt(SFO_CHDIR|SFO_DESC,fd,dir)

because the pointer and the int do not necessarily take up the same
space in the arglist....

					der Mouse