Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!uunet!snorkelwacker.mit.edu!hsdndev!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.unix.internals
Subject: Re: Ideas for changes to Unix filesystem
Message-ID: <17698:Feb511:37:2791@kramden.acf.nyu.edu>
Date: 5 Feb 91 11:37:27 GMT
References: <1991Jan30.143326.16676@socs.uts.edu.au> <1991Feb04.004933.17253@kithrup.COM>
Organization: IR
Lines: 20

In article <1991Feb04.004933.17253@kithrup.COM> sef@kithrup.COM (Sean Eric Fagan) writes:
> In article <1991Jan30.143326.16676@socs.uts.edu.au> 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?

Here's one use of flink(): You run ``rmprotect foo bar'', where foo and
bar are important files that you want to make sure you never delete.
rmprotect periodically checks the number of links on foo and bar; if
they ever disappear, it puts them back and sends you mail. The only way
to do this without flink() is to waste some directory space elsewhere
for extra links, and then you don't get the same reliability.

---Dan