On Tue, 15 Jan 2008, Junio C Hamano wrote: >> Junio C Hamano <gitster@xxxxxxxxx> writes: >> >> While I think the ones that are immediately followed by >> commit_locked_index() can drop the close(fd) safely, I am not >> sure about Kristian's changes to the other ones that we >> currently close(fd) but do not commit nor rollback immediately. >> These indices are now shown to the hook with open fd to it if >> you choose not to close them. Is that okay for Windows guys? I >> somehow had an impression that the other process may have >> trouble accessing a file that is still open elsewhere for >> writing. >> >> So I think the approach along the lines of your "hack" to close >> and tell lockfile API not to double-close is more appropriate. >> We would perhaps want "close_lock_file(struct lock_file *)" that >> calls close(lk->fd) and does lk->fd = -1 without rename/unlink, >> and replace these close() with that. >> >> I am sick today, feeling feverish, and not thinking straight, >> so I may be talking total nonsense... > I'll aplly and push out Kristian's one that apparently got > Tested-by from Brandon for tonight. I've got a followup patch coming that will remove the rest of the redundant close()'s and I'll look into your suggestion for close_lock_file() above. Currently everything passes the test suite, I just need to do some manual testing. -brandon - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
