From: Alex Riesen <hidden> Date: 2016-06-15 22:43:06
This is a quick and dirty fix for the broken "git cherry-pick -n" on
some broken OS, which does not remove the directory entry after unlink
succeeded(!) if the file is still open somewher.
The entry is left but "protected": no open, no unlink, no stat.
Very annoying.
Signed-off-by: Alex Riesen <redacted>
---
That should be enough to get going, but I have to say that the
interface to lockfiles is really troublesome. Why has the caller close
a handle it didn't open? Especially if there are perfect matches for
the opening function (hold_locked_index) in form of commit and
rollback?
How about something like this (just interface):
struct lock_file
{
struct lock_file *next;
pid_t owner;
int fd;
char on_list;
char filename[PATH_MAX];
};
struct lock_file *open_locked(const char *path, int die_on_error);
struct lock_file *open_index_locked(int die_on_error);
void commit_lock_file(struct lock_file *); /* always assuming .lock */
void rollback_lock_file(struct lock_file *);
builtin-write-tree.c | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
@@ -29,6 +29,7 @@ int write_tree(unsigned char *sha1, int missing_ok, const char *prefix)was_valid=cache_tree_fully_valid(active_cache_tree);+close(newfd);if(!was_valid){if(cache_tree_update(active_cache_tree,active_cache,active_nr,
@@ -36,8 +37,10 @@ int write_tree(unsigned char *sha1, int missing_ok, const char *prefix)die("git-write-tree: error building trees");if(0<=newfd){if(!write_cache(newfd,active_cache,active_nr)-&&!close(newfd))+&&!close(newfd)){commit_lock_file(lock_file);+newfd=-1;+}}/* Not being able to write is fine -- we are only interested*inupdatingthecache-treepart,andifthenextcaller
@@ -55,6 +58,8 @@ int write_tree(unsigned char *sha1, int missing_ok, const char *prefix)elsehashcpy(sha1,active_cache_tree->sha1);+if(0<=newfd)+close(newfd);rollback_lock_file(lock_file);return0;
From: Junio C Hamano <hidden> Date: 2016-06-15 22:43:06
Alex Riesen [off-list ref] writes:
This is a quick and dirty fix for the broken "git cherry-pick -n" on
some broken OS, which does not remove the directory entry after unlink
succeeded(!) if the file is still open somewher.
The entry is left but "protected": no open, no unlink, no stat.
Very annoying.
Signed-off-by: Alex Riesen <redacted>
---
That should be enough to get going, but I have to say that the
interface to lockfiles is really troublesome. Why has the caller close
a handle it didn't open? Especially if there are perfect matches for
the opening function (hold_locked_index) in form of commit and
rollback?
How about something like this (just interface):
struct lock_file
{
struct lock_file *next;
pid_t owner;
int fd;
char on_list;
char filename[PATH_MAX];
};
struct lock_file *open_locked(const char *path, int die_on_error);
struct lock_file *open_index_locked(int die_on_error);
void commit_lock_file(struct lock_file *); /* always assuming .lock */
void rollback_lock_file(struct lock_file *);
I agree that making commit and rollback close the file
descriptor and lock holders to use lock->fd for write() makes
more sense, although it is a bit unclear from the above set of
function signatures what your plan on the lifetime rule for
"struct lock_file" is. If it will be linked to the list given
to the atexit() handler and the caller of open_locked() never
frees it, I think I am fine with the interface.
From: Alex Riesen <hidden> Date: 2016-06-15 22:43:06
On 4/24/07, Junio C Hamano [off-list ref] wrote:
quoted
How about something like this (just interface):
struct lock_file
{
struct lock_file *next;
pid_t owner;
int fd;
char on_list;
char filename[PATH_MAX];
};
struct lock_file *open_locked(const char *path, int die_on_error);
struct lock_file *open_index_locked(int die_on_error);
void commit_lock_file(struct lock_file *); /* always assuming .lock */
void rollback_lock_file(struct lock_file *);
I agree that making commit and rollback close the file
descriptor and lock holders to use lock->fd for write() makes
more sense, although it is a bit unclear from the above set of
function signatures what your plan on the lifetime rule for
"struct lock_file" is. If it will be linked to the list given
to the atexit() handler and the caller of open_locked() never
frees it, I think I am fine with the interface.
I actually expected the caller to define the lifetime. atexit is not exactly
libification-effort friendly. I could imagine open*locked with an additional
argument for atexit registration, I just don't like the idea (dislike
die_on_error
too). Isn't such kind of resource control _generally_ nicer to implement
in the top levels of a program?
From: Alex Riesen <hidden> Date: 2016-06-15 22:43:07
This is a quick and dirty fix for the broken "git cherry-pick -n" on
some broken OS, which does not remove the directory entry after unlink
succeeded(!) if the file is still open somewher.
The entry is left but "protected": no open, no unlink, no stat.
Very annoying.
Signed-off-by: Alex Riesen <redacted>
---
Alex Riesen, Mon, Apr 23, 2007 21:49:25 +0200:
@@ -29,6 +29,7 @@ int write_tree(unsigned char *sha1, int missing_ok, const char *prefix)was_valid=cache_tree_fully_valid(active_cache_tree);+close(newfd);if(!was_valid){if(cache_tree_update(active_cache_tree,active_cache,active_nr,
BTW, can someone explain this hunk? And how does it manage to
pass the tests?! And HOW did it manage to pass me?!!!
builtin-write-tree.c | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
@@ -36,8 +36,10 @@ int write_tree(unsigned char *sha1, int missing_ok, const char *prefix)die("git-write-tree: error building trees");if(0<=newfd){if(!write_cache(newfd,active_cache,active_nr)-&&!close(newfd))+&&!close(newfd)){commit_lock_file(lock_file);+newfd=-1;+}}/* Not being able to write is fine -- we are only interested*inupdatingthecache-treepart,andifthenextcaller
@@ -55,6 +57,8 @@ int write_tree(unsigned char *sha1, int missing_ok, const char *prefix)elsehashcpy(sha1,active_cache_tree->sha1);+if(0<=newfd)+close(newfd);rollback_lock_file(lock_file);return0;