2006-06-06 23:51:49 +04:00
|
|
|
/*
|
|
|
|
* Copyright (c) 2005, Junio C Hamano
|
|
|
|
*/
|
|
|
|
#include "cache.h"
|
chain kill signals for cleanup functions
If a piece of code wanted to do some cleanup before exiting
(e.g., cleaning up a lockfile or a tempfile), our usual
strategy was to install a signal handler that did something
like this:
do_cleanup(); /* actual work */
signal(signo, SIG_DFL); /* restore previous behavior */
raise(signo); /* deliver signal, killing ourselves */
For a single handler, this works fine. However, if we want
to clean up two _different_ things, we run into a problem.
The most recently installed handler will run, but when it
removes itself as a handler, it doesn't put back the first
handler.
This patch introduces sigchain, a tiny library for handling
a stack of signal handlers. You sigchain_push each handler,
and use sigchain_pop to restore whoever was before you in
the stack.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-22 09:02:35 +03:00
|
|
|
#include "sigchain.h"
|
2006-06-06 23:51:49 +04:00
|
|
|
|
2014-10-01 14:28:14 +04:00
|
|
|
/*
|
|
|
|
* File write-locks as used by Git.
|
|
|
|
*
|
|
|
|
* For an overview of how to use the lockfile API, please see
|
|
|
|
*
|
|
|
|
* Documentation/technical/api-lockfile.txt
|
|
|
|
*
|
|
|
|
* This module keeps track of all locked files in lock_file_list for
|
|
|
|
* use at cleanup. This list and the lock_file objects that comprise
|
|
|
|
* it must be kept in self-consistent states at all time, because the
|
|
|
|
* program can be interrupted any time by a signal, in which case the
|
|
|
|
* signal handler will walk through the list attempting to clean up
|
|
|
|
* any open lock files.
|
|
|
|
*
|
|
|
|
* A lockfile is owned by the process that created it. The lock_file
|
|
|
|
* object has an "owner" field that records its owner. This field is
|
|
|
|
* used to prevent a forked process from closing a lockfile created by
|
|
|
|
* its parent.
|
|
|
|
*
|
lockfile: avoid transitory invalid states
Because remove_lock_file() can be called any time by the signal
handler, it is important that any lock_file objects that are in the
lock_file_list are always in a valid state. And since lock_file
objects are often reused (but are never removed from lock_file_list),
that means we have to be careful whenever mutating a lock_file object
to always keep it in a well-defined state.
This was formerly not the case, because part of the state was encoded
by setting lk->filename to the empty string vs. a valid filename. It
is wrong to assume that this string can be updated atomically; for
example, even
strcpy(lk->filename, value)
is unsafe. But the old code was even more reckless; for example,
strcpy(lk->filename, path);
if (!(flags & LOCK_NODEREF))
resolve_symlink(lk->filename, max_path_len);
strcat(lk->filename, ".lock");
During the call to resolve_symlink(), lk->filename contained the name
of the file that was being locked, not the name of the lockfile. If a
signal were raised during that interval, then the signal handler would
have deleted the valuable file!
We could probably continue to use the filename field to encode the
state by being careful to write characters 1..N-1 of the filename
first, and then overwrite the NUL at filename[0] with the first
character of the filename, but that would be awkward and error-prone.
So, instead of using the filename field to determine whether the
lock_file object is active, add a new field "lock_file::active" for
this purpose. Be careful to set this field only when filename really
contains the name of a file that should be deleted on cleanup.
Helped-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-10-01 14:28:27 +04:00
|
|
|
* The possible states of a lock_file object are as follows:
|
2014-10-01 14:28:14 +04:00
|
|
|
*
|
|
|
|
* - 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 the lock_file_list, and on_list is set.
|
|
|
|
*
|
|
|
|
* - Locked, lockfile open (after hold_lock_file_for_update(),
|
|
|
|
* hold_lock_file_for_append(), or reopen_lock_file()). In this
|
lockfile: avoid transitory invalid states
Because remove_lock_file() can be called any time by the signal
handler, it is important that any lock_file objects that are in the
lock_file_list are always in a valid state. And since lock_file
objects are often reused (but are never removed from lock_file_list),
that means we have to be careful whenever mutating a lock_file object
to always keep it in a well-defined state.
This was formerly not the case, because part of the state was encoded
by setting lk->filename to the empty string vs. a valid filename. It
is wrong to assume that this string can be updated atomically; for
example, even
strcpy(lk->filename, value)
is unsafe. But the old code was even more reckless; for example,
strcpy(lk->filename, path);
if (!(flags & LOCK_NODEREF))
resolve_symlink(lk->filename, max_path_len);
strcat(lk->filename, ".lock");
During the call to resolve_symlink(), lk->filename contained the name
of the file that was being locked, not the name of the lockfile. If a
signal were raised during that interval, then the signal handler would
have deleted the valuable file!
We could probably continue to use the filename field to encode the
state by being careful to write characters 1..N-1 of the filename
first, and then overwrite the NUL at filename[0] with the first
character of the filename, but that would be awkward and error-prone.
So, instead of using the filename field to determine whether the
lock_file object is active, add a new field "lock_file::active" for
this purpose. Be careful to set this field only when filename really
contains the name of a file that should be deleted on cleanup.
Helped-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-10-01 14:28:27 +04:00
|
|
|
* state:
|
|
|
|
* - the lockfile exists
|
|
|
|
* - active is set
|
|
|
|
* - filename holds the filename of the lockfile
|
|
|
|
* - fd holds a file descriptor open for writing to the lockfile
|
|
|
|
* - owner holds the PID of the process that locked the file
|
2014-10-01 14:28:14 +04:00
|
|
|
*
|
2014-10-01 14:28:22 +04:00
|
|
|
* - Locked, lockfile closed (after successful close_lock_file()).
|
|
|
|
* Same as the previous state, except that the lockfile is closed
|
|
|
|
* and fd is -1.
|
2014-10-01 14:28:14 +04:00
|
|
|
*
|
2014-10-01 14:28:22 +04:00
|
|
|
* - Unlocked (after commit_lock_file(), rollback_lock_file(), a
|
lockfile: avoid transitory invalid states
Because remove_lock_file() can be called any time by the signal
handler, it is important that any lock_file objects that are in the
lock_file_list are always in a valid state. And since lock_file
objects are often reused (but are never removed from lock_file_list),
that means we have to be careful whenever mutating a lock_file object
to always keep it in a well-defined state.
This was formerly not the case, because part of the state was encoded
by setting lk->filename to the empty string vs. a valid filename. It
is wrong to assume that this string can be updated atomically; for
example, even
strcpy(lk->filename, value)
is unsafe. But the old code was even more reckless; for example,
strcpy(lk->filename, path);
if (!(flags & LOCK_NODEREF))
resolve_symlink(lk->filename, max_path_len);
strcat(lk->filename, ".lock");
During the call to resolve_symlink(), lk->filename contained the name
of the file that was being locked, not the name of the lockfile. If a
signal were raised during that interval, then the signal handler would
have deleted the valuable file!
We could probably continue to use the filename field to encode the
state by being careful to write characters 1..N-1 of the filename
first, and then overwrite the NUL at filename[0] with the first
character of the filename, but that would be awkward and error-prone.
So, instead of using the filename field to determine whether the
lock_file object is active, add a new field "lock_file::active" for
this purpose. Be careful to set this field only when filename really
contains the name of a file that should be deleted on cleanup.
Helped-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-10-01 14:28:27 +04:00
|
|
|
* failed attempt to lock, or a failed close_lock_file()). In this
|
|
|
|
* state:
|
|
|
|
* - active is unset
|
|
|
|
* - filename[0] == '\0' (usually, though there are transitory states
|
|
|
|
* in which this condition doesn't hold). Client code should *not*
|
|
|
|
* rely on this fact!
|
|
|
|
* - fd is -1
|
|
|
|
* - the object is left registered in the lock_file_list, and
|
|
|
|
* on_list is set.
|
2014-10-01 14:28:14 +04:00
|
|
|
*/
|
|
|
|
|
2006-06-06 23:51:49 +04:00
|
|
|
static struct lock_file *lock_file_list;
|
|
|
|
|
|
|
|
static void remove_lock_file(void)
|
|
|
|
{
|
2007-04-21 14:11:10 +04:00
|
|
|
pid_t me = getpid();
|
|
|
|
|
2006-06-06 23:51:49 +04:00
|
|
|
while (lock_file_list) {
|
2014-10-01 14:28:19 +04:00
|
|
|
if (lock_file_list->owner == me)
|
|
|
|
rollback_lock_file(lock_file_list);
|
2006-06-06 23:51:49 +04:00
|
|
|
lock_file_list = lock_file_list->next;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void remove_lock_file_on_signal(int signo)
|
|
|
|
{
|
|
|
|
remove_lock_file();
|
chain kill signals for cleanup functions
If a piece of code wanted to do some cleanup before exiting
(e.g., cleaning up a lockfile or a tempfile), our usual
strategy was to install a signal handler that did something
like this:
do_cleanup(); /* actual work */
signal(signo, SIG_DFL); /* restore previous behavior */
raise(signo); /* deliver signal, killing ourselves */
For a single handler, this works fine. However, if we want
to clean up two _different_ things, we run into a problem.
The most recently installed handler will run, but when it
removes itself as a handler, it doesn't put back the first
handler.
This patch introduces sigchain, a tiny library for handling
a stack of signal handlers. You sigchain_push each handler,
and use sigchain_pop to restore whoever was before you in
the stack.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-22 09:02:35 +03:00
|
|
|
sigchain_pop(signo);
|
2006-06-06 23:51:49 +04:00
|
|
|
raise(signo);
|
|
|
|
}
|
|
|
|
|
2007-07-26 21:34:14 +04:00
|
|
|
/*
|
|
|
|
* p = absolute or relative path name
|
|
|
|
*
|
|
|
|
* Return a pointer into p showing the beginning of the last path name
|
|
|
|
* element. If p is empty or the root directory ("/"), just return p.
|
|
|
|
*/
|
|
|
|
static char *last_path_elm(char *p)
|
|
|
|
{
|
|
|
|
/* r starts pointing to null at the end of the string */
|
|
|
|
char *r = strchr(p, '\0');
|
|
|
|
|
|
|
|
if (r == p)
|
|
|
|
return p; /* just return empty string */
|
|
|
|
|
|
|
|
r--; /* back up to last non-null character */
|
|
|
|
|
|
|
|
/* back up past trailing slashes, if any */
|
|
|
|
while (r > p && *r == '/')
|
|
|
|
r--;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* then go backwards until I hit a slash, or the beginning of
|
|
|
|
* the string
|
|
|
|
*/
|
|
|
|
while (r > p && *(r-1) != '/')
|
|
|
|
r--;
|
|
|
|
return r;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/* We allow "recursive" symbolic links. Only within reason, though */
|
|
|
|
#define MAXDEPTH 5
|
|
|
|
|
|
|
|
/*
|
|
|
|
* p = path that may be a symlink
|
|
|
|
* s = full size of p
|
|
|
|
*
|
|
|
|
* If p is a symlink, attempt to overwrite p with a path to the real
|
|
|
|
* file or directory (which may or may not exist), following a chain of
|
|
|
|
* symlinks if necessary. Otherwise, leave p unmodified.
|
|
|
|
*
|
|
|
|
* This is a best-effort routine. If an error occurs, p will either be
|
|
|
|
* left unmodified or will name a different symlink in a symlink chain
|
|
|
|
* that started with p's initial contents.
|
|
|
|
*
|
|
|
|
* Always returns p.
|
|
|
|
*/
|
|
|
|
|
|
|
|
static char *resolve_symlink(char *p, size_t s)
|
|
|
|
{
|
|
|
|
int depth = MAXDEPTH;
|
|
|
|
|
|
|
|
while (depth--) {
|
|
|
|
char link[PATH_MAX];
|
|
|
|
int link_len = readlink(p, link, sizeof(link));
|
|
|
|
if (link_len < 0) {
|
|
|
|
/* not a symlink anymore */
|
|
|
|
return p;
|
|
|
|
}
|
|
|
|
else if (link_len < sizeof(link))
|
|
|
|
/* readlink() never null-terminates */
|
|
|
|
link[link_len] = '\0';
|
|
|
|
else {
|
|
|
|
warning("%s: symlink too long", p);
|
|
|
|
return p;
|
|
|
|
}
|
|
|
|
|
2007-11-26 01:29:03 +03:00
|
|
|
if (is_absolute_path(link)) {
|
2007-07-26 21:34:14 +04:00
|
|
|
/* absolute path simply replaces p */
|
|
|
|
if (link_len < s)
|
|
|
|
strcpy(p, link);
|
|
|
|
else {
|
|
|
|
warning("%s: symlink too long", p);
|
|
|
|
return p;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
/*
|
|
|
|
* link is a relative path, so I must replace the
|
|
|
|
* last element of p with it.
|
|
|
|
*/
|
2009-05-01 13:06:36 +04:00
|
|
|
char *r = (char *)last_path_elm(p);
|
2007-07-26 21:34:14 +04:00
|
|
|
if (r - p + link_len < s)
|
|
|
|
strcpy(r, link);
|
|
|
|
else {
|
|
|
|
warning("%s: symlink too long", p);
|
|
|
|
return p;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return p;
|
|
|
|
}
|
|
|
|
|
2014-06-20 18:42:48 +04:00
|
|
|
/* Make sure errno contains a meaningful value on error */
|
2008-10-18 02:44:39 +04:00
|
|
|
static int lock_file(struct lock_file *lk, const char *path, int flags)
|
2006-06-06 23:51:49 +04:00
|
|
|
{
|
2007-07-26 21:34:14 +04:00
|
|
|
/*
|
2014-10-01 14:28:15 +04:00
|
|
|
* subtract LOCK_SUFFIX_LEN from size to make sure there's
|
|
|
|
* room for adding ".lock" for the lock file name:
|
2007-07-26 21:34:14 +04:00
|
|
|
*/
|
2014-10-01 14:28:15 +04:00
|
|
|
static const size_t max_path_len = sizeof(lk->filename) -
|
|
|
|
LOCK_SUFFIX_LEN;
|
2013-07-06 23:48:52 +04:00
|
|
|
|
2014-10-01 14:28:13 +04:00
|
|
|
if (!lock_file_list) {
|
|
|
|
/* One-time initialization */
|
|
|
|
sigchain_push_common(remove_lock_file_on_signal);
|
|
|
|
atexit(remove_lock_file);
|
|
|
|
}
|
|
|
|
|
lockfile: avoid transitory invalid states
Because remove_lock_file() can be called any time by the signal
handler, it is important that any lock_file objects that are in the
lock_file_list are always in a valid state. And since lock_file
objects are often reused (but are never removed from lock_file_list),
that means we have to be careful whenever mutating a lock_file object
to always keep it in a well-defined state.
This was formerly not the case, because part of the state was encoded
by setting lk->filename to the empty string vs. a valid filename. It
is wrong to assume that this string can be updated atomically; for
example, even
strcpy(lk->filename, value)
is unsafe. But the old code was even more reckless; for example,
strcpy(lk->filename, path);
if (!(flags & LOCK_NODEREF))
resolve_symlink(lk->filename, max_path_len);
strcat(lk->filename, ".lock");
During the call to resolve_symlink(), lk->filename contained the name
of the file that was being locked, not the name of the lockfile. If a
signal were raised during that interval, then the signal handler would
have deleted the valuable file!
We could probably continue to use the filename field to encode the
state by being careful to write characters 1..N-1 of the filename
first, and then overwrite the NUL at filename[0] with the first
character of the filename, but that would be awkward and error-prone.
So, instead of using the filename field to determine whether the
lock_file object is active, add a new field "lock_file::active" for
this purpose. Be careful to set this field only when filename really
contains the name of a file that should be deleted on cleanup.
Helped-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-10-01 14:28:27 +04:00
|
|
|
if (lk->active)
|
|
|
|
die("BUG: cannot lock_file(\"%s\") using active struct lock_file",
|
|
|
|
path);
|
2014-10-01 14:28:13 +04:00
|
|
|
if (!lk->on_list) {
|
|
|
|
/* Initialize *lk and add it to lock_file_list: */
|
|
|
|
lk->fd = -1;
|
lockfile: avoid transitory invalid states
Because remove_lock_file() can be called any time by the signal
handler, it is important that any lock_file objects that are in the
lock_file_list are always in a valid state. And since lock_file
objects are often reused (but are never removed from lock_file_list),
that means we have to be careful whenever mutating a lock_file object
to always keep it in a well-defined state.
This was formerly not the case, because part of the state was encoded
by setting lk->filename to the empty string vs. a valid filename. It
is wrong to assume that this string can be updated atomically; for
example, even
strcpy(lk->filename, value)
is unsafe. But the old code was even more reckless; for example,
strcpy(lk->filename, path);
if (!(flags & LOCK_NODEREF))
resolve_symlink(lk->filename, max_path_len);
strcat(lk->filename, ".lock");
During the call to resolve_symlink(), lk->filename contained the name
of the file that was being locked, not the name of the lockfile. If a
signal were raised during that interval, then the signal handler would
have deleted the valuable file!
We could probably continue to use the filename field to encode the
state by being careful to write characters 1..N-1 of the filename
first, and then overwrite the NUL at filename[0] with the first
character of the filename, but that would be awkward and error-prone.
So, instead of using the filename field to determine whether the
lock_file object is active, add a new field "lock_file::active" for
this purpose. Be careful to set this field only when filename really
contains the name of a file that should be deleted on cleanup.
Helped-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-10-01 14:28:27 +04:00
|
|
|
lk->active = 0;
|
2014-10-01 14:28:13 +04:00
|
|
|
lk->owner = 0;
|
|
|
|
lk->filename[0] = 0;
|
|
|
|
lk->next = lock_file_list;
|
|
|
|
lock_file_list = lk;
|
|
|
|
lk->on_list = 1;
|
|
|
|
}
|
|
|
|
|
2014-06-20 18:42:48 +04:00
|
|
|
if (strlen(path) >= max_path_len) {
|
|
|
|
errno = ENAMETOOLONG;
|
2013-07-06 23:48:52 +04:00
|
|
|
return -1;
|
2014-06-20 18:42:48 +04:00
|
|
|
}
|
2013-07-06 23:48:52 +04:00
|
|
|
strcpy(lk->filename, path);
|
2008-10-18 02:44:39 +04:00
|
|
|
if (!(flags & LOCK_NODEREF))
|
2013-07-06 23:48:52 +04:00
|
|
|
resolve_symlink(lk->filename, max_path_len);
|
2014-10-01 14:28:15 +04:00
|
|
|
strcat(lk->filename, LOCK_SUFFIX);
|
2007-11-13 23:05:03 +03:00
|
|
|
lk->fd = open(lk->filename, O_RDWR | O_CREAT | O_EXCL, 0666);
|
2014-10-01 14:28:18 +04:00
|
|
|
if (lk->fd < 0) {
|
2007-01-02 22:19:05 +03:00
|
|
|
lk->filename[0] = 0;
|
2014-10-01 14:28:18 +04:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
lk->owner = getpid();
|
lockfile: avoid transitory invalid states
Because remove_lock_file() can be called any time by the signal
handler, it is important that any lock_file objects that are in the
lock_file_list are always in a valid state. And since lock_file
objects are often reused (but are never removed from lock_file_list),
that means we have to be careful whenever mutating a lock_file object
to always keep it in a well-defined state.
This was formerly not the case, because part of the state was encoded
by setting lk->filename to the empty string vs. a valid filename. It
is wrong to assume that this string can be updated atomically; for
example, even
strcpy(lk->filename, value)
is unsafe. But the old code was even more reckless; for example,
strcpy(lk->filename, path);
if (!(flags & LOCK_NODEREF))
resolve_symlink(lk->filename, max_path_len);
strcat(lk->filename, ".lock");
During the call to resolve_symlink(), lk->filename contained the name
of the file that was being locked, not the name of the lockfile. If a
signal were raised during that interval, then the signal handler would
have deleted the valuable file!
We could probably continue to use the filename field to encode the
state by being careful to write characters 1..N-1 of the filename
first, and then overwrite the NUL at filename[0] with the first
character of the filename, but that would be awkward and error-prone.
So, instead of using the filename field to determine whether the
lock_file object is active, add a new field "lock_file::active" for
this purpose. Be careful to set this field only when filename really
contains the name of a file that should be deleted on cleanup.
Helped-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-10-01 14:28:27 +04:00
|
|
|
lk->active = 1;
|
2014-10-01 14:28:18 +04:00
|
|
|
if (adjust_shared_perm(lk->filename)) {
|
|
|
|
int save_errno = errno;
|
|
|
|
error("cannot fix permission bits on %s", lk->filename);
|
|
|
|
rollback_lock_file(lk);
|
|
|
|
errno = save_errno;
|
|
|
|
return -1;
|
|
|
|
}
|
2007-11-13 23:05:03 +03:00
|
|
|
return lk->fd;
|
2006-06-06 23:51:49 +04:00
|
|
|
}
|
|
|
|
|
2014-06-20 18:42:47 +04:00
|
|
|
void unable_to_lock_message(const char *path, int err, struct strbuf *buf)
|
2009-02-19 15:54:18 +03:00
|
|
|
{
|
2009-03-04 18:00:44 +03:00
|
|
|
if (err == EEXIST) {
|
2014-06-20 18:42:47 +04:00
|
|
|
strbuf_addf(buf, "Unable to create '%s.lock': %s.\n\n"
|
2009-02-19 15:54:18 +03:00
|
|
|
"If no other git process is currently running, this probably means a\n"
|
|
|
|
"git process crashed in this repository earlier. Make sure no other git\n"
|
|
|
|
"process is running and remove the file manually to continue.",
|
2011-03-17 14:26:46 +03:00
|
|
|
absolute_path(path), strerror(err));
|
2009-09-27 03:15:09 +04:00
|
|
|
} else
|
2014-06-20 18:42:47 +04:00
|
|
|
strbuf_addf(buf, "Unable to create '%s.lock': %s",
|
2011-03-17 14:26:46 +03:00
|
|
|
absolute_path(path), strerror(err));
|
2009-09-27 03:15:09 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
int unable_to_lock_error(const char *path, int err)
|
|
|
|
{
|
2014-06-20 18:42:47 +04:00
|
|
|
struct strbuf buf = STRBUF_INIT;
|
|
|
|
|
|
|
|
unable_to_lock_message(path, err, &buf);
|
|
|
|
error("%s", buf.buf);
|
|
|
|
strbuf_release(&buf);
|
2009-09-27 03:15:09 +04:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
2014-10-01 14:28:05 +04:00
|
|
|
NORETURN void unable_to_lock_die(const char *path, int err)
|
2009-09-27 03:15:09 +04:00
|
|
|
{
|
2014-06-20 18:42:47 +04:00
|
|
|
struct strbuf buf = STRBUF_INIT;
|
|
|
|
|
|
|
|
unable_to_lock_message(path, err, &buf);
|
|
|
|
die("%s", buf.buf);
|
2009-02-19 15:54:18 +03:00
|
|
|
}
|
|
|
|
|
2014-06-20 18:42:48 +04:00
|
|
|
/* This should return a meaningful errno on failure */
|
2008-10-18 02:44:39 +04:00
|
|
|
int hold_lock_file_for_update(struct lock_file *lk, const char *path, int flags)
|
2006-08-12 12:03:47 +04:00
|
|
|
{
|
2008-10-18 02:44:39 +04:00
|
|
|
int fd = lock_file(lk, path, flags);
|
|
|
|
if (fd < 0 && (flags & LOCK_DIE_ON_ERROR))
|
2014-10-01 14:28:05 +04:00
|
|
|
unable_to_lock_die(path, errno);
|
2006-08-12 12:03:47 +04:00
|
|
|
return fd;
|
|
|
|
}
|
|
|
|
|
2008-10-18 02:44:39 +04:00
|
|
|
int hold_lock_file_for_append(struct lock_file *lk, const char *path, int flags)
|
2008-04-18 03:32:26 +04:00
|
|
|
{
|
|
|
|
int fd, orig_fd;
|
|
|
|
|
2008-10-18 02:44:39 +04:00
|
|
|
fd = lock_file(lk, path, flags);
|
2008-04-18 03:32:26 +04:00
|
|
|
if (fd < 0) {
|
2008-10-18 02:44:39 +04:00
|
|
|
if (flags & LOCK_DIE_ON_ERROR)
|
2014-10-01 14:28:05 +04:00
|
|
|
unable_to_lock_die(path, errno);
|
2008-04-18 03:32:26 +04:00
|
|
|
return fd;
|
|
|
|
}
|
|
|
|
|
|
|
|
orig_fd = open(path, O_RDONLY);
|
|
|
|
if (orig_fd < 0) {
|
|
|
|
if (errno != ENOENT) {
|
2008-10-18 02:44:39 +04:00
|
|
|
if (flags & LOCK_DIE_ON_ERROR)
|
2008-04-18 03:32:26 +04:00
|
|
|
die("cannot open '%s' for copying", path);
|
2014-10-01 14:28:12 +04:00
|
|
|
rollback_lock_file(lk);
|
2008-04-18 03:32:26 +04:00
|
|
|
return error("cannot open '%s' for copying", path);
|
|
|
|
}
|
|
|
|
} else if (copy_fd(orig_fd, fd)) {
|
2008-10-18 02:44:39 +04:00
|
|
|
if (flags & LOCK_DIE_ON_ERROR)
|
2008-04-18 03:32:26 +04:00
|
|
|
exit(128);
|
2014-10-01 14:28:12 +04:00
|
|
|
rollback_lock_file(lk);
|
2008-04-18 03:32:26 +04:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
return fd;
|
|
|
|
}
|
|
|
|
|
2008-01-16 22:05:32 +03:00
|
|
|
int close_lock_file(struct lock_file *lk)
|
|
|
|
{
|
|
|
|
int fd = lk->fd;
|
2014-10-01 14:28:07 +04:00
|
|
|
|
|
|
|
if (fd < 0)
|
|
|
|
return 0;
|
|
|
|
|
2008-01-16 22:05:32 +03:00
|
|
|
lk->fd = -1;
|
2014-10-01 14:28:22 +04:00
|
|
|
if (close(fd)) {
|
|
|
|
int save_errno = errno;
|
|
|
|
rollback_lock_file(lk);
|
|
|
|
errno = save_errno;
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
return 0;
|
2008-01-16 22:05:32 +03:00
|
|
|
}
|
|
|
|
|
2014-07-14 21:29:58 +04:00
|
|
|
int reopen_lock_file(struct lock_file *lk)
|
|
|
|
{
|
|
|
|
if (0 <= lk->fd)
|
|
|
|
die(_("BUG: reopen a lockfile that is still open"));
|
lockfile: avoid transitory invalid states
Because remove_lock_file() can be called any time by the signal
handler, it is important that any lock_file objects that are in the
lock_file_list are always in a valid state. And since lock_file
objects are often reused (but are never removed from lock_file_list),
that means we have to be careful whenever mutating a lock_file object
to always keep it in a well-defined state.
This was formerly not the case, because part of the state was encoded
by setting lk->filename to the empty string vs. a valid filename. It
is wrong to assume that this string can be updated atomically; for
example, even
strcpy(lk->filename, value)
is unsafe. But the old code was even more reckless; for example,
strcpy(lk->filename, path);
if (!(flags & LOCK_NODEREF))
resolve_symlink(lk->filename, max_path_len);
strcat(lk->filename, ".lock");
During the call to resolve_symlink(), lk->filename contained the name
of the file that was being locked, not the name of the lockfile. If a
signal were raised during that interval, then the signal handler would
have deleted the valuable file!
We could probably continue to use the filename field to encode the
state by being careful to write characters 1..N-1 of the filename
first, and then overwrite the NUL at filename[0] with the first
character of the filename, but that would be awkward and error-prone.
So, instead of using the filename field to determine whether the
lock_file object is active, add a new field "lock_file::active" for
this purpose. Be careful to set this field only when filename really
contains the name of a file that should be deleted on cleanup.
Helped-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-10-01 14:28:27 +04:00
|
|
|
if (!lk->active)
|
2014-07-14 21:29:58 +04:00
|
|
|
die(_("BUG: reopen a lockfile that has been committed"));
|
|
|
|
lk->fd = open(lk->filename, O_WRONLY);
|
|
|
|
return lk->fd;
|
|
|
|
}
|
|
|
|
|
2006-06-06 23:51:49 +04:00
|
|
|
int commit_lock_file(struct lock_file *lk)
|
|
|
|
{
|
|
|
|
char result_file[PATH_MAX];
|
2014-10-01 14:28:20 +04:00
|
|
|
|
lockfile: avoid transitory invalid states
Because remove_lock_file() can be called any time by the signal
handler, it is important that any lock_file objects that are in the
lock_file_list are always in a valid state. And since lock_file
objects are often reused (but are never removed from lock_file_list),
that means we have to be careful whenever mutating a lock_file object
to always keep it in a well-defined state.
This was formerly not the case, because part of the state was encoded
by setting lk->filename to the empty string vs. a valid filename. It
is wrong to assume that this string can be updated atomically; for
example, even
strcpy(lk->filename, value)
is unsafe. But the old code was even more reckless; for example,
strcpy(lk->filename, path);
if (!(flags & LOCK_NODEREF))
resolve_symlink(lk->filename, max_path_len);
strcat(lk->filename, ".lock");
During the call to resolve_symlink(), lk->filename contained the name
of the file that was being locked, not the name of the lockfile. If a
signal were raised during that interval, then the signal handler would
have deleted the valuable file!
We could probably continue to use the filename field to encode the
state by being careful to write characters 1..N-1 of the filename
first, and then overwrite the NUL at filename[0] with the first
character of the filename, but that would be awkward and error-prone.
So, instead of using the filename field to determine whether the
lock_file object is active, add a new field "lock_file::active" for
this purpose. Be careful to set this field only when filename really
contains the name of a file that should be deleted on cleanup.
Helped-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-10-01 14:28:27 +04:00
|
|
|
if (!lk->active)
|
2014-10-01 14:28:21 +04:00
|
|
|
die("BUG: attempt to commit unlocked object");
|
|
|
|
|
2014-10-01 14:28:07 +04:00
|
|
|
if (close_lock_file(lk))
|
2008-01-16 22:05:32 +03:00
|
|
|
return -1;
|
2014-10-01 14:28:20 +04:00
|
|
|
|
2006-06-06 23:51:49 +04:00
|
|
|
strcpy(result_file, lk->filename);
|
2014-10-01 14:28:20 +04:00
|
|
|
/* remove ".lock": */
|
|
|
|
result_file[strlen(result_file) - LOCK_SUFFIX_LEN] = 0;
|
|
|
|
|
2014-10-01 14:28:23 +04:00
|
|
|
if (rename(lk->filename, result_file)) {
|
|
|
|
int save_errno = errno;
|
|
|
|
rollback_lock_file(lk);
|
|
|
|
errno = save_errno;
|
2008-01-16 22:05:32 +03:00
|
|
|
return -1;
|
2014-10-01 14:28:23 +04:00
|
|
|
}
|
|
|
|
|
lockfile: avoid transitory invalid states
Because remove_lock_file() can be called any time by the signal
handler, it is important that any lock_file objects that are in the
lock_file_list are always in a valid state. And since lock_file
objects are often reused (but are never removed from lock_file_list),
that means we have to be careful whenever mutating a lock_file object
to always keep it in a well-defined state.
This was formerly not the case, because part of the state was encoded
by setting lk->filename to the empty string vs. a valid filename. It
is wrong to assume that this string can be updated atomically; for
example, even
strcpy(lk->filename, value)
is unsafe. But the old code was even more reckless; for example,
strcpy(lk->filename, path);
if (!(flags & LOCK_NODEREF))
resolve_symlink(lk->filename, max_path_len);
strcat(lk->filename, ".lock");
During the call to resolve_symlink(), lk->filename contained the name
of the file that was being locked, not the name of the lockfile. If a
signal were raised during that interval, then the signal handler would
have deleted the valuable file!
We could probably continue to use the filename field to encode the
state by being careful to write characters 1..N-1 of the filename
first, and then overwrite the NUL at filename[0] with the first
character of the filename, but that would be awkward and error-prone.
So, instead of using the filename field to determine whether the
lock_file object is active, add a new field "lock_file::active" for
this purpose. Be careful to set this field only when filename really
contains the name of a file that should be deleted on cleanup.
Helped-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-10-01 14:28:27 +04:00
|
|
|
lk->active = 0;
|
2006-06-06 23:51:49 +04:00
|
|
|
lk->filename[0] = 0;
|
2008-01-16 22:05:32 +03:00
|
|
|
return 0;
|
2006-06-06 23:51:49 +04:00
|
|
|
}
|
|
|
|
|
_GIT_INDEX_OUTPUT: allow plumbing to output to an alternative index file.
When defined, this allows plumbing commands that update the
index (add, apply, checkout-index, merge-recursive, mv,
read-tree, rm, update-index, and write-tree) to write their
resulting index to an alternative index file while holding a
lock to the original index file. With this, git-commit that
jumps the index does not have to make an extra copy of the index
file, and more importantly, it can do the update while holding
the lock on the index.
However, I think the interface to let an environment variable
specify the output is a mistake, as shown in the documentation.
If a curious user has the environment variable set to something
other than the file GIT_INDEX_FILE points at, almost everything
will break. This should instead be a command line parameter to
tell these plumbing commands to write the result in the named
file, to prevent stupid mistakes.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-01 10:09:02 +04:00
|
|
|
int hold_locked_index(struct lock_file *lk, int die_on_error)
|
|
|
|
{
|
2008-10-18 02:44:39 +04:00
|
|
|
return hold_lock_file_for_update(lk, get_index_file(),
|
|
|
|
die_on_error
|
|
|
|
? LOCK_DIE_ON_ERROR
|
|
|
|
: 0);
|
_GIT_INDEX_OUTPUT: allow plumbing to output to an alternative index file.
When defined, this allows plumbing commands that update the
index (add, apply, checkout-index, merge-recursive, mv,
read-tree, rm, update-index, and write-tree) to write their
resulting index to an alternative index file while holding a
lock to the original index file. With this, git-commit that
jumps the index does not have to make an extra copy of the index
file, and more importantly, it can do the update while holding
the lock on the index.
However, I think the interface to let an environment variable
specify the output is a mistake, as shown in the documentation.
If a curious user has the environment variable set to something
other than the file GIT_INDEX_FILE points at, almost everything
will break. This should instead be a command line parameter to
tell these plumbing commands to write the result in the named
file, to prevent stupid mistakes.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-01 10:09:02 +04:00
|
|
|
}
|
|
|
|
|
2006-06-06 23:51:49 +04:00
|
|
|
void rollback_lock_file(struct lock_file *lk)
|
|
|
|
{
|
lockfile: avoid transitory invalid states
Because remove_lock_file() can be called any time by the signal
handler, it is important that any lock_file objects that are in the
lock_file_list are always in a valid state. And since lock_file
objects are often reused (but are never removed from lock_file_list),
that means we have to be careful whenever mutating a lock_file object
to always keep it in a well-defined state.
This was formerly not the case, because part of the state was encoded
by setting lk->filename to the empty string vs. a valid filename. It
is wrong to assume that this string can be updated atomically; for
example, even
strcpy(lk->filename, value)
is unsafe. But the old code was even more reckless; for example,
strcpy(lk->filename, path);
if (!(flags & LOCK_NODEREF))
resolve_symlink(lk->filename, max_path_len);
strcat(lk->filename, ".lock");
During the call to resolve_symlink(), lk->filename contained the name
of the file that was being locked, not the name of the lockfile. If a
signal were raised during that interval, then the signal handler would
have deleted the valuable file!
We could probably continue to use the filename field to encode the
state by being careful to write characters 1..N-1 of the filename
first, and then overwrite the NUL at filename[0] with the first
character of the filename, but that would be awkward and error-prone.
So, instead of using the filename field to determine whether the
lock_file object is active, add a new field "lock_file::active" for
this purpose. Be careful to set this field only when filename really
contains the name of a file that should be deleted on cleanup.
Helped-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-10-01 14:28:27 +04:00
|
|
|
if (!lk->active)
|
2014-10-01 14:28:09 +04:00
|
|
|
return;
|
|
|
|
|
2014-10-01 14:28:22 +04:00
|
|
|
if (!close_lock_file(lk)) {
|
|
|
|
unlink_or_warn(lk->filename);
|
lockfile: avoid transitory invalid states
Because remove_lock_file() can be called any time by the signal
handler, it is important that any lock_file objects that are in the
lock_file_list are always in a valid state. And since lock_file
objects are often reused (but are never removed from lock_file_list),
that means we have to be careful whenever mutating a lock_file object
to always keep it in a well-defined state.
This was formerly not the case, because part of the state was encoded
by setting lk->filename to the empty string vs. a valid filename. It
is wrong to assume that this string can be updated atomically; for
example, even
strcpy(lk->filename, value)
is unsafe. But the old code was even more reckless; for example,
strcpy(lk->filename, path);
if (!(flags & LOCK_NODEREF))
resolve_symlink(lk->filename, max_path_len);
strcat(lk->filename, ".lock");
During the call to resolve_symlink(), lk->filename contained the name
of the file that was being locked, not the name of the lockfile. If a
signal were raised during that interval, then the signal handler would
have deleted the valuable file!
We could probably continue to use the filename field to encode the
state by being careful to write characters 1..N-1 of the filename
first, and then overwrite the NUL at filename[0] with the first
character of the filename, but that would be awkward and error-prone.
So, instead of using the filename field to determine whether the
lock_file object is active, add a new field "lock_file::active" for
this purpose. Be careful to set this field only when filename really
contains the name of a file that should be deleted on cleanup.
Helped-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-10-01 14:28:27 +04:00
|
|
|
lk->active = 0;
|
2014-10-01 14:28:22 +04:00
|
|
|
lk->filename[0] = 0;
|
|
|
|
}
|
2006-06-06 23:51:49 +04:00
|
|
|
}
|