[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
clean-temp usage question
From: |
Eric Blake |
Subject: |
clean-temp usage question |
Date: |
Wed, 4 Oct 2006 18:10:22 +0000 (UTC) |
User-agent: |
Loom/3.14 (http://gmane.org/) |
I'm trying to convert CVS M4 to use clean-tmp instead of tmpfile-safer, in part
so I can use the closeout module while minimally impacting the current code
base usage of temporary FILE* for storage of large diversions. But in the
process, I have several questions. It looks like using mkstemp
(<temp_dir.dir_name>/templateXXXXXX) is not safe; I must instead invent a name,
call register_temp_file with that name, then create the file, then
unregister_temp_file if the creation failed. When creating the name, do I have
to worry about making the name random, or can I just use sequential file names
under the assumption that the directory is already secure?
If the former, then it would be nice if there were a mkstemp-like wrapper to be
used with clean-temp that did all this work, maybe something like:
/* Like mkstemp, except that PREFIX need only point to a basename residing
inside DIR, and the created file (if successful) will be automatically deleted
when DIR is cleaned up. */
int
temp_dir_mkstemp (struct temp_dir *dir, char *prefix)
{
// pseudocode:
name = concat dir.dir_name and prefix
use gen_tempname (name)//(either from tempname.c or mkdtemp.c)
register_temp_file (dir, name)
open (name, O_CREAT | O_EXCL)
if success
{
update prefix to match created name
return fd
}
else
unregister_temp_file (dir, name)
}
And likewise for mkdtemp and tmpfile.
Also, if I keep M4's usage of FILE*, then I imagine I should ensure that each
of the file objects is closed before the temp_dir cleanup functions get
invoked. That makes it sound like I would need to register another fatal
handler that gets invoked before the temp_dir fatal_handler (does
at_fatal_handler guarantee LIFO execution of fatal handlers?). Right now,
at_fatal_handler does not pass an argument to the handler; so I would have to
register a single handler, and maintain my own list of FILE* objects that
mirrors temp_dir's list of files to clean up, which sounds messy. It would be
nice if fatal-signal could be augmented with a way to register a handler
function that takes a void* argument along with the argument to invoke it with
(similar to on_exit semantics), at which point I could repeatedly register the
same handler but with a different FILE* object and let fatal-signal manage the
list of registered FILE* to close.
--
Eric Blake
- clean-temp usage question,
Eric Blake <=
- Re: [bug-gnulib] clean-temp usage question, Bruno Haible, 2006/10/05
- Re: [bug-gnulib] clean-temp usage question, Eric Blake, 2006/10/05
- Re: [bug-gnulib] clean-temp usage question, Bruno Haible, 2006/10/06
- Re: [bug-gnulib] clean-temp usage question, Eric Blake, 2006/10/06
- Re: [bug-gnulib] clean-temp usage question, Bruno Haible, 2006/10/06
- Re: [bug-gnulib] clean-temp usage question, Eric Blake, 2006/10/06
- Re: [bug-gnulib] clean-temp usage question, Paul Eggert, 2006/10/06
- Re: [bug-gnulib] clean-temp usage question, Bruno Haible, 2006/10/06
- Re: [bug-gnulib] clean-temp usage question, Eric Blake, 2006/10/06
- Re: [bug-gnulib] clean-temp usage question, Bruno Haible, 2006/10/07