Ideas for changes to Unix filesystem

[Richard M. Mathews]

brnstnd at kramden.acf.nyu.edu (Dan Bernstein) writes:

>sef at kithrup.COM (Sean Eric Fagan) writes:
>> jeremy at socs.uts.edu.au (Jeremy Fitzhardinge) writes:
>> >1 - a flink(char *path, int fd) system call/operation.
>> This, while not necessarily a bad idea, is not necessarily a *good* idea.
>> You are not going to be able to do it for any arbitrary path and
>> file descriptor (since you have problems with mount points still, just like
>> normal links), and some of the objects don't make a whole lot of sense as
>> files.

>You're describing exactly the limitations on link(). What's wrong with
>that?

With link() you have a pathname to the file, so you have some idea where
you can put the new link().  Presumably with flink(), you are using this
call because you DON'T have a pathname.  Since you don't know where the
file came from, you have to do more work to figure out where it can go.

Now I'll rebut my own statements above.  Perhaps the real reason you are
using flink() is that the file has ZERO links.  You know where it WAS,
so you know where you can put it back as well as you do with link().
Flink() has some real use here.

I agree that flink could be useful, but as I've pointed out elsewhere,
I am slightly worried about its possible use to violate security.  On
the other hand, given the weak security of most Unix systems, this small
chance of opening a hole is nothing.

Richard M. Mathews			 Freedom for Lithuania
richard at locus.com				Laisve!
lcc!richard at seas.ucla.edu
...!{uunet|ucla-se|turnkey}!lcc!richard