Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!spool.mu.edu!uunet!decwrl!ucbvax!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: <15455:Feb1010:35:0491@kramden.acf.nyu.edu>
Date: 10 Feb 91 10:35:04 GMT
References: <richard.665739383@fafnir.la.locus.com> <1991Feb5.223232.21632@odin.diku.dk> <27B18AD8.2F15@tct.uucp>
Organization: IR
Lines: 22

In article <27B18AD8.2F15@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes:
  [ on flink() ]
> It's a convenient way to create lock files -- if, that is, the kernel
> also supports fdcreat(), which creates a plain file with no links.

A few months ago I briefly discussed with Keith Bostic the top three
calls on my BSD-extensions list: fdlink(), fdtemp(), and fdunlink(). The
first was the same as flink(); the second was the same as fdcreat(); the
third was the same as unlink(), but returned a file descriptor pointing
to the removed file. He didn't believe that my examples of race
conditions were problems in practice.

> Also, the obvious companion fdunlink(int fd, char *path) is something
> I've always wanted.  It unlinks the given path if and only if it is a
> name for fd.

Hmmm. I already have fdunldilink() listed; it only removes a file if it
has a specified number of hard links, device, and inode, with 0 for no
restriction. I think fdunldilink(0,st.st_dev,st.st_ino,path) would do
the trick after an fstat(fd,&st).

---Dan