Path: utzoo!mnetor!tmsoft!torsqnt!lethe!yunexus!ists!helios.physics.utoronto.ca!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!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: 8 Feb 91 23:47:02 GMT References: <1991Feb04.004933.17253@kithrup.COM> <17698:Feb511:37:2791@kramden.acf.nyu.edu> <1991Feb7.202526.18893@Think.COM> Organization: Locus Computing Corporation, Los Angeles, California Lines: 38 barmar@think.com (Barry Margolin) writes: >In article richard@locus.com (Richard M. Mathews) writes: >>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. >What do pathnames have to do with "where you can put the new link"? You >can put the new link anywhere on the same file system as the file. Due to >symbolic links, it is not possible to determine whether two files are on >the same file system simply by looking at the pathnames. >Presumably one of the first things that the link() system call does is I get the feeling that you thought I meant that the flink system call wouldn't be able to figure out where the link is allowed to go. That isn't what I meant at all. The "you" in my quote above refers to application programs which try to make general use of flink on a random file descriptor. I meant that a possible application of flink would NOT include a general purpose program which would flink its stdin to some file to allow it to reopen the file in a different mode (e.g., "more" wants to read stderr (at least it did at one time), so if it gets a stderr which is open for write-only, it might want an opportunity to reopen the file (terminal) for read-write). This would not be a practical use of flink because of the single file system restriction of link and flink. On the other hand, a program which knows where a file is because it created it (and thus it also knows that the original path name was not through a symbolic link) can make good use of flink to put back a file even after the link count goes to zero. Sorry, if I wasn't clear before. Richard M. Mathews D efend richard@locus.com E stonian-Latvian-Lithuanian lcc!richard@seas.ucla.edu I ndependence ...!{uunet|ucla-se|turnkey}!lcc!richard