From: Junio C Hamano Date: Tue, 24 Apr 2007 05:16:43 GMT Subject: Re: [PATCH] Fix handle leak in write_tree Message-ID: <7vps5u9wsk.fsf@assigned-by-dhcp.cox.net> In-Reply-To: <20070423194925.GA5163@steel.home> Alex Riesen 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 > --- > > 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.