Path: utzoo!mnetor!tmsoft!torsqnt!lethe!yunexus!ists!helios.physics.utoronto.ca!news-server.csri.toronto.edu!cs.utexas.edu!usc!elroy.jpl.nasa.gov!turnkey!orchard.la.locus.com!fafnir.la.locus.com!fafnir.la.locus.com!richard From: richard@locus.com (Richard M. Mathews) Newsgroups: comp.unix.internals Subject: Re: Ideas for changes to Unix filesystem Message-ID: Date: 7 Feb 91 03:13:35 GMT References: <1991Jan30.143326.16676@socs.uts.edu.au> <1991Feb04.004933.17253@kithrup.COM> <17698:Feb511:37:2791@kramden.acf.nyu.edu> Organization: Locus Computing Corporation, Los Angeles, California Lines: 33 brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >sef@kithrup.COM (Sean Eric Fagan) writes: >> jeremy@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@locus.com Laisve! lcc!richard@seas.ucla.edu ...!{uunet|ucla-se|turnkey}!lcc!richard