Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!apple!usc!cs.utexas.edu!uunet!munnari.oz.au!yoyo.aarnet.edu.au!sirius.ucs.adelaide.edu.au!levels!xtdn
From: xtdn@levels.sait.edu.au
Newsgroups: comp.unix.internals
Subject: Re: Ideas for changes to Unix filesystem
Message-ID: <15878.27b3841d@levels.sait.edu.au>
Date: 9 Feb 91 05:09:49 GMT
References: <1991Jan30.143326.16676@socs.uts.edu.au> <121494@uunet.UU.NET> <richard.665896876@fafnir.la.locus.com> <BZS.91Feb7163251@world.std.com>
Organization: University of South Australia
Lines: 18

bzs@world.std.com (Barry Shein) writes:
> But if it can be flink()'d at all then we assume you could seek to
> zero and copy all the data out of the file to your own file anyhow, so
> that's not a new opportunity. And whether you can read or write is
> dictated by the setting of the inode and how the original fd was
> opened which is independent of flink() entirely.

Copying a file now gives access to the current contents later.  Flinking
a file now could give access to the future contents of that file.  This
may not be desirable.  It is, however, unlikely to be a major problem to
the aware programmer: an appropriate file mode solves all!

I do like the idea of flink().  The suggestion (I forget whose it was)
of fdunlink() seems appropriate, too; it sounds quite balanced.

David Newall, who no longer works       Phone:  +61 8 344 2008
for SA Institute of Technology          E-mail: xtdn@lux.sait.edu.au
                "Life is uncertain:  Eat dessert first"