2015-08-10 12:47:41 +03:00
|
|
|
/*
|
|
|
|
* State diagram and cleanup
|
|
|
|
* -------------------------
|
|
|
|
*
|
|
|
|
* If the program exits while a temporary file is active, we want to
|
|
|
|
* make sure that we remove it. This is done by remembering the active
|
|
|
|
* temporary files in a linked list, `tempfile_list`. An `atexit(3)`
|
|
|
|
* handler and a signal handler are registered, to clean up any active
|
|
|
|
* temporary files.
|
|
|
|
*
|
|
|
|
* Because the signal handler can run at any time, `tempfile_list` and
|
|
|
|
* the `tempfile` objects that comprise it must be kept in
|
|
|
|
* self-consistent states at all times.
|
|
|
|
*
|
|
|
|
* The possible states of a `tempfile` object are as follows:
|
|
|
|
*
|
|
|
|
* - Uninitialized. In this state the object's `on_list` field must be
|
|
|
|
* zero but the rest of its contents need not be initialized. As
|
|
|
|
* soon as the object is used in any way, it is irrevocably
|
|
|
|
* registered in `tempfile_list`, and `on_list` is set.
|
|
|
|
*
|
|
|
|
* - Active, file open (after `create_tempfile()` or
|
|
|
|
* `reopen_tempfile()`). In this state:
|
|
|
|
*
|
|
|
|
* - the temporary file exists
|
|
|
|
* - `active` is set
|
|
|
|
* - `filename` holds the filename of the temporary file
|
|
|
|
* - `fd` holds a file descriptor open for writing to it
|
|
|
|
* - `fp` holds a pointer to an open `FILE` object if and only if
|
|
|
|
* `fdopen_tempfile()` has been called on the object
|
|
|
|
* - `owner` holds the PID of the process that created the file
|
|
|
|
*
|
tempfile: do not delete tempfile on failed close
When close_tempfile() fails, we delete the tempfile and
reset the fields of the tempfile struct. This makes it
easier for callers to return without cleaning up, but it
also makes this common pattern:
if (close_tempfile(tempfile))
return error_errno("error closing %s", tempfile->filename.buf);
wrong, because the "filename" field has been reset after the
failed close. And it's not easy to fix, as in many cases we
don't have another copy of the filename (e.g., if it was
created via one of the mks_tempfile functions, and we just
have the original template string).
Let's drop the feature that a failed close automatically
deletes the file. This puts the burden on the caller to do
the deletion themselves, but this isn't that big a deal.
Callers which do:
if (write(...) || close_tempfile(...)) {
delete_tempfile(...);
return -1;
}
already had to call delete when the write() failed, and so
aren't affected. Likewise, any caller which just calls die()
in the error path is OK; we'll delete the tempfile during
the atexit handler.
Because this patch changes the semantics of close_tempfile()
without changing its signature, all callers need to be
manually checked and converted to the new scheme. This patch
covers all in-tree callers, but there may be others for
not-yet-merged topics. To catch these, we rename the
function to close_tempfile_gently(), which will attract
compile-time attention to new callers. (Technically the
original could be considered "gentle" already in that it
didn't die() on errors, but this one is even more so).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-05 15:14:30 +03:00
|
|
|
* - Active, file closed (after `close_tempfile_gently()`). Same
|
2015-08-10 12:47:41 +03:00
|
|
|
* as the previous state, except that the temporary file is closed,
|
|
|
|
* `fd` is -1, and `fp` is `NULL`.
|
|
|
|
*
|
tempfile: do not delete tempfile on failed close
When close_tempfile() fails, we delete the tempfile and
reset the fields of the tempfile struct. This makes it
easier for callers to return without cleaning up, but it
also makes this common pattern:
if (close_tempfile(tempfile))
return error_errno("error closing %s", tempfile->filename.buf);
wrong, because the "filename" field has been reset after the
failed close. And it's not easy to fix, as in many cases we
don't have another copy of the filename (e.g., if it was
created via one of the mks_tempfile functions, and we just
have the original template string).
Let's drop the feature that a failed close automatically
deletes the file. This puts the burden on the caller to do
the deletion themselves, but this isn't that big a deal.
Callers which do:
if (write(...) || close_tempfile(...)) {
delete_tempfile(...);
return -1;
}
already had to call delete when the write() failed, and so
aren't affected. Likewise, any caller which just calls die()
in the error path is OK; we'll delete the tempfile during
the atexit handler.
Because this patch changes the semantics of close_tempfile()
without changing its signature, all callers need to be
manually checked and converted to the new scheme. This patch
covers all in-tree callers, but there may be others for
not-yet-merged topics. To catch these, we rename the
function to close_tempfile_gently(), which will attract
compile-time attention to new callers. (Technically the
original could be considered "gentle" already in that it
didn't die() on errors, but this one is even more so).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-05 15:14:30 +03:00
|
|
|
* - Inactive (after `delete_tempfile()`, `rename_tempfile()`, or a
|
|
|
|
* failed attempt to create a temporary file). In this state:
|
2015-08-10 12:47:41 +03:00
|
|
|
*
|
|
|
|
* - `active` is unset
|
|
|
|
* - `filename` is empty (usually, though there are transitory
|
|
|
|
* states in which this condition doesn't hold). Client code should
|
|
|
|
* *not* rely on the filename being empty in this state.
|
|
|
|
* - `fd` is -1 and `fp` is `NULL`
|
|
|
|
* - the object is left registered in the `tempfile_list`, and
|
|
|
|
* `on_list` is set.
|
|
|
|
*
|
|
|
|
* A temporary file is owned by the process that created it. The
|
|
|
|
* `tempfile` has an `owner` field that records the owner's PID. This
|
|
|
|
* field is used to prevent a forked process from deleting a temporary
|
|
|
|
* file created by its parent.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include "cache.h"
|
|
|
|
#include "tempfile.h"
|
|
|
|
#include "sigchain.h"
|
|
|
|
|
tempfile: use list.h for linked list
The tempfile API keeps to-be-cleaned tempfiles in a
singly-linked list and never removes items from the list. A
future patch would like to start removing items, but removal
from a singly linked list is O(n), as we have to walk the
list to find the predecessor element. This means that a
process which takes "n" simultaneous lockfiles (for example,
an atomic transaction on "n" refs) may end up quadratic in
"n".
Before we start allowing items to be removed, it would be
nice to have a way to cover this case in linear time.
The simplest solution is to make an assumption about the
order in which tempfiles are added and removed from the
list. If both operations iterate over the tempfiles in the
same order, then by putting new items at the end of the list
our removal search will always find its items at the
beginning of the list. And indeed, that would work for the
case of refs. But it creates a hidden dependency between
unrelated parts of the code. If anybody changes the ref code
(or if we add a new caller that opens multiple simultaneous
tempfiles) they may unknowingly introduce a performance
regression.
Another solution is to use a better data structure. A
doubly-linked list works fine, and we already have an
implementation in list.h. But there's one snag: the elements
of "struct tempfile" are all marked as "volatile", since a
signal handler may interrupt us and iterate over the list at
any moment (even if we were in the middle of adding a new
entry).
We can declare a "volatile struct list_head", but we can't
actually use it with the normal list functions. The compiler
complains about passing a pointer-to-volatile via a regular
pointer argument. And rightfully so, as the sub-function
would potentially need different code to deal with the
volatile case.
That leaves us with a few options:
1. Drop the "volatile" modifier for the list items.
This is probably a bad idea. I checked the assembly
output from "gcc -O2", and the "volatile" really does
impact the order in which it updates memory.
2. Use macros instead of inline functions. The irony here
is that list.h is entirely implemented as trivial
inline functions. So we basically are already
generating custom code for each call. But sadly there's no
way in C to declare the inline function to take a more
generic type.
We could do so by switching the inline functions to
macros, but it does make the end result harder to read.
And it doesn't fully solve the problem (for instance,
the declaration of list_head needs to change so that
its "prev" and "next" pointers point to other volatile
structs).
3. Don't use list.h, and just make our own ad-hoc
doubly-linked list. It's not that much code to
implement the basics that we need here. But if we're
going to do so, why not add the few extra lines
required to model it after the actual list.h interface?
We can even reuse a few of the macro helpers.
So this patch takes option 3, but actually implements a
parallel "volatile list" interface in list.h, where it could
potentially be reused by other code. This implements just
enough for tempfile.c's use, though we could easily port
other functions later if need be.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-05 15:15:00 +03:00
|
|
|
static VOLATILE_LIST_HEAD(tempfile_list);
|
2015-08-10 12:47:41 +03:00
|
|
|
|
2017-09-05 15:14:53 +03:00
|
|
|
static void remove_tempfiles(int in_signal_handler)
|
2015-08-10 12:47:41 +03:00
|
|
|
{
|
|
|
|
pid_t me = getpid();
|
tempfile: use list.h for linked list
The tempfile API keeps to-be-cleaned tempfiles in a
singly-linked list and never removes items from the list. A
future patch would like to start removing items, but removal
from a singly linked list is O(n), as we have to walk the
list to find the predecessor element. This means that a
process which takes "n" simultaneous lockfiles (for example,
an atomic transaction on "n" refs) may end up quadratic in
"n".
Before we start allowing items to be removed, it would be
nice to have a way to cover this case in linear time.
The simplest solution is to make an assumption about the
order in which tempfiles are added and removed from the
list. If both operations iterate over the tempfiles in the
same order, then by putting new items at the end of the list
our removal search will always find its items at the
beginning of the list. And indeed, that would work for the
case of refs. But it creates a hidden dependency between
unrelated parts of the code. If anybody changes the ref code
(or if we add a new caller that opens multiple simultaneous
tempfiles) they may unknowingly introduce a performance
regression.
Another solution is to use a better data structure. A
doubly-linked list works fine, and we already have an
implementation in list.h. But there's one snag: the elements
of "struct tempfile" are all marked as "volatile", since a
signal handler may interrupt us and iterate over the list at
any moment (even if we were in the middle of adding a new
entry).
We can declare a "volatile struct list_head", but we can't
actually use it with the normal list functions. The compiler
complains about passing a pointer-to-volatile via a regular
pointer argument. And rightfully so, as the sub-function
would potentially need different code to deal with the
volatile case.
That leaves us with a few options:
1. Drop the "volatile" modifier for the list items.
This is probably a bad idea. I checked the assembly
output from "gcc -O2", and the "volatile" really does
impact the order in which it updates memory.
2. Use macros instead of inline functions. The irony here
is that list.h is entirely implemented as trivial
inline functions. So we basically are already
generating custom code for each call. But sadly there's no
way in C to declare the inline function to take a more
generic type.
We could do so by switching the inline functions to
macros, but it does make the end result harder to read.
And it doesn't fully solve the problem (for instance,
the declaration of list_head needs to change so that
its "prev" and "next" pointers point to other volatile
structs).
3. Don't use list.h, and just make our own ad-hoc
doubly-linked list. It's not that much code to
implement the basics that we need here. But if we're
going to do so, why not add the few extra lines
required to model it after the actual list.h interface?
We can even reuse a few of the macro helpers.
So this patch takes option 3, but actually implements a
parallel "volatile list" interface in list.h, where it could
potentially be reused by other code. This implements just
enough for tempfile.c's use, though we could easily port
other functions later if need be.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-05 15:15:00 +03:00
|
|
|
volatile struct volatile_list_head *pos;
|
|
|
|
|
|
|
|
list_for_each(pos, &tempfile_list) {
|
|
|
|
struct tempfile *p = list_entry(pos, struct tempfile, list);
|
2015-08-10 12:47:41 +03:00
|
|
|
|
2017-09-05 15:14:53 +03:00
|
|
|
if (!is_tempfile_active(p) || p->owner != me)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (p->fd >= 0)
|
|
|
|
close(p->fd);
|
|
|
|
|
|
|
|
if (in_signal_handler)
|
|
|
|
unlink(p->filename.buf);
|
|
|
|
else
|
|
|
|
unlink_or_warn(p->filename.buf);
|
|
|
|
|
|
|
|
p->active = 0;
|
2015-08-10 12:47:41 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void remove_tempfiles_on_exit(void)
|
|
|
|
{
|
|
|
|
remove_tempfiles(0);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void remove_tempfiles_on_signal(int signo)
|
|
|
|
{
|
|
|
|
remove_tempfiles(1);
|
|
|
|
sigchain_pop(signo);
|
|
|
|
raise(signo);
|
|
|
|
}
|
|
|
|
|
2015-08-10 12:47:42 +03:00
|
|
|
/*
|
|
|
|
* Initialize *tempfile if necessary and add it to tempfile_list.
|
|
|
|
*/
|
|
|
|
static void prepare_tempfile_object(struct tempfile *tempfile)
|
2015-08-10 12:47:41 +03:00
|
|
|
{
|
tempfile: use list.h for linked list
The tempfile API keeps to-be-cleaned tempfiles in a
singly-linked list and never removes items from the list. A
future patch would like to start removing items, but removal
from a singly linked list is O(n), as we have to walk the
list to find the predecessor element. This means that a
process which takes "n" simultaneous lockfiles (for example,
an atomic transaction on "n" refs) may end up quadratic in
"n".
Before we start allowing items to be removed, it would be
nice to have a way to cover this case in linear time.
The simplest solution is to make an assumption about the
order in which tempfiles are added and removed from the
list. If both operations iterate over the tempfiles in the
same order, then by putting new items at the end of the list
our removal search will always find its items at the
beginning of the list. And indeed, that would work for the
case of refs. But it creates a hidden dependency between
unrelated parts of the code. If anybody changes the ref code
(or if we add a new caller that opens multiple simultaneous
tempfiles) they may unknowingly introduce a performance
regression.
Another solution is to use a better data structure. A
doubly-linked list works fine, and we already have an
implementation in list.h. But there's one snag: the elements
of "struct tempfile" are all marked as "volatile", since a
signal handler may interrupt us and iterate over the list at
any moment (even if we were in the middle of adding a new
entry).
We can declare a "volatile struct list_head", but we can't
actually use it with the normal list functions. The compiler
complains about passing a pointer-to-volatile via a regular
pointer argument. And rightfully so, as the sub-function
would potentially need different code to deal with the
volatile case.
That leaves us with a few options:
1. Drop the "volatile" modifier for the list items.
This is probably a bad idea. I checked the assembly
output from "gcc -O2", and the "volatile" really does
impact the order in which it updates memory.
2. Use macros instead of inline functions. The irony here
is that list.h is entirely implemented as trivial
inline functions. So we basically are already
generating custom code for each call. But sadly there's no
way in C to declare the inline function to take a more
generic type.
We could do so by switching the inline functions to
macros, but it does make the end result harder to read.
And it doesn't fully solve the problem (for instance,
the declaration of list_head needs to change so that
its "prev" and "next" pointers point to other volatile
structs).
3. Don't use list.h, and just make our own ad-hoc
doubly-linked list. It's not that much code to
implement the basics that we need here. But if we're
going to do so, why not add the few extra lines
required to model it after the actual list.h interface?
We can even reuse a few of the macro helpers.
So this patch takes option 3, but actually implements a
parallel "volatile list" interface in list.h, where it could
potentially be reused by other code. This implements just
enough for tempfile.c's use, though we could easily port
other functions later if need be.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-05 15:15:00 +03:00
|
|
|
if (volatile_list_empty(&tempfile_list)) {
|
2015-08-10 12:47:41 +03:00
|
|
|
/* One-time initialization */
|
|
|
|
sigchain_push_common(remove_tempfiles_on_signal);
|
|
|
|
atexit(remove_tempfiles_on_exit);
|
|
|
|
}
|
|
|
|
|
2017-09-05 15:14:36 +03:00
|
|
|
if (is_tempfile_active(tempfile))
|
2017-09-05 15:14:43 +03:00
|
|
|
BUG("prepare_tempfile_object called for active object");
|
2015-08-10 12:47:41 +03:00
|
|
|
if (!tempfile->on_list) {
|
|
|
|
/* Initialize *tempfile and add it to tempfile_list: */
|
|
|
|
tempfile->fd = -1;
|
|
|
|
tempfile->fp = NULL;
|
|
|
|
tempfile->active = 0;
|
|
|
|
tempfile->owner = 0;
|
2015-08-10 12:47:42 +03:00
|
|
|
strbuf_init(&tempfile->filename, 0);
|
tempfile: use list.h for linked list
The tempfile API keeps to-be-cleaned tempfiles in a
singly-linked list and never removes items from the list. A
future patch would like to start removing items, but removal
from a singly linked list is O(n), as we have to walk the
list to find the predecessor element. This means that a
process which takes "n" simultaneous lockfiles (for example,
an atomic transaction on "n" refs) may end up quadratic in
"n".
Before we start allowing items to be removed, it would be
nice to have a way to cover this case in linear time.
The simplest solution is to make an assumption about the
order in which tempfiles are added and removed from the
list. If both operations iterate over the tempfiles in the
same order, then by putting new items at the end of the list
our removal search will always find its items at the
beginning of the list. And indeed, that would work for the
case of refs. But it creates a hidden dependency between
unrelated parts of the code. If anybody changes the ref code
(or if we add a new caller that opens multiple simultaneous
tempfiles) they may unknowingly introduce a performance
regression.
Another solution is to use a better data structure. A
doubly-linked list works fine, and we already have an
implementation in list.h. But there's one snag: the elements
of "struct tempfile" are all marked as "volatile", since a
signal handler may interrupt us and iterate over the list at
any moment (even if we were in the middle of adding a new
entry).
We can declare a "volatile struct list_head", but we can't
actually use it with the normal list functions. The compiler
complains about passing a pointer-to-volatile via a regular
pointer argument. And rightfully so, as the sub-function
would potentially need different code to deal with the
volatile case.
That leaves us with a few options:
1. Drop the "volatile" modifier for the list items.
This is probably a bad idea. I checked the assembly
output from "gcc -O2", and the "volatile" really does
impact the order in which it updates memory.
2. Use macros instead of inline functions. The irony here
is that list.h is entirely implemented as trivial
inline functions. So we basically are already
generating custom code for each call. But sadly there's no
way in C to declare the inline function to take a more
generic type.
We could do so by switching the inline functions to
macros, but it does make the end result harder to read.
And it doesn't fully solve the problem (for instance,
the declaration of list_head needs to change so that
its "prev" and "next" pointers point to other volatile
structs).
3. Don't use list.h, and just make our own ad-hoc
doubly-linked list. It's not that much code to
implement the basics that we need here. But if we're
going to do so, why not add the few extra lines
required to model it after the actual list.h interface?
We can even reuse a few of the macro helpers.
So this patch takes option 3, but actually implements a
parallel "volatile list" interface in list.h, where it could
potentially be reused by other code. This implements just
enough for tempfile.c's use, though we could easily port
other functions later if need be.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-05 15:15:00 +03:00
|
|
|
volatile_list_add(&tempfile->list, &tempfile_list);
|
2015-08-10 12:47:41 +03:00
|
|
|
tempfile->on_list = 1;
|
|
|
|
} else if (tempfile->filename.len) {
|
|
|
|
/* This shouldn't happen, but better safe than sorry. */
|
2017-09-05 15:14:43 +03:00
|
|
|
BUG("prepare_tempfile_object called for improperly-reset object");
|
2015-08-10 12:47:41 +03:00
|
|
|
}
|
2015-08-10 12:47:42 +03:00
|
|
|
}
|
|
|
|
|
2017-09-05 15:14:47 +03:00
|
|
|
static void activate_tempfile(struct tempfile *tempfile)
|
|
|
|
{
|
|
|
|
tempfile->owner = getpid();
|
|
|
|
tempfile->active = 1;
|
|
|
|
}
|
|
|
|
|
2017-09-05 15:14:50 +03:00
|
|
|
static void deactivate_tempfile(struct tempfile *tempfile)
|
|
|
|
{
|
|
|
|
tempfile->active = 0;
|
2017-09-05 15:14:56 +03:00
|
|
|
strbuf_release(&tempfile->filename);
|
2017-09-05 15:14:50 +03:00
|
|
|
}
|
|
|
|
|
2015-08-10 12:47:42 +03:00
|
|
|
/* Make sure errno contains a meaningful value on error */
|
|
|
|
int create_tempfile(struct tempfile *tempfile, const char *path)
|
|
|
|
{
|
|
|
|
prepare_tempfile_object(tempfile);
|
2015-08-10 12:47:41 +03:00
|
|
|
|
|
|
|
strbuf_add_absolute_path(&tempfile->filename, path);
|
2016-08-22 15:47:55 +03:00
|
|
|
tempfile->fd = open(tempfile->filename.buf,
|
|
|
|
O_RDWR | O_CREAT | O_EXCL | O_CLOEXEC, 0666);
|
|
|
|
if (O_CLOEXEC && tempfile->fd < 0 && errno == EINVAL)
|
|
|
|
/* Try again w/o O_CLOEXEC: the kernel might not support it */
|
|
|
|
tempfile->fd = open(tempfile->filename.buf,
|
|
|
|
O_RDWR | O_CREAT | O_EXCL, 0666);
|
2015-08-10 12:47:41 +03:00
|
|
|
if (tempfile->fd < 0) {
|
2017-09-05 15:14:50 +03:00
|
|
|
deactivate_tempfile(tempfile);
|
2015-08-10 12:47:41 +03:00
|
|
|
return -1;
|
|
|
|
}
|
2017-09-05 15:14:47 +03:00
|
|
|
activate_tempfile(tempfile);
|
2015-08-10 12:47:41 +03:00
|
|
|
if (adjust_shared_perm(tempfile->filename.buf)) {
|
|
|
|
int save_errno = errno;
|
|
|
|
error("cannot fix permission bits on %s", tempfile->filename.buf);
|
|
|
|
delete_tempfile(tempfile);
|
|
|
|
errno = save_errno;
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
return tempfile->fd;
|
|
|
|
}
|
|
|
|
|
2015-08-10 12:47:44 +03:00
|
|
|
void register_tempfile(struct tempfile *tempfile, const char *path)
|
|
|
|
{
|
|
|
|
prepare_tempfile_object(tempfile);
|
|
|
|
strbuf_add_absolute_path(&tempfile->filename, path);
|
2017-09-05 15:14:47 +03:00
|
|
|
activate_tempfile(tempfile);
|
2015-08-10 12:47:44 +03:00
|
|
|
}
|
|
|
|
|
2015-08-10 12:47:43 +03:00
|
|
|
int mks_tempfile_sm(struct tempfile *tempfile,
|
|
|
|
const char *template, int suffixlen, int mode)
|
|
|
|
{
|
|
|
|
prepare_tempfile_object(tempfile);
|
|
|
|
|
|
|
|
strbuf_add_absolute_path(&tempfile->filename, template);
|
|
|
|
tempfile->fd = git_mkstemps_mode(tempfile->filename.buf, suffixlen, mode);
|
|
|
|
if (tempfile->fd < 0) {
|
2017-09-05 15:14:50 +03:00
|
|
|
deactivate_tempfile(tempfile);
|
2015-08-10 12:47:43 +03:00
|
|
|
return -1;
|
|
|
|
}
|
2017-09-05 15:14:47 +03:00
|
|
|
activate_tempfile(tempfile);
|
2015-08-10 12:47:43 +03:00
|
|
|
return tempfile->fd;
|
|
|
|
}
|
|
|
|
|
|
|
|
int mks_tempfile_tsm(struct tempfile *tempfile,
|
|
|
|
const char *template, int suffixlen, int mode)
|
|
|
|
{
|
|
|
|
const char *tmpdir;
|
|
|
|
|
|
|
|
prepare_tempfile_object(tempfile);
|
|
|
|
|
|
|
|
tmpdir = getenv("TMPDIR");
|
|
|
|
if (!tmpdir)
|
|
|
|
tmpdir = "/tmp";
|
|
|
|
|
|
|
|
strbuf_addf(&tempfile->filename, "%s/%s", tmpdir, template);
|
|
|
|
tempfile->fd = git_mkstemps_mode(tempfile->filename.buf, suffixlen, mode);
|
|
|
|
if (tempfile->fd < 0) {
|
2017-09-05 15:14:50 +03:00
|
|
|
deactivate_tempfile(tempfile);
|
2015-08-10 12:47:43 +03:00
|
|
|
return -1;
|
|
|
|
}
|
2017-09-05 15:14:47 +03:00
|
|
|
activate_tempfile(tempfile);
|
2015-08-10 12:47:43 +03:00
|
|
|
return tempfile->fd;
|
|
|
|
}
|
|
|
|
|
|
|
|
int xmks_tempfile_m(struct tempfile *tempfile, const char *template, int mode)
|
|
|
|
{
|
|
|
|
int fd;
|
|
|
|
struct strbuf full_template = STRBUF_INIT;
|
|
|
|
|
|
|
|
strbuf_add_absolute_path(&full_template, template);
|
|
|
|
fd = mks_tempfile_m(tempfile, full_template.buf, mode);
|
|
|
|
if (fd < 0)
|
|
|
|
die_errno("Unable to create temporary file '%s'",
|
|
|
|
full_template.buf);
|
|
|
|
|
|
|
|
strbuf_release(&full_template);
|
|
|
|
return fd;
|
|
|
|
}
|
|
|
|
|
2015-08-10 12:47:41 +03:00
|
|
|
FILE *fdopen_tempfile(struct tempfile *tempfile, const char *mode)
|
|
|
|
{
|
2017-09-05 15:14:36 +03:00
|
|
|
if (!is_tempfile_active(tempfile))
|
2017-09-05 15:14:43 +03:00
|
|
|
BUG("fdopen_tempfile() called for inactive object");
|
2015-08-10 12:47:41 +03:00
|
|
|
if (tempfile->fp)
|
2017-09-05 15:14:43 +03:00
|
|
|
BUG("fdopen_tempfile() called for open object");
|
2015-08-10 12:47:41 +03:00
|
|
|
|
|
|
|
tempfile->fp = fdopen(tempfile->fd, mode);
|
|
|
|
return tempfile->fp;
|
|
|
|
}
|
|
|
|
|
|
|
|
const char *get_tempfile_path(struct tempfile *tempfile)
|
|
|
|
{
|
2017-09-05 15:14:36 +03:00
|
|
|
if (!is_tempfile_active(tempfile))
|
2017-09-05 15:14:43 +03:00
|
|
|
BUG("get_tempfile_path() called for inactive object");
|
2015-08-10 12:47:41 +03:00
|
|
|
return tempfile->filename.buf;
|
|
|
|
}
|
|
|
|
|
|
|
|
int get_tempfile_fd(struct tempfile *tempfile)
|
|
|
|
{
|
2017-09-05 15:14:36 +03:00
|
|
|
if (!is_tempfile_active(tempfile))
|
2017-09-05 15:14:43 +03:00
|
|
|
BUG("get_tempfile_fd() called for inactive object");
|
2015-08-10 12:47:41 +03:00
|
|
|
return tempfile->fd;
|
|
|
|
}
|
|
|
|
|
|
|
|
FILE *get_tempfile_fp(struct tempfile *tempfile)
|
|
|
|
{
|
2017-09-05 15:14:36 +03:00
|
|
|
if (!is_tempfile_active(tempfile))
|
2017-09-05 15:14:43 +03:00
|
|
|
BUG("get_tempfile_fp() called for inactive object");
|
2015-08-10 12:47:41 +03:00
|
|
|
return tempfile->fp;
|
|
|
|
}
|
|
|
|
|
tempfile: do not delete tempfile on failed close
When close_tempfile() fails, we delete the tempfile and
reset the fields of the tempfile struct. This makes it
easier for callers to return without cleaning up, but it
also makes this common pattern:
if (close_tempfile(tempfile))
return error_errno("error closing %s", tempfile->filename.buf);
wrong, because the "filename" field has been reset after the
failed close. And it's not easy to fix, as in many cases we
don't have another copy of the filename (e.g., if it was
created via one of the mks_tempfile functions, and we just
have the original template string).
Let's drop the feature that a failed close automatically
deletes the file. This puts the burden on the caller to do
the deletion themselves, but this isn't that big a deal.
Callers which do:
if (write(...) || close_tempfile(...)) {
delete_tempfile(...);
return -1;
}
already had to call delete when the write() failed, and so
aren't affected. Likewise, any caller which just calls die()
in the error path is OK; we'll delete the tempfile during
the atexit handler.
Because this patch changes the semantics of close_tempfile()
without changing its signature, all callers need to be
manually checked and converted to the new scheme. This patch
covers all in-tree callers, but there may be others for
not-yet-merged topics. To catch these, we rename the
function to close_tempfile_gently(), which will attract
compile-time attention to new callers. (Technically the
original could be considered "gentle" already in that it
didn't die() on errors, but this one is even more so).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-05 15:14:30 +03:00
|
|
|
int close_tempfile_gently(struct tempfile *tempfile)
|
2015-08-10 12:47:41 +03:00
|
|
|
{
|
2017-09-05 15:14:40 +03:00
|
|
|
int fd;
|
|
|
|
FILE *fp;
|
2015-08-10 12:47:41 +03:00
|
|
|
int err;
|
|
|
|
|
2017-09-05 15:14:40 +03:00
|
|
|
if (!is_tempfile_active(tempfile) || tempfile->fd < 0)
|
2015-08-10 12:47:41 +03:00
|
|
|
return 0;
|
|
|
|
|
2017-09-05 15:14:40 +03:00
|
|
|
fd = tempfile->fd;
|
|
|
|
fp = tempfile->fp;
|
2015-08-10 12:47:41 +03:00
|
|
|
tempfile->fd = -1;
|
|
|
|
if (fp) {
|
|
|
|
tempfile->fp = NULL;
|
tempfile: set errno to a known value before calling ferror()
In close_tempfile(), we return an error if ferror()
indicated a previous failure, or if fclose() failed. In the
latter case, errno is set and it is useful for callers to
report it.
However, if _only_ ferror() triggers, then the value of
errno is based on whatever syscall happened to last fail,
which may not be related to our filehandle at all. A caller
cannot tell the difference between the two cases, and may
use "die_errno()" or similar to report a nonsense errno value.
One solution would be to actually pass back separate return
values for the two cases, so a caller can write a more
appropriate message for each case. But that makes the
interface clunky.
Instead, let's just set errno to the generic EIO in this case.
That's not as descriptive as we'd like, but at least it's
predictable. So it's better than the status quo in all cases
but one: when the last syscall really did involve a failure
on our filehandle, we'll be wiping that out. But that's a
fragile thing for us to rely on.
In any case, we'll let the errno result from fclose() take
precedence over our value, as we know that's recent and
accurate (and many I/O errors will persist through the
fclose anyway).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-18 00:07:49 +03:00
|
|
|
if (ferror(fp)) {
|
|
|
|
err = -1;
|
|
|
|
if (!fclose(fp))
|
|
|
|
errno = EIO;
|
|
|
|
} else {
|
|
|
|
err = fclose(fp);
|
|
|
|
}
|
2015-08-10 12:47:41 +03:00
|
|
|
} else {
|
|
|
|
err = close(fd);
|
|
|
|
}
|
|
|
|
|
tempfile: do not delete tempfile on failed close
When close_tempfile() fails, we delete the tempfile and
reset the fields of the tempfile struct. This makes it
easier for callers to return without cleaning up, but it
also makes this common pattern:
if (close_tempfile(tempfile))
return error_errno("error closing %s", tempfile->filename.buf);
wrong, because the "filename" field has been reset after the
failed close. And it's not easy to fix, as in many cases we
don't have another copy of the filename (e.g., if it was
created via one of the mks_tempfile functions, and we just
have the original template string).
Let's drop the feature that a failed close automatically
deletes the file. This puts the burden on the caller to do
the deletion themselves, but this isn't that big a deal.
Callers which do:
if (write(...) || close_tempfile(...)) {
delete_tempfile(...);
return -1;
}
already had to call delete when the write() failed, and so
aren't affected. Likewise, any caller which just calls die()
in the error path is OK; we'll delete the tempfile during
the atexit handler.
Because this patch changes the semantics of close_tempfile()
without changing its signature, all callers need to be
manually checked and converted to the new scheme. This patch
covers all in-tree callers, but there may be others for
not-yet-merged topics. To catch these, we rename the
function to close_tempfile_gently(), which will attract
compile-time attention to new callers. (Technically the
original could be considered "gentle" already in that it
didn't die() on errors, but this one is even more so).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-05 15:14:30 +03:00
|
|
|
return err ? -1 : 0;
|
2015-08-10 12:47:41 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
int reopen_tempfile(struct tempfile *tempfile)
|
|
|
|
{
|
2017-09-05 15:14:36 +03:00
|
|
|
if (!is_tempfile_active(tempfile))
|
2017-09-05 15:14:43 +03:00
|
|
|
BUG("reopen_tempfile called for an inactive object");
|
2017-09-05 15:14:40 +03:00
|
|
|
if (0 <= tempfile->fd)
|
2017-09-05 15:14:43 +03:00
|
|
|
BUG("reopen_tempfile called for an open object");
|
2015-08-10 12:47:41 +03:00
|
|
|
tempfile->fd = open(tempfile->filename.buf, O_WRONLY);
|
|
|
|
return tempfile->fd;
|
|
|
|
}
|
|
|
|
|
|
|
|
int rename_tempfile(struct tempfile *tempfile, const char *path)
|
|
|
|
{
|
2017-09-05 15:14:36 +03:00
|
|
|
if (!is_tempfile_active(tempfile))
|
2017-09-05 15:14:43 +03:00
|
|
|
BUG("rename_tempfile called for inactive object");
|
2015-08-10 12:47:41 +03:00
|
|
|
|
tempfile: do not delete tempfile on failed close
When close_tempfile() fails, we delete the tempfile and
reset the fields of the tempfile struct. This makes it
easier for callers to return without cleaning up, but it
also makes this common pattern:
if (close_tempfile(tempfile))
return error_errno("error closing %s", tempfile->filename.buf);
wrong, because the "filename" field has been reset after the
failed close. And it's not easy to fix, as in many cases we
don't have another copy of the filename (e.g., if it was
created via one of the mks_tempfile functions, and we just
have the original template string).
Let's drop the feature that a failed close automatically
deletes the file. This puts the burden on the caller to do
the deletion themselves, but this isn't that big a deal.
Callers which do:
if (write(...) || close_tempfile(...)) {
delete_tempfile(...);
return -1;
}
already had to call delete when the write() failed, and so
aren't affected. Likewise, any caller which just calls die()
in the error path is OK; we'll delete the tempfile during
the atexit handler.
Because this patch changes the semantics of close_tempfile()
without changing its signature, all callers need to be
manually checked and converted to the new scheme. This patch
covers all in-tree callers, but there may be others for
not-yet-merged topics. To catch these, we rename the
function to close_tempfile_gently(), which will attract
compile-time attention to new callers. (Technically the
original could be considered "gentle" already in that it
didn't die() on errors, but this one is even more so).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-05 15:14:30 +03:00
|
|
|
if (close_tempfile_gently(tempfile)) {
|
|
|
|
delete_tempfile(tempfile);
|
2015-08-10 12:47:41 +03:00
|
|
|
return -1;
|
tempfile: do not delete tempfile on failed close
When close_tempfile() fails, we delete the tempfile and
reset the fields of the tempfile struct. This makes it
easier for callers to return without cleaning up, but it
also makes this common pattern:
if (close_tempfile(tempfile))
return error_errno("error closing %s", tempfile->filename.buf);
wrong, because the "filename" field has been reset after the
failed close. And it's not easy to fix, as in many cases we
don't have another copy of the filename (e.g., if it was
created via one of the mks_tempfile functions, and we just
have the original template string).
Let's drop the feature that a failed close automatically
deletes the file. This puts the burden on the caller to do
the deletion themselves, but this isn't that big a deal.
Callers which do:
if (write(...) || close_tempfile(...)) {
delete_tempfile(...);
return -1;
}
already had to call delete when the write() failed, and so
aren't affected. Likewise, any caller which just calls die()
in the error path is OK; we'll delete the tempfile during
the atexit handler.
Because this patch changes the semantics of close_tempfile()
without changing its signature, all callers need to be
manually checked and converted to the new scheme. This patch
covers all in-tree callers, but there may be others for
not-yet-merged topics. To catch these, we rename the
function to close_tempfile_gently(), which will attract
compile-time attention to new callers. (Technically the
original could be considered "gentle" already in that it
didn't die() on errors, but this one is even more so).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-05 15:14:30 +03:00
|
|
|
}
|
2015-08-10 12:47:41 +03:00
|
|
|
|
|
|
|
if (rename(tempfile->filename.buf, path)) {
|
|
|
|
int save_errno = errno;
|
|
|
|
delete_tempfile(tempfile);
|
|
|
|
errno = save_errno;
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
2017-09-05 15:14:50 +03:00
|
|
|
deactivate_tempfile(tempfile);
|
2015-08-10 12:47:41 +03:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
void delete_tempfile(struct tempfile *tempfile)
|
|
|
|
{
|
2017-09-05 15:14:36 +03:00
|
|
|
if (!is_tempfile_active(tempfile))
|
2015-08-10 12:47:41 +03:00
|
|
|
return;
|
|
|
|
|
tempfile: do not delete tempfile on failed close
When close_tempfile() fails, we delete the tempfile and
reset the fields of the tempfile struct. This makes it
easier for callers to return without cleaning up, but it
also makes this common pattern:
if (close_tempfile(tempfile))
return error_errno("error closing %s", tempfile->filename.buf);
wrong, because the "filename" field has been reset after the
failed close. And it's not easy to fix, as in many cases we
don't have another copy of the filename (e.g., if it was
created via one of the mks_tempfile functions, and we just
have the original template string).
Let's drop the feature that a failed close automatically
deletes the file. This puts the burden on the caller to do
the deletion themselves, but this isn't that big a deal.
Callers which do:
if (write(...) || close_tempfile(...)) {
delete_tempfile(...);
return -1;
}
already had to call delete when the write() failed, and so
aren't affected. Likewise, any caller which just calls die()
in the error path is OK; we'll delete the tempfile during
the atexit handler.
Because this patch changes the semantics of close_tempfile()
without changing its signature, all callers need to be
manually checked and converted to the new scheme. This patch
covers all in-tree callers, but there may be others for
not-yet-merged topics. To catch these, we rename the
function to close_tempfile_gently(), which will attract
compile-time attention to new callers. (Technically the
original could be considered "gentle" already in that it
didn't die() on errors, but this one is even more so).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-05 15:14:30 +03:00
|
|
|
close_tempfile_gently(tempfile);
|
|
|
|
unlink_or_warn(tempfile->filename.buf);
|
2017-09-05 15:14:50 +03:00
|
|
|
deactivate_tempfile(tempfile);
|
2015-08-10 12:47:41 +03:00
|
|
|
}
|