Bruno Haible <[EMAIL PROTECTED]> 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.
