- 02 10月, 2014 7 次提交
-
-
由 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>
-
- 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>
-
- 14 6月, 2014 1 次提交
-
-
由 Nguyễn Thái Ngọc Duy 提交于
This function is now only used by write_locked_index(). Move it to read-cache.c (because read-cache.c will need to be aware of alternate_index_output later) and unexport it. Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 08 7月, 2013 1 次提交
-
-
由 Michael Haggerty 提交于
The path of the file to be locked is held in lock_file::filename, which is a fixed-length buffer of length PATH_MAX. This buffer is also (temporarily) used to hold the path of the lock file, which is the path of the file being locked plus ".lock". Because of this, the path of the file being locked must be less than (PATH_MAX - 5) characters long (5 chars are needed for ".lock" and one character for the NUL terminator). On entry into lock_file(), the path length was only verified to be less than PATH_MAX characters, not less than (PATH_MAX - 5) characters. When and if resolve_symlink() is called, then that function is correctly told to treat the buffer as (PATH_MAX - 5) characters long. This part is correct. However: * If LOCK_NODEREF was specified, then resolve_symlink() is never called. * If resolve_symlink() is called but the path is not a symlink, then the length check is never applied. So it is possible for a path with length (PATH_MAX - 5 <= len < PATH_MAX) to make it through the checks. When ".lock" is strcat()ted to such a path, the lock_file::filename buffer is overflowed. Fix the problem by adding a check when entering lock_file() that the original path is less than (PATH_MAX - 5) characters. [jc: with independent development by Peff] Signed-off-by: NMichael Haggerty <mhagger@alum.mit.edu> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 18 3月, 2011 1 次提交
-
-
由 Carlos Martín Nieto 提交于
Rename the make_*_path functions so it's clearer what they do, in particlar make clear what the differnce between make_absolute_path and make_nonrelative_path is by renaming them real_path and absolute_path respectively. make_relative_path has an understandable name and is renamed to relative_path to maintain the name convention. The function calls have been replaced 1-to-1 in their usage. Signed-off-by: NCarlos Martín Nieto <cmn@elego.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 13 1月, 2010 1 次提交
-
-
由 Matthieu Moy 提交于
When calling a git command from a subdirectory and a file locking fails, the user will get a path relative to the root of the worktree, which is invalid from the place where the command is ran. Make it easy for the user to know which file it is. Signed-off-by: NMatthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 29 9月, 2009 1 次提交
-
-
由 Miklos Vajna 提交于
Previously the old error message just told the user that it was not possible to delete the ref from the packed-refs file. Give instructions on how to resolve the problem. Signed-off-by: NMiklos Vajna <vmiklos@frugalware.org> Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 02 5月, 2009 1 次提交
-
-
由 Felipe Contreras 提交于
Essentially; s/type* /type */ as per the coding guidelines. Signed-off-by: NFelipe Contreras <felipe.contreras@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 30 4月, 2009 1 次提交
-
-
由 Alex Riesen 提交于
This helps to notice when something's going wrong, especially on systems which lock open files. I used the following criteria when selecting the code for replacement: - it was already printing a warning for the unlink failures - it is in a function which already printing something or is called from such a function - it is in a static function, returning void and the function is only called from a builtin main function (cmd_) - it is in a function which handles emergency exit (signal handlers) - it is in a function which is obvously cleaning up the lockfiles Signed-off-by: NAlex Riesen <raa.lkml@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 05 3月, 2009 1 次提交
-
-
由 John Tapsell 提交于
It looks like someone did 90% of the work, then forgot to actually use the function in one place. Also the helper function did not use the correct variable. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 20 2月, 2009 1 次提交
-
-
由 Matthieu Moy 提交于
Just saying that index.lock exists doesn't tell the user _what_ to do to fix the problem. We should give an indication that it's normally safe to delete index.lock after making sure git isn't running here. Signed-off-by: NMatthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 22 1月, 2009 2 次提交
-
-
由 Jeff King 提交于
The current code is very inconsistent about which signals are caught for doing cleanup of temporary files and lock files. Some callsites checked only SIGINT, while others checked a variety of death-dealing signals. This patch factors out those signals to a single function, and then calls it everywhere. For some sites, that means this is a simple clean up. For others, it is an improvement in that they will now properly clean themselves up after a larger variety of signals. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jeff King 提交于
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: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 21 12月, 2008 1 次提交
-
-
由 Junio C Hamano 提交于
We cleaned up lockfiles upon receiving the usual suspects HUP, TERM, QUIT but a wicked user could kill us of asphyxiation by piping our output to a pipe that does not read. Protect ourselves by catching SIGPIPE and clean up the lockfiles as well in such a case. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 20 10月, 2008 1 次提交
-
-
由 Junio C Hamano 提交于
This changes the "die_on_error" boolean parameter to a mere "flags", and changes the existing callers of hold_lock_file_for_update/append() functions to pass LOCK_DIE_ON_ERROR. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 01 6月, 2008 1 次提交
-
-
由 Paolo Bonzini 提交于
Other signals are also common, for example SIGTERM and SIGHUP. This patch modifies the lock file mechanism to catch more signals. It also modifies http-push.c which was missing SIGTERM. Signed-off-by: NPaolo Bonzini <bonzini@gnu.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 26 5月, 2008 1 次提交
-
-
由 Clemens Buchacher 提交于
This did not cause any problems, because remove_lock_file_on_signal is only registered for SIGINT. Signed-off-by: NClemens Buchacher <drizzd@aon.at> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 05 5月, 2008 1 次提交
-
-
由 Daniel Barkalow 提交于
This takes care of copying the original contents into the replacement file after the lock is held, so that concurrent additions can't miss each other's changes. [jc: munged to drop mmap in favor of copy_file.] Signed-off-by: NDaniel Barkalow <barkalow@iabervon.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 17 1月, 2008 1 次提交
-
-
由 Brandon Casey 提交于
The lockfile API is a handy way to obtain a file that is cleaned up if you die(). But sometimes you would need this sequence to work: 1. hold_lock_file_for_update() to get a file descriptor for writing; 2. write the contents out, without being able to decide if the results should be committed or rolled back; 3. do something else that makes the decision --- and this "something else" needs the lockfile not to have an open file descriptor for writing (e.g. Windows do not want a open file to be renamed); 4. call commit_lock_file() or rollback_lock_file() as appropriately. This adds close_lock_file() you can call between step 2 and 3 in the above sequence. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 27 11月, 2007 1 次提交
-
-
由 Steffen Prohaska 提交于
Using the helper function to test for absolute paths makes porting easier. Signed-off-by: NSteffen Prohaska <prohaska@zib.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 15 11月, 2007 1 次提交
-
-
由 Johannes Schindelin 提交于
This is needed on Windows since open files cannot be unlinked. Signed-off-by: NJohannes Sixt <johannes.sixt@telecom.at> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 27 7月, 2007 1 次提交
-
-
由 Bradford C. Smith 提交于
Make the code for resolving symlinks in lockfile.c more robust as follows: 1. Handle relative symlinks 2. recursively resolve symlink chains up to 5 [jc: removed lstat/stat calls to do things stupid way] Signed-off-by: NBradford C. Smith <bradford.carl.smith@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 26 7月, 2007 1 次提交
-
-
由 Junio C Hamano 提交于
In a working tree prepared in new-workdir (in contrib/), some files in .git/ directory are symbolic links to the original repository. The usual sequence of lock-write-rename would break the symbolic link. Ideally we should resolve relative symbolic link with maxdepth, but I do not want to risk too elaborate patch before 1.5.3 release, so this is a minimum and trivially obvious fix. new-workdir creates its symbolic links absolute, and does not link from a symlinked workdir, so this fix should suffice for now. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 13 7月, 2007 1 次提交
-
-
由 Sven Verdoolaege 提交于
Removing a lockfile once should be enough. Signed-off-by: NSven Verdoolaege <skimo@kotnet.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 07 6月, 2007 1 次提交
-
-
由 Junio C Hamano 提交于
This uses "git-apply --whitespace=strip" to fix whitespace errors that have crept in to our source files over time. There are a few files that need to have trailing whitespaces (most notably, test vectors). The results still passes the test, and build result in Documentation/ area is unchanged. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 22 4月, 2007 1 次提交
-
-
由 Junio C Hamano 提交于
The usual process flow is the main process opens and holds the lock to the index, does its thing, perhaps spawning children during the course, and then writes the resulting index out by releaseing the lock. However, the lockfile interface uses atexit(3) to clean it up, without regard to who actually created the lock. This typically leads to a confusing behaviour of lock being released too early when the child exits, and then the parent process when it calls commit_lockfile() finds that it cannot unlock it. This fixes the problem by recording who created and holds the lock, and upon atexit(3) handler, child simply ignores the lockfile the parent created. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 04 4月, 2007 2 次提交
-
-
由 Junio C Hamano 提交于
This corrects the interface mistake of the previous one, and gives a command line parameter to the only plumbing command that currently needs it: "git-read-tree". We can add the calls to set_alternate_index_output() to other plumbing commands that update the index if/when needed. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
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: NJunio C Hamano <junkio@cox.net>
-
- 07 1月, 2007 1 次提交
-
-
由 Steven Grimm 提交于
Signed-off-by: NSteven Grimm <koreth@midwinter.com> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 03 1月, 2007 1 次提交
-
-
由 Junio C Hamano 提交于
It was stupid to link the same element twice to lock_file_list and end up in a loop, so we certainly need a fix. But it is not like we are taking a lock on multiple files in this case. It is just that we leave the linked element on the list even after commit_lock_file() successfully removes the cruft. We cannot remove the list element in commit_lock_file(); if we are interrupted in the middle of list manipulation, the call to remove_lock_file_on_signal() will happen with a broken list structure pointed by lock_file_list, which would cause the cruft to remain, so not removing the list element is the right thing to do. Instead we should be reusing the element already on the list. There is already a code for that in lock_file() function in lockfile.c. The code checks lk->next and the element is linked only when it is not already on the list -- which is incorrect for the last element on the list (which has NULL in its next field), but if you read the check as "is this element already on the list?" it actually makes sense. We do not want to link it on the list again, nor we would want to set up signal/atexit over and over. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 21 12月, 2006 1 次提交
-
-
由 Junio C Hamano 提交于
This is a mechanical clean-up of the way *.c files include system header files. (1) sources under compat/, platform sha-1 implementations, and xdelta code are exempt from the following rules; (2) the first #include must be "git-compat-util.h" or one of our own header file that includes it first (e.g. config.h, builtin.h, pkt-line.h); (3) system headers that are included in "git-compat-util.h" need not be included in individual C source files. (4) "git-compat-util.h" does not have to include subsystem specific header files (e.g. expat.h). Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 13 8月, 2006 1 次提交
-
-
由 Junio C Hamano 提交于
Most of the callers except the one in refs.c use the function to update the index file. Among the index writers, everybody except write-tree dies if they cannot open it for writing. This gives the function an extra argument, to tell it to die when it cannot create a new file as the lockfile. The only caller that does not have to die is write-tree, because updating the index for the cache-tree part is optional and not being able to do so does not affect the correctness. I think we do not have to be so careful and make the failure into die() the same way as other callers, but that would be a different patch. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-