bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: new module for temporary files in temporary directories


From: Paul Eggert
Subject: Re: new module for temporary files in temporary directories
Date: Wed, 28 Jun 2006 16:11:14 -0700
User-agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux)

Bruno Haible <address@hidden> writes:

> I'd like to propose a module which supports temporary directories,
> and cleans them up either upon request or at a fatal signal.

This sounds like a good module to have.  I like the idea of putting
all the temp files into a subdirectory.

Some problems I noticed:

* The GNU coding standards say that one shouldn't use "path" to
  describe a file name; "path" should be used for things like PATH
  instead, which are lists of file names.  Several of the comments and
  names of functions etc should be changed accordingly.

* When 'sort' removes a temporary file in ordinary computation
  (outside a signal handler), it wants to know if 'unlink' failed so
  that it can issue a diagnostic (e.g., an I/O error occurred).  The
  proposed API doesn't seem to allow for this.  Similarly for 'rmdir'.

* 'sort' creates and remove temporary files in a certain order,
  and its asymptotic performance relies on the internal data structures
  (linked lists) accommodating this order.  I suppose I'll have to
  review the proposed code to see whether it has similar asymptotic
  behavior.  The basic problem here occurs when one has many, many
  temporary files.

* Why do the functions have 'queue' in their names?  Files don't
  have to be removed in a FIFO order.
  
> Btw, this would also be good behaviour for the 'sort' program: Often,
> when I shutdown my machine while an 'updatedb' process is in progress,
> several big sortXXXXXXX files are left over in $TMPDIR.

'sort' already does something similar to what the new module does: it
removes its temporary files when it gets a signal.  So I don't see how
this module would fix that problem.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]