[PATCH] hash-object: fix descriptor leak with --literally

In hash_object(), we open a descriptor for each file to hash (whether we got the filename from the command line or --stdin-paths), but never close it. For the traditional code path which feeds the result to index_fd(), this is OK; it closes the descriptor for us.

But 5ba9a93b39 (hash-object: add --literally option, 2014-09-11) a second code path which does not close the descriptor. There we need to do so ourselves.

You can see the problem in a clone of git.git like this:

  $ git ls-files -s | grep ^100644 | cut -f2 |
    git hash-object --stdin-paths --literally >/dev/null
  fatal: could not open 'builtin/var.c' for reading: Too many open files

After this patch, it completes successfully. I didn't bother with a test, as it's a pain to deal with descriptor limits portably, and the fix is so trivial.

Signed-off-by: Jeff King <peff@peff.net>
---
Something I ran into while testing my hash-object fsck series, but I
broke it off here because it's really an independent bug-fix.

I do think the world would be less confusing if index_fd() didn't close the descriptor we pass it, and then hash_file() could just do:

  fd = open();
  hash_fd(fd);
  close(fd);

which is much more readable. But it has many other callers. So even if we wanted to untangle all that, I think it makes sense to do this obvious fix in the meantime.

 builtin/hash-object.c | 1 +
 1 file changed, 1 insertion(+)