summaryrefslogtreecommitdiff
path: root/lockfile.c
diff options
context:
space:
mode:
authorJunio C Hamano <gitster@pobox.com>2014-09-02 20:20:12 (GMT)
committerJunio C Hamano <gitster@pobox.com>2014-09-02 20:20:13 (GMT)
commitc518279c0efbee88c31bb9916572ddfd9ac8eb00 (patch)
treefebace945b65c5666af2404c1410242509eb2eb9 /lockfile.c
parent96db324a73fdada6fbe7b63221986f8f18cc63b0 (diff)
parent93dcaea22674864f931be3fe6050671d335dc5b0 (diff)
downloadgit-c518279c0efbee88c31bb9916572ddfd9ac8eb00.zip
git-c518279c0efbee88c31bb9916572ddfd9ac8eb00.tar.gz
git-c518279c0efbee88c31bb9916572ddfd9ac8eb00.tar.bz2
Merge branch 'jc/reopen-lock-file'
There are cases where you lock and open to write a file, close it to show the updated contents to external processes, and then have to update the file again while still holding the lock, but the lockfile API lacked support for such an access pattern. * jc/reopen-lock-file: lockfile: allow reopening a closed but still locked file
Diffstat (limited to 'lockfile.c')
-rw-r--r--lockfile.c10
1 files changed, 10 insertions, 0 deletions
diff --git a/lockfile.c b/lockfile.c
index 2564a7f..2a800ce 100644
--- a/lockfile.c
+++ b/lockfile.c
@@ -237,6 +237,16 @@ int close_lock_file(struct lock_file *lk)
return close(fd);
}
+int reopen_lock_file(struct lock_file *lk)
+{
+ if (0 <= lk->fd)
+ die(_("BUG: reopen a lockfile that is still open"));
+ if (!lk->filename[0])
+ die(_("BUG: reopen a lockfile that has been committed"));
+ lk->fd = open(lk->filename, O_WRONLY);
+ return lk->fd;
+}
+
int commit_lock_file(struct lock_file *lk)
{
char result_file[PATH_MAX];