- 06 6月, 2015 2 次提交
-
-
由 Johannes Sixt 提交于
When the goal is to wait for some random amount of time up to one second, it is not necessary to compute with microsecond precision. This is a preparation to re-use sleep_millisec(). Signed-off-by: NJohannes Sixt <j6t@kdbg.org> Reviewed-by: NMichael Haggerty <mhagger@alum.mit.edu> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Johannes Sixt 提交于
On Windows, we do not have functions srandom() and random(). Use srand() and rand(). These functions produce random numbers of lesser quality, but for the purpose (a retry time-out) they are still good enough. Signed-off-by: NJohannes Sixt <j6t@kdbg.org> Reviewed-by: NMichael Haggerty <mhagger@alum.mit.edu> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 15 5月, 2015 1 次提交
-
-
由 Michael Haggerty 提交于
Currently, there is only one attempt to lock a file. If it fails, the whole operation fails. But it might sometimes be advantageous to try acquiring a file lock a few times before giving up. So add a new function, hold_lock_file_for_update_timeout(), that allows a timeout to be specified. Make hold_lock_file_for_update() a thin wrapper around the new function. If timeout_ms is positive, then retry for at least that many milliseconds to acquire the lock. On each failed attempt, use select() to wait for a backoff time that increases quadratically (capped at 1 second) and has a random component to prevent two processes from getting synchronized. If timeout_ms is negative, retry indefinitely. In a moment we will switch to using the new function when locking packed-refs. Signed-off-by: NMichael Haggerty <mhagger@alum.mit.edu> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 04 11月, 2014 1 次提交
-
-
由 Nguyễn Thái Ngọc Duy 提交于
Locked paths can be saved in a linked list so that if something wrong happens, *.lock are removed. For relative paths, this works fine if we keep cwd the same, which is true 99% of time except: - update-index and read-tree hold the lock on $GIT_DIR/index really early, then later on may call setup_work_tree() to move cwd. - Suppose a lock is being held (e.g. by "git add") then somewhere down the line, somebody calls real_path (e.g. "link_alt_odb_entry"), which temporarily moves cwd away and back. During that time when cwd is moved (either permanently or temporarily) and we decide to die(), attempts to remove relative *.lock will fail, and the next operation will complain that some files are still locked. Avoid this case by turning relative paths to absolute before storing the path in "filename" field. Reported-by: NYue Lin Ho <yuelinho777@gmail.com> Helped-by: NRamsay Jones <ramsay@ramsay1.demon.co.uk> Helped-by: NJohannes Sixt <j6t@kdbg.org> Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Adapted-by: NMichael Haggerty <mhagger@alum.mit.edu> Signed-off-by: NMichael Haggerty <mhagger@alum.mit.edu> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 16 10月, 2014 1 次提交
-
-
由 Jonathan Nieder 提交于
The former caller uses unable_to_lock_message now. Signed-off-by: NJonathan Nieder <jrnieder@gmail.com> Reviewed-by: NRonnie Sahlberg <sahlberg@google.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 02 10月, 2014 31 次提交
-
-
由 Michael Haggerty 提交于
Add a new function, fdopen_lock_file(), which returns a FILE pointer open to the lockfile. If a stream is open on a lock_file object, it is closed using fclose() on commit, rollback, or close_lock_file(). This change will allow callers to use stdio to write to a lockfile without having to muck around in the internal representation of the lock_file object (callers will be rewritten in upcoming commits). Signed-off-by: NMichael Haggerty <mhagger@alum.mit.edu> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Michael Haggerty 提交于
Move the interface declaration for the functions in lockfile.c from cache.h to a new file, lockfile.h. Add #includes where necessary (and remove some redundant includes of cache.h by files that already include builtin.h). Move the documentation of the lock_file state diagram from lockfile.c to the new header file. Signed-off-by: NMichael Haggerty <mhagger@alum.mit.edu> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Michael Haggerty 提交于
lockfile.c contains the general API for locking any file. Code specifically about the index file doesn't belong here. Signed-off-by: NMichael Haggerty <mhagger@alum.mit.edu> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Michael Haggerty 提交于
Callers who don't pass LOCK_DIE_ON_ERROR might want to examine errno to see what went wrong, so restore errno before returning. In fact this function only has one caller, add_to_alternates_file(), and it *does* use LOCK_DIE_ON_ERROR, but, you know, think of future generations. Signed-off-by: NMichael Haggerty <mhagger@alum.mit.edu> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Michael Haggerty 提交于
Add a function to return the path of the file that is locked by a lock_file object. This reduces the knowledge that callers have to have about the lock_file layout. Suggested-by: NRonnie Sahlberg <sahlberg@google.com> Signed-off-by: NMichael Haggerty <mhagger@alum.mit.edu> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Michael Haggerty 提交于
* remove_lock_file() -> remove_lock_files() * remove_lock_file_on_signal() -> remove_lock_files_on_signal() Suggested-by: NTorsten Bögershausen <tboegi@web.de> Signed-off-by: NMichael Haggerty <mhagger@alum.mit.edu> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Michael Haggerty 提交于
This makes it harder to misread the name as LOCK_NODE_REF. Suggested-by: NTorsten Bögershausen <tboegi@web.de> Signed-off-by: NMichael Haggerty <mhagger@alum.mit.edu> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Michael Haggerty 提交于
commit_locked_index(), when writing to an alternate index file, duplicates (poorly) the code in commit_lock_file(). And anyway, it shouldn't have to know so much about the internal workings of lockfile objects. So extract a new function commit_lock_file_to() that does the work common to the two functions, and call it from both commit_lock_file() and commit_locked_index(). Signed-off-by: NMichael Haggerty <mhagger@alum.mit.edu> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Michael Haggerty 提交于
Rewrite last_path_elm() to take a strbuf parameter and to trim off the last path name element in place rather than returning a pointer to the beginning of the last path name element. This simplifies the function a bit and makes it integrate better with its caller, which is now also strbuf-based. Rename the function accordingly and a bit less tersely. Signed-off-by: NMichael Haggerty <mhagger@alum.mit.edu> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Michael Haggerty 提交于
Change resolve_symlink() to take a strbuf rather than a string as parameter. This simplifies the code and removes an arbitrary pathname length restriction. It also means that lock_file's filename field no longer needs to be initialized to a large size. Helped-by: NTorsten Bögershausen <tboegi@web.de> Signed-off-by: NMichael Haggerty <mhagger@alum.mit.edu> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Michael Haggerty 提交于
Aside from shortening and simplifying the code, this removes another place where the path name length is arbitrarily limited. Signed-off-by: NMichael Haggerty <mhagger@alum.mit.edu> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Michael Haggerty 提交于
For now, we still make sure to allocate at least PATH_MAX characters for the strbuf because resolve_symlink() doesn't know how to expand the space for its return value. (That will be fixed in a moment.) Another alternative would be to just use a strbuf as scratch space in lock_file() but then store a pointer to the naked string in struct lock_file. But lock_file objects are often reused. By reusing the same strbuf, we can avoid having to reallocate the string most times when a lock_file object is reused. Helped-by: NTorsten Bögershausen <tboegi@web.de> Signed-off-by: NMichael Haggerty <mhagger@alum.mit.edu> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Michael Haggerty 提交于
Avoid relying on the filename length restrictions that are currently checked by lock_file(). Signed-off-by: NMichael Haggerty <mhagger@alum.mit.edu> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Michael Haggerty 提交于
The function remove_lock_file_on_signal() is used as a signal handler. It is not realistic to make the signal handler conform strictly to the C standard, which is very restrictive about what a signal handler is allowed to do. But let's increase the likelihood that it will work: The lock_file_list global variable and several fields from struct lock_file are used by the signal handler. Declare those values "volatile" to (1) force the main process to write the values to RAM promptly, and (2) prevent updates to these fields from being reordered in a way that leaves an opportunity for a jump to the signal handler while the object is in an inconsistent state. We don't mark the filename field volatile because that would prevent the use of strcpy(), and it is anyway unlikely that a compiler re-orders a strcpy() call across other expressions. So in practice it should be possible to get away without "volatile" in the "filename" case. Suggested-by: NJohannes Sixt <j6t@kdbg.org> Signed-off-by: NMichael Haggerty <mhagger@alum.mit.edu> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Michael Haggerty 提交于
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: NJohannes Sixt <j6t@kdbg.org> Signed-off-by: NMichael Haggerty <mhagger@alum.mit.edu> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Michael Haggerty 提交于
If rename() fails, call rollback_lock_file() to delete the lock file (in case it is still present) and reset the filename field to the empty string so that the lockfile object is left in a valid state. Signed-off-by: NMichael Haggerty <mhagger@alum.mit.edu> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Michael Haggerty 提交于
If closing an open lockfile fails, then we cannot be sure of the contents of the lockfile, so there is nothing sensible to do but delete it. This change also insures that the lock_file object is left in a defined state in this error path (namely, unlocked). The only caller that is ultimately affected by this change is try_merge_strategy() -> write_locked_index(), which can call close_lock_file() via various execution paths. This caller uses a static lock_file object which previously could have been reused after a failed close_lock_file() even though it was still in locked state. This change causes the lock_file object to be unlocked on failure, thus fixing this error-handling path. Signed-off-by: NMichael Haggerty <mhagger@alum.mit.edu> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Michael Haggerty 提交于
It was previously a bug to call commit_lock_file() with a lock_file object that was not active (an illegal access would happen within the function). It was presumably never done, but this would be an easy programming error to overlook. So before continuing, do a consistency check that the lock_file object really is locked. Helped-by: NJohannes Sixt <j6t@kdbg.org> Signed-off-by: NMichael Haggerty <mhagger@alum.mit.edu> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Michael Haggerty 提交于
Signed-off-by: NMichael Haggerty <mhagger@alum.mit.edu> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Michael Haggerty 提交于
It does just what we need. Signed-off-by: NMichael Haggerty <mhagger@alum.mit.edu> Reviewed-by: NJonathan Nieder <jrnieder@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Michael Haggerty 提交于
This is a bit easier to read than the old version, which nested part of the non-error code in an "if" block. Signed-off-by: NMichael Haggerty <mhagger@alum.mit.edu> Reviewed-by: NRonnie Sahlberg <sahlberg@google.com> Reviewed-by: NJonathan Nieder <jrnieder@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Michael Haggerty 提交于
There are a few places that use these values, so define constants for them. Signed-off-by: NMichael Haggerty <mhagger@alum.mit.edu> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Michael Haggerty 提交于
Document the valid states of lock_file objects, how they get into each state, and how the state is encoded in the object's fields. Signed-off-by: NMichael Haggerty <mhagger@alum.mit.edu> Reviewed-by: NRonnie Sahlberg <sahlberg@google.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Michael Haggerty 提交于
The purpose of this change is to make the state diagram for lock_file objects simpler and deterministic. If locking fails, lock_file() sometimes leaves the lock_file object partly initialized, but sometimes not. It sometimes registers the object in lock_file_list, but sometimes not. This makes the state diagram for lock_file objects effectively indeterministic and hard to reason about. A future patch will also change the filename field into a strbuf, which needs more involved initialization, so it will become even more important that the state of a lock_file object is well-defined after a failed attempt to lock. The ambiguity doesn't currently have any ill effects, because lock_file objects cannot be removed from the lock_file_list anyway. But to make it easier to document and reason about the code, make this behavior consistent: *always* initialize the lock_file object and *always* register it in lock_file_list the first time it is used, regardless of whether an error occurs. While we're at it, make sure that all of the lock_file fields are initialized to values appropriate for an unlocked object; the caller is only responsible for making sure that on_list is set to zero before the first time it is used. Signed-off-by: NMichael Haggerty <mhagger@alum.mit.edu> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Michael Haggerty 提交于
If there is an error copying the old contents to the lockfile, roll back the lockfile before exiting so that the lockfile is not held until process cleanup. Signed-off-by: NMichael Haggerty <mhagger@alum.mit.edu> Reviewed-by: NJonathan Nieder <jrnieder@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Michael Haggerty 提交于
If the call to adjust_shared_perm() fails, lock_file returns -1, which to the caller looks like any other failure to lock the file. So in this case, roll back the lockfile before returning so that the lock file is deleted immediately and the lockfile object is left in a predictable state (namely, unlocked). Previously, the lockfile was retained until process cleanup in this situation. Signed-off-by: NMichael Haggerty <mhagger@alum.mit.edu> Reviewed-by: NJonathan Nieder <jrnieder@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Michael Haggerty 提交于
When rolling back the lockfile, call close_lock_file() so that the lock_file's fd field gets set back to -1. This keeps the lock_file object in a valid state, which is important because these objects are allowed to be reused. It also makes it unnecessary to check whether the file has already been closed, because close_lock_file() takes care of that. Signed-off-by: NMichael Haggerty <mhagger@alum.mit.edu> Reviewed-by: NJonathan Nieder <jrnieder@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Michael Haggerty 提交于
Eliminate a layer of nesting. Signed-off-by: NMichael Haggerty <mhagger@alum.mit.edu> Reviewed-by: NRonnie Sahlberg <sahlberg@google.com> Reviewed-by: NJonathan Nieder <jrnieder@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Michael Haggerty 提交于
It is only necessary to clear the lock_file's filename field if it was not already clear. Signed-off-by: NMichael Haggerty <mhagger@alum.mit.edu> Reviewed-by: NRonnie Sahlberg <sahlberg@google.com> Reviewed-by: NJonathan Nieder <jrnieder@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Michael Haggerty 提交于
Suggested-by: NJonathan Nieder <jrnieder@gmail.com> Signed-off-by: NMichael Haggerty <mhagger@alum.mit.edu> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Michael Haggerty 提交于
This function is used for other things besides the index, so rename it accordingly. Suggested-by: NJeff King <peff@peff.net> Signed-off-by: NMichael Haggerty <mhagger@alum.mit.edu> Reviewed-by: NRonnie Sahlberg <sahlberg@google.com> Reviewed-by: NJonathan Nieder <jrnieder@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 29 8月, 2014 1 次提交
-
-
由 Steffen Prohaska 提交于
The caller, not this function, opened the file descriptor; it is selfish for the callee to close it when it is done reading from it. The caller may want an option to rewind and re-read the contents after it returns. Simplify the loop to copy the input in full to the output; its body essentially is what a call to write_in_full() helper does. Signed-off-by: NSteffen Prohaska <prohaska@zib.de> Helped-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 15 7月, 2014 3 次提交
-
-
由 Junio C Hamano 提交于
In some code paths (e.g. giving "add -i" to prepare the contents to be committed interactively inside "commit -p") where a caller takes a lock, writes the new content, give chance for others to use it while still holding the lock, and then releases the lock when all is done. As an extension, allow the caller to re-update an already closed file while still holding the lock (i.e. not yet committed) by re-opening the file, to be followed by updating the contents and then by the usual close_lock_file() or commit_lock_file(). This is necessary if we want to add code to rebuild the cache-tree and write the resulting index out after "add -i" returns the control to "commit -p", for example. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Ronnie Sahlberg 提交于
Making errno when returning from lock_file() meaningful, which should fix * an existing almost-bug in lock_ref_sha1_basic where it assumes errno==ENOENT is meaningful and could waste some work on retries * an existing bug in repack_without_refs where it prints strerror(errno) and picks advice based on errno, despite errno potentially being zero and potentially having been clobbered by that point Signed-off-by: NRonnie Sahlberg <sahlberg@google.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com> Acked-by: NMichael Haggerty <mhagger@alum.mit.edu>
-
由 Ronnie Sahlberg 提交于
Introducing a new unable_to_lock_message helper, which has nicer semantics than unable_to_lock_error and cleans up lockfile.c a little. Signed-off-by: NRonnie Sahlberg <sahlberg@google.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com> Acked-by: NMichael Haggerty <mhagger@alum.mit.edu>
-