2006-06-07 03:51:49 +08:00
|
|
|
/*
|
|
|
|
* Copyright (c) 2005, Junio C Hamano
|
|
|
|
*/
|
2015-08-10 17:47:36 +08:00
|
|
|
|
2023-03-21 14:26:02 +08:00
|
|
|
#include "git-compat-util.h"
|
2023-03-21 14:25:58 +08:00
|
|
|
#include "abspath.h"
|
2023-03-21 14:25:54 +08:00
|
|
|
#include "gettext.h"
|
2014-10-01 18:28:42 +08:00
|
|
|
#include "lockfile.h"
|
2006-06-07 03:51:49 +08:00
|
|
|
|
2007-07-27 01:34:14 +08:00
|
|
|
/*
|
2014-10-01 18:28:35 +08:00
|
|
|
* path = absolute or relative path name
|
2007-07-27 01:34:14 +08:00
|
|
|
*
|
2014-10-01 18:28:35 +08:00
|
|
|
* Remove the last path name element from path (leaving the preceding
|
|
|
|
* "/", if any). If path is empty or the root directory ("/"), set
|
|
|
|
* path to the empty string.
|
2007-07-27 01:34:14 +08:00
|
|
|
*/
|
2014-10-01 18:28:35 +08:00
|
|
|
static void trim_last_path_component(struct strbuf *path)
|
2007-07-27 01:34:14 +08:00
|
|
|
{
|
2014-10-01 18:28:35 +08:00
|
|
|
int i = path->len;
|
2007-07-27 01:34:14 +08:00
|
|
|
|
|
|
|
/* back up past trailing slashes, if any */
|
2014-10-01 18:28:35 +08:00
|
|
|
while (i && path->buf[i - 1] == '/')
|
|
|
|
i--;
|
2007-07-27 01:34:14 +08:00
|
|
|
|
|
|
|
/*
|
2014-10-01 18:28:35 +08:00
|
|
|
* then go backwards until a slash, or the beginning of the
|
|
|
|
* string
|
2007-07-27 01:34:14 +08:00
|
|
|
*/
|
2014-10-01 18:28:35 +08:00
|
|
|
while (i && path->buf[i - 1] != '/')
|
|
|
|
i--;
|
|
|
|
|
|
|
|
strbuf_setlen(path, i);
|
2007-07-27 01:34:14 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/* We allow "recursive" symbolic links. Only within reason, though */
|
|
|
|
#define MAXDEPTH 5
|
|
|
|
|
|
|
|
/*
|
2014-10-01 18:28:34 +08:00
|
|
|
* path contains a path that might be a symlink.
|
2007-07-27 01:34:14 +08:00
|
|
|
*
|
2014-10-01 18:28:34 +08:00
|
|
|
* If path is a symlink, attempt to overwrite it with a path to the
|
|
|
|
* real file or directory (which may or may not exist), following a
|
|
|
|
* chain of symlinks if necessary. Otherwise, leave path unmodified.
|
2007-07-27 01:34:14 +08:00
|
|
|
*
|
2014-10-01 18:28:34 +08:00
|
|
|
* This is a best-effort routine. If an error occurs, path will
|
|
|
|
* either be left unmodified or will name a different symlink in a
|
|
|
|
* symlink chain that started with the original path.
|
2007-07-27 01:34:14 +08:00
|
|
|
*/
|
2014-10-01 18:28:34 +08:00
|
|
|
static void resolve_symlink(struct strbuf *path)
|
2007-07-27 01:34:14 +08:00
|
|
|
{
|
|
|
|
int depth = MAXDEPTH;
|
2014-10-01 18:28:33 +08:00
|
|
|
static struct strbuf link = STRBUF_INIT;
|
2007-07-27 01:34:14 +08:00
|
|
|
|
|
|
|
while (depth--) {
|
2014-10-01 18:28:34 +08:00
|
|
|
if (strbuf_readlink(&link, path->buf, path->len) < 0)
|
2014-10-01 18:28:33 +08:00
|
|
|
break;
|
2007-07-27 01:34:14 +08:00
|
|
|
|
2014-10-01 18:28:34 +08:00
|
|
|
if (is_absolute_path(link.buf))
|
2007-07-27 01:34:14 +08:00
|
|
|
/* absolute path simply replaces p */
|
2014-10-01 18:28:34 +08:00
|
|
|
strbuf_reset(path);
|
2014-10-01 18:28:35 +08:00
|
|
|
else
|
2007-07-27 01:34:14 +08:00
|
|
|
/*
|
2014-10-01 18:28:33 +08:00
|
|
|
* link is a relative path, so replace the
|
2007-07-27 01:34:14 +08:00
|
|
|
* last element of p with it.
|
|
|
|
*/
|
2014-10-01 18:28:35 +08:00
|
|
|
trim_last_path_component(path);
|
2014-10-01 18:28:34 +08:00
|
|
|
|
|
|
|
strbuf_addbuf(path, &link);
|
2007-07-27 01:34:14 +08:00
|
|
|
}
|
2014-10-01 18:28:33 +08:00
|
|
|
strbuf_reset(&link);
|
2007-07-27 01:34:14 +08:00
|
|
|
}
|
|
|
|
|
2014-06-20 22:42:48 +08:00
|
|
|
/* Make sure errno contains a meaningful value on error */
|
lockfile.c: introduce 'hold_lock_file_for_update_mode'
We use 'hold_lock_file_for_update' (and the '_timeout') variant to
acquire a lock when updating references, the commit-graph file, and so
on.
In particular, the commit-graph machinery uses this to acquire a
temporary file that is used to write a non-split commit-graph. In a
subsequent commit, an issue in the commit-graph machinery produces
graph files that have a different permission based on whether or not
they are part of a multi-layer graph will be addressed.
To do so, the commit-graph machinery will need a version of
'hold_lock_file_for_update' that takes the permission bits from the
caller.
Introduce such a function in this patch for both the
'hold_lock_file_for_update' and 'hold_lock_file_for_update_timeout'
functions, and leave the existing functions alone by inlining their
definitions in terms of the new mode variants.
Note that, like in the previous commit, 'hold_lock_file_for_update_mode'
is not guarenteed to set the given mode, since it may be modified by
both the umask and 'core.sharedRepository'.
Note also that even though the commit-graph machinery only calls
'hold_lock_file_for_update', that this is defined in terms of
'hold_lock_file_for_update_timeout', and so both need an additional mode
parameter here.
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-04-28 00:27:58 +08:00
|
|
|
static int lock_file(struct lock_file *lk, const char *path, int flags,
|
|
|
|
int mode)
|
2006-06-07 03:51:49 +08:00
|
|
|
{
|
2015-08-10 17:47:41 +08:00
|
|
|
struct strbuf filename = STRBUF_INIT;
|
2014-10-01 18:28:13 +08:00
|
|
|
|
2015-08-10 17:47:41 +08:00
|
|
|
strbuf_addstr(&filename, path);
|
|
|
|
if (!(flags & LOCK_NO_DEREF))
|
|
|
|
resolve_symlink(&filename);
|
2014-11-02 14:24:37 +08:00
|
|
|
|
2015-08-10 17:47:41 +08:00
|
|
|
strbuf_addstr(&filename, LOCK_SUFFIX);
|
lockfile.c: introduce 'hold_lock_file_for_update_mode'
We use 'hold_lock_file_for_update' (and the '_timeout') variant to
acquire a lock when updating references, the commit-graph file, and so
on.
In particular, the commit-graph machinery uses this to acquire a
temporary file that is used to write a non-split commit-graph. In a
subsequent commit, an issue in the commit-graph machinery produces
graph files that have a different permission based on whether or not
they are part of a multi-layer graph will be addressed.
To do so, the commit-graph machinery will need a version of
'hold_lock_file_for_update' that takes the permission bits from the
caller.
Introduce such a function in this patch for both the
'hold_lock_file_for_update' and 'hold_lock_file_for_update_timeout'
functions, and leave the existing functions alone by inlining their
definitions in terms of the new mode variants.
Note that, like in the previous commit, 'hold_lock_file_for_update_mode'
is not guarenteed to set the given mode, since it may be modified by
both the umask and 'core.sharedRepository'.
Note also that even though the commit-graph machinery only calls
'hold_lock_file_for_update', that this is defined in terms of
'hold_lock_file_for_update_timeout', and so both need an additional mode
parameter here.
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-04-28 00:27:58 +08:00
|
|
|
lk->tempfile = create_tempfile_mode(filename.buf, mode);
|
2015-08-10 17:47:41 +08:00
|
|
|
strbuf_release(&filename);
|
tempfile: auto-allocate tempfiles on heap
The previous commit taught the tempfile code to give up
ownership over tempfiles that have been renamed or deleted.
That makes it possible to use a stack variable like this:
struct tempfile t;
create_tempfile(&t, ...);
...
if (!err)
rename_tempfile(&t, ...);
else
delete_tempfile(&t);
But doing it this way has a high potential for creating
memory errors. The tempfile we pass to create_tempfile()
ends up on a global linked list, and it's not safe for it to
go out of scope until we've called one of those two
deactivation functions.
Imagine that we add an early return from the function that
forgets to call delete_tempfile(). With a static or heap
tempfile variable, the worst case is that the tempfile hangs
around until the program exits (and some functions like
setup_shallow_temporary rely on this intentionally, creating
a tempfile and then leaving it for later cleanup).
But with a stack variable as above, this is a serious memory
error: the variable goes out of scope and may be filled with
garbage by the time the tempfile code looks at it. Let's
see if we can make it harder to get this wrong.
Since many callers need to allocate arbitrary numbers of
tempfiles, we can't rely on static storage as a general
solution. So we need to turn to the heap. We could just ask
all callers to pass us a heap variable, but that puts the
burden on them to call free() at the right time.
Instead, let's have the tempfile code handle the heap
allocation _and_ the deallocation (when the tempfile is
deactivated and removed from the list).
This changes the return value of all of the creation
functions. For the cleanup functions (delete and rename),
we'll add one extra bit of safety: instead of taking a
tempfile pointer, we'll take a pointer-to-pointer and set it
to NULL after freeing the object. This makes it safe to
double-call functions like delete_tempfile(), as the second
call treats the NULL input as a noop. Several callsites
follow this pattern.
The resulting patch does have a fair bit of noise, as each
caller needs to be converted to handle:
1. Storing a pointer instead of the struct itself.
2. Passing the pointer instead of taking the struct
address.
3. Handling a "struct tempfile *" return instead of a file
descriptor.
We could play games to make this less noisy. For example, by
defining the tempfile like this:
struct tempfile {
struct heap_allocated_part_of_tempfile {
int fd;
...etc
} *actual_data;
}
Callers would continue to have a "struct tempfile", and it
would be "active" only when the inner pointer was non-NULL.
But that just makes things more awkward in the long run.
There aren't that many callers, so we can simply bite
the bullet and adjust all of them. And the compiler makes it
easy for us to find them all.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-05 20:15:08 +08:00
|
|
|
return lk->tempfile ? lk->tempfile->fd : -1;
|
2006-06-07 03:51:49 +08:00
|
|
|
}
|
|
|
|
|
2015-05-11 18:35:25 +08:00
|
|
|
/*
|
|
|
|
* Constants defining the gaps between attempts to lock a file. The
|
|
|
|
* first backoff period is approximately INITIAL_BACKOFF_MS
|
|
|
|
* milliseconds. The longest backoff period is approximately
|
|
|
|
* (BACKOFF_MAX_MULTIPLIER * INITIAL_BACKOFF_MS) milliseconds.
|
|
|
|
*/
|
|
|
|
#define INITIAL_BACKOFF_MS 1L
|
|
|
|
#define BACKOFF_MAX_MULTIPLIER 1000
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Try locking path, retrying with quadratic backoff for at least
|
|
|
|
* timeout_ms milliseconds. If timeout_ms is 0, try locking the file
|
|
|
|
* exactly once. If timeout_ms is -1, try indefinitely.
|
|
|
|
*/
|
|
|
|
static int lock_file_timeout(struct lock_file *lk, const char *path,
|
lockfile.c: introduce 'hold_lock_file_for_update_mode'
We use 'hold_lock_file_for_update' (and the '_timeout') variant to
acquire a lock when updating references, the commit-graph file, and so
on.
In particular, the commit-graph machinery uses this to acquire a
temporary file that is used to write a non-split commit-graph. In a
subsequent commit, an issue in the commit-graph machinery produces
graph files that have a different permission based on whether or not
they are part of a multi-layer graph will be addressed.
To do so, the commit-graph machinery will need a version of
'hold_lock_file_for_update' that takes the permission bits from the
caller.
Introduce such a function in this patch for both the
'hold_lock_file_for_update' and 'hold_lock_file_for_update_timeout'
functions, and leave the existing functions alone by inlining their
definitions in terms of the new mode variants.
Note that, like in the previous commit, 'hold_lock_file_for_update_mode'
is not guarenteed to set the given mode, since it may be modified by
both the umask and 'core.sharedRepository'.
Note also that even though the commit-graph machinery only calls
'hold_lock_file_for_update', that this is defined in terms of
'hold_lock_file_for_update_timeout', and so both need an additional mode
parameter here.
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-04-28 00:27:58 +08:00
|
|
|
int flags, long timeout_ms, int mode)
|
2015-05-11 18:35:25 +08:00
|
|
|
{
|
|
|
|
int n = 1;
|
|
|
|
int multiplier = 1;
|
2015-06-06 03:45:06 +08:00
|
|
|
long remaining_ms = 0;
|
2015-05-11 18:35:25 +08:00
|
|
|
static int random_initialized = 0;
|
|
|
|
|
|
|
|
if (timeout_ms == 0)
|
lockfile.c: introduce 'hold_lock_file_for_update_mode'
We use 'hold_lock_file_for_update' (and the '_timeout') variant to
acquire a lock when updating references, the commit-graph file, and so
on.
In particular, the commit-graph machinery uses this to acquire a
temporary file that is used to write a non-split commit-graph. In a
subsequent commit, an issue in the commit-graph machinery produces
graph files that have a different permission based on whether or not
they are part of a multi-layer graph will be addressed.
To do so, the commit-graph machinery will need a version of
'hold_lock_file_for_update' that takes the permission bits from the
caller.
Introduce such a function in this patch for both the
'hold_lock_file_for_update' and 'hold_lock_file_for_update_timeout'
functions, and leave the existing functions alone by inlining their
definitions in terms of the new mode variants.
Note that, like in the previous commit, 'hold_lock_file_for_update_mode'
is not guarenteed to set the given mode, since it may be modified by
both the umask and 'core.sharedRepository'.
Note also that even though the commit-graph machinery only calls
'hold_lock_file_for_update', that this is defined in terms of
'hold_lock_file_for_update_timeout', and so both need an additional mode
parameter here.
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-04-28 00:27:58 +08:00
|
|
|
return lock_file(lk, path, flags, mode);
|
2015-05-11 18:35:25 +08:00
|
|
|
|
|
|
|
if (!random_initialized) {
|
2015-06-06 03:45:04 +08:00
|
|
|
srand((unsigned int)getpid());
|
2015-05-11 18:35:25 +08:00
|
|
|
random_initialized = 1;
|
|
|
|
}
|
|
|
|
|
2015-06-06 03:45:06 +08:00
|
|
|
if (timeout_ms > 0)
|
|
|
|
remaining_ms = timeout_ms;
|
2015-05-11 18:35:25 +08:00
|
|
|
|
|
|
|
while (1) {
|
2015-06-06 03:45:06 +08:00
|
|
|
long backoff_ms, wait_ms;
|
2015-05-11 18:35:25 +08:00
|
|
|
int fd;
|
|
|
|
|
lockfile.c: introduce 'hold_lock_file_for_update_mode'
We use 'hold_lock_file_for_update' (and the '_timeout') variant to
acquire a lock when updating references, the commit-graph file, and so
on.
In particular, the commit-graph machinery uses this to acquire a
temporary file that is used to write a non-split commit-graph. In a
subsequent commit, an issue in the commit-graph machinery produces
graph files that have a different permission based on whether or not
they are part of a multi-layer graph will be addressed.
To do so, the commit-graph machinery will need a version of
'hold_lock_file_for_update' that takes the permission bits from the
caller.
Introduce such a function in this patch for both the
'hold_lock_file_for_update' and 'hold_lock_file_for_update_timeout'
functions, and leave the existing functions alone by inlining their
definitions in terms of the new mode variants.
Note that, like in the previous commit, 'hold_lock_file_for_update_mode'
is not guarenteed to set the given mode, since it may be modified by
both the umask and 'core.sharedRepository'.
Note also that even though the commit-graph machinery only calls
'hold_lock_file_for_update', that this is defined in terms of
'hold_lock_file_for_update_timeout', and so both need an additional mode
parameter here.
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-04-28 00:27:58 +08:00
|
|
|
fd = lock_file(lk, path, flags, mode);
|
2015-05-11 18:35:25 +08:00
|
|
|
|
|
|
|
if (fd >= 0)
|
|
|
|
return fd; /* success */
|
|
|
|
else if (errno != EEXIST)
|
|
|
|
return -1; /* failure other than lock held */
|
2015-06-06 03:45:06 +08:00
|
|
|
else if (timeout_ms > 0 && remaining_ms <= 0)
|
2015-05-11 18:35:25 +08:00
|
|
|
return -1; /* failure due to timeout */
|
|
|
|
|
|
|
|
backoff_ms = multiplier * INITIAL_BACKOFF_MS;
|
|
|
|
/* back off for between 0.75*backoff_ms and 1.25*backoff_ms */
|
2015-06-06 03:45:06 +08:00
|
|
|
wait_ms = (750 + rand() % 500) * backoff_ms / 1000;
|
2015-06-06 03:45:07 +08:00
|
|
|
sleep_millisec(wait_ms);
|
2015-06-06 03:45:06 +08:00
|
|
|
remaining_ms -= wait_ms;
|
2015-05-11 18:35:25 +08:00
|
|
|
|
|
|
|
/* Recursion: (n+1)^2 = n^2 + 2n + 1 */
|
|
|
|
multiplier += 2*n + 1;
|
|
|
|
if (multiplier > BACKOFF_MAX_MULTIPLIER)
|
|
|
|
multiplier = BACKOFF_MAX_MULTIPLIER;
|
|
|
|
else
|
|
|
|
n++;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-06-20 22:42:47 +08:00
|
|
|
void unable_to_lock_message(const char *path, int err, struct strbuf *buf)
|
2009-02-19 20:54:18 +08:00
|
|
|
{
|
2009-03-04 23:00:44 +08:00
|
|
|
if (err == EEXIST) {
|
2016-03-02 01:04:09 +08:00
|
|
|
strbuf_addf(buf, _("Unable to create '%s.lock': %s.\n\n"
|
2016-03-02 01:04:10 +08:00
|
|
|
"Another git process seems to be running in this repository, e.g.\n"
|
|
|
|
"an editor opened by 'git commit'. Please make sure all processes\n"
|
|
|
|
"are terminated then try again. If it still fails, a git process\n"
|
|
|
|
"may have crashed in this repository earlier:\n"
|
|
|
|
"remove the file manually to continue."),
|
2011-03-17 19:26:46 +08:00
|
|
|
absolute_path(path), strerror(err));
|
2009-09-27 07:15:09 +08:00
|
|
|
} else
|
2016-03-02 01:04:09 +08:00
|
|
|
strbuf_addf(buf, _("Unable to create '%s.lock': %s"),
|
2011-03-17 19:26:46 +08:00
|
|
|
absolute_path(path), strerror(err));
|
2009-09-27 07:15:09 +08:00
|
|
|
}
|
|
|
|
|
2014-10-01 18:28:05 +08:00
|
|
|
NORETURN void unable_to_lock_die(const char *path, int err)
|
2009-09-27 07:15:09 +08:00
|
|
|
{
|
2014-06-20 22:42:47 +08:00
|
|
|
struct strbuf buf = STRBUF_INIT;
|
|
|
|
|
|
|
|
unable_to_lock_message(path, err, &buf);
|
|
|
|
die("%s", buf.buf);
|
2009-02-19 20:54:18 +08:00
|
|
|
}
|
|
|
|
|
2014-06-20 22:42:48 +08:00
|
|
|
/* This should return a meaningful errno on failure */
|
lockfile.c: introduce 'hold_lock_file_for_update_mode'
We use 'hold_lock_file_for_update' (and the '_timeout') variant to
acquire a lock when updating references, the commit-graph file, and so
on.
In particular, the commit-graph machinery uses this to acquire a
temporary file that is used to write a non-split commit-graph. In a
subsequent commit, an issue in the commit-graph machinery produces
graph files that have a different permission based on whether or not
they are part of a multi-layer graph will be addressed.
To do so, the commit-graph machinery will need a version of
'hold_lock_file_for_update' that takes the permission bits from the
caller.
Introduce such a function in this patch for both the
'hold_lock_file_for_update' and 'hold_lock_file_for_update_timeout'
functions, and leave the existing functions alone by inlining their
definitions in terms of the new mode variants.
Note that, like in the previous commit, 'hold_lock_file_for_update_mode'
is not guarenteed to set the given mode, since it may be modified by
both the umask and 'core.sharedRepository'.
Note also that even though the commit-graph machinery only calls
'hold_lock_file_for_update', that this is defined in terms of
'hold_lock_file_for_update_timeout', and so both need an additional mode
parameter here.
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-04-28 00:27:58 +08:00
|
|
|
int hold_lock_file_for_update_timeout_mode(struct lock_file *lk,
|
|
|
|
const char *path, int flags,
|
|
|
|
long timeout_ms, int mode)
|
2006-08-12 16:03:47 +08:00
|
|
|
{
|
lockfile.c: introduce 'hold_lock_file_for_update_mode'
We use 'hold_lock_file_for_update' (and the '_timeout') variant to
acquire a lock when updating references, the commit-graph file, and so
on.
In particular, the commit-graph machinery uses this to acquire a
temporary file that is used to write a non-split commit-graph. In a
subsequent commit, an issue in the commit-graph machinery produces
graph files that have a different permission based on whether or not
they are part of a multi-layer graph will be addressed.
To do so, the commit-graph machinery will need a version of
'hold_lock_file_for_update' that takes the permission bits from the
caller.
Introduce such a function in this patch for both the
'hold_lock_file_for_update' and 'hold_lock_file_for_update_timeout'
functions, and leave the existing functions alone by inlining their
definitions in terms of the new mode variants.
Note that, like in the previous commit, 'hold_lock_file_for_update_mode'
is not guarenteed to set the given mode, since it may be modified by
both the umask and 'core.sharedRepository'.
Note also that even though the commit-graph machinery only calls
'hold_lock_file_for_update', that this is defined in terms of
'hold_lock_file_for_update_timeout', and so both need an additional mode
parameter here.
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-04-28 00:27:58 +08:00
|
|
|
int fd = lock_file_timeout(lk, path, flags, timeout_ms, mode);
|
2016-12-08 02:56:26 +08:00
|
|
|
if (fd < 0) {
|
|
|
|
if (flags & LOCK_DIE_ON_ERROR)
|
|
|
|
unable_to_lock_die(path, errno);
|
|
|
|
if (flags & LOCK_REPORT_ON_ERROR) {
|
|
|
|
struct strbuf buf = STRBUF_INIT;
|
|
|
|
unable_to_lock_message(path, errno, &buf);
|
|
|
|
error("%s", buf.buf);
|
|
|
|
strbuf_release(&buf);
|
|
|
|
}
|
|
|
|
}
|
2006-08-12 16:03:47 +08:00
|
|
|
return fd;
|
|
|
|
}
|
|
|
|
|
2014-10-01 18:28:39 +08:00
|
|
|
char *get_locked_file_path(struct lock_file *lk)
|
|
|
|
{
|
2015-08-10 17:47:41 +08:00
|
|
|
struct strbuf ret = STRBUF_INIT;
|
2014-10-01 19:14:47 +08:00
|
|
|
|
tempfile: auto-allocate tempfiles on heap
The previous commit taught the tempfile code to give up
ownership over tempfiles that have been renamed or deleted.
That makes it possible to use a stack variable like this:
struct tempfile t;
create_tempfile(&t, ...);
...
if (!err)
rename_tempfile(&t, ...);
else
delete_tempfile(&t);
But doing it this way has a high potential for creating
memory errors. The tempfile we pass to create_tempfile()
ends up on a global linked list, and it's not safe for it to
go out of scope until we've called one of those two
deactivation functions.
Imagine that we add an early return from the function that
forgets to call delete_tempfile(). With a static or heap
tempfile variable, the worst case is that the tempfile hangs
around until the program exits (and some functions like
setup_shallow_temporary rely on this intentionally, creating
a tempfile and then leaving it for later cleanup).
But with a stack variable as above, this is a serious memory
error: the variable goes out of scope and may be filled with
garbage by the time the tempfile code looks at it. Let's
see if we can make it harder to get this wrong.
Since many callers need to allocate arbitrary numbers of
tempfiles, we can't rely on static storage as a general
solution. So we need to turn to the heap. We could just ask
all callers to pass us a heap variable, but that puts the
burden on them to call free() at the right time.
Instead, let's have the tempfile code handle the heap
allocation _and_ the deallocation (when the tempfile is
deactivated and removed from the list).
This changes the return value of all of the creation
functions. For the cleanup functions (delete and rename),
we'll add one extra bit of safety: instead of taking a
tempfile pointer, we'll take a pointer-to-pointer and set it
to NULL after freeing the object. This makes it safe to
double-call functions like delete_tempfile(), as the second
call treats the NULL input as a noop. Several callsites
follow this pattern.
The resulting patch does have a fair bit of noise, as each
caller needs to be converted to handle:
1. Storing a pointer instead of the struct itself.
2. Passing the pointer instead of taking the struct
address.
3. Handling a "struct tempfile *" return instead of a file
descriptor.
We could play games to make this less noisy. For example, by
defining the tempfile like this:
struct tempfile {
struct heap_allocated_part_of_tempfile {
int fd;
...etc
} *actual_data;
}
Callers would continue to have a "struct tempfile", and it
would be "active" only when the inner pointer was non-NULL.
But that just makes things more awkward in the long run.
There aren't that many callers, so we can simply bite
the bullet and adjust all of them. And the compiler makes it
easy for us to find them all.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-05 20:15:08 +08:00
|
|
|
strbuf_addstr(&ret, get_tempfile_path(lk->tempfile));
|
2015-08-10 17:47:41 +08:00
|
|
|
if (ret.len <= LOCK_SUFFIX_LEN ||
|
|
|
|
strcmp(ret.buf + ret.len - LOCK_SUFFIX_LEN, LOCK_SUFFIX))
|
2018-05-02 17:38:39 +08:00
|
|
|
BUG("get_locked_file_path() called for malformed lock object");
|
2015-08-10 17:47:40 +08:00
|
|
|
/* remove ".lock": */
|
2015-08-10 17:47:41 +08:00
|
|
|
strbuf_setlen(&ret, ret.len - LOCK_SUFFIX_LEN);
|
|
|
|
return strbuf_detach(&ret, NULL);
|
2014-07-15 01:29:58 +08:00
|
|
|
}
|
|
|
|
|
2014-10-01 18:28:36 +08:00
|
|
|
int commit_lock_file(struct lock_file *lk)
|
2006-06-07 03:51:49 +08:00
|
|
|
{
|
2015-08-10 17:47:40 +08:00
|
|
|
char *result_path = get_locked_file_path(lk);
|
2014-10-01 18:28:21 +08:00
|
|
|
|
2015-08-10 17:47:40 +08:00
|
|
|
if (commit_lock_file_to(lk, result_path)) {
|
2014-10-01 18:28:23 +08:00
|
|
|
int save_errno = errno;
|
2015-08-10 17:47:40 +08:00
|
|
|
free(result_path);
|
2014-10-01 18:28:23 +08:00
|
|
|
errno = save_errno;
|
2008-01-17 03:05:32 +08:00
|
|
|
return -1;
|
2014-10-01 18:28:23 +08:00
|
|
|
}
|
2015-08-10 17:47:40 +08:00
|
|
|
free(result_path);
|
2008-01-17 03:05:32 +08:00
|
|
|
return 0;
|
2006-06-07 03:51:49 +08:00
|
|
|
}
|