Re: git-commit fatal: Out of memory? mmap failed: Bad file descriptor

Junio C Hamano schrieb:

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.

The trouble is that on Windows open files cannot be deleted or renamed.
Hence, if an index file remains open, the hooks won't be able to modify
them (because of the create-new-file-then-rename-over-old tactics).

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.

Yes!

-- Hannes