GNU bug report logs - #6900
mktemp: want option to make a fifo

Previous Next

Full log

Message #17 received at 6900 <at> debbugs.gnu.org (full text, mbox):

From: John Reiser <jreiser <at> bitwagon.com>
To: Eric Blake <eblake <at> redhat.com>
Cc: 6900 <at> debbugs.gnu.org
Subject: Re: bug#6900: mktemp: want option to make a fifo
Date: Mon, 23 Aug 2010 13:40:34 -0700

On 08/23/2010 11:00 AM, Eric Blake wrote:
  [snip]
> If we add 'mktemp --fifo', then where do we stop?  What about creating a
> uniquely named symlink?  Or a new shared memory object?

There are several possible answers to "Where do we stop?".

1) Stop at current code [no changes.]

2) Stop when user requests stop.

3) Add --symlink and --hardlink.  Each requires another string argument.
   Limiting the number of string arguments is a defensible argument:
   it is based on an extrinsic property.

4) Add --block and --character device nodes.  Each requires two
   non-negative integer arguments, and mktemp should check this
   in order to provide good Usability.

5) Stop when all file types of S_IFMT (<stat.h>) have been covered.
   This would add S_IFSOCK, which is gnarly indeed.

6) Stop after shmem, which is not even a file type.

I favor drawing the line between 2) and 3), which means adding --fifo
and not the others.  Two independent user requests [one of which
includes code!] within a few months show a definite need.

> http://lists.gnu.org/archive/html/bug-coreutils/2010-06/msg00033.html
> 
> And did you not read in that thread about the arguments that recursively
> moving an entire temporary directory hierarchy with 'rm -rf dir' is just
> as short in shell code as 'rm -f fifo'?

The user of such a fifo must be taught that one unlink() or "rm -f fifo"
does recover all the resources.  That is a significant reduction in
*each* of the five software metric dimensions: Functionality, Usability,
Performance, Maintenance, and Supportability.  The hard task is finding
all the places that [should] remove objects from the filesystem, and
teaching them to remove the directory of such a fifo, too.  For shell,
a dirname() must be applied.  For C code, then the code must figure out
[or be told] that the name is special, parse the name, and perform another
unlink().  This is not trivial.

>   A couple kilobytes of disk
> space for a temporary directory given today's storage technologies is
> not a very convincing argument.

One of the places where I want such fifos [many hundreds of them]
is in a filesystem that resides on a much smaller flash memory device.
Occupying a megabyte more than necessary can be fatal.

> The whole argument of Unix is that each tool does one thing well, so
> that the combination of tools can do everything.  mktemp should NOT be
> bloated just to reproduce the functionality of mkfifo or of ln, when
> those tools can already be paired nicely.

It's not nice to get a compound object (directory plus fifo) when a
singleton is expected, and when the compound object cannot be treated
identically to the singleton.  The properties are different,
not "reproduced"; and that makes it not "bloat."

-- 

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.