From: Jeff King Date: Thu, 19 Jan 2023 01:57:56 +0000 (-0500) Subject: hash-object: fix descriptor leak with --literally X-Git-Tag: v2.40.0-rc0~50^2 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=590b63673747597ab458cb4414e68bb7c4a66aea;p=thirdparty%2Fgit.git 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) added 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 Signed-off-by: Junio C Hamano --- diff --git a/builtin/hash-object.c b/builtin/hash-object.c index fbae878c2b..3d6bec60e1 100644 --- a/builtin/hash-object.c +++ b/builtin/hash-object.c @@ -27,6 +27,7 @@ static int hash_literally(struct object_id *oid, int fd, const char *type, unsig else ret = write_object_file_literally(buf.buf, buf.len, type, oid, flags); + close(fd); strbuf_release(&buf); return ret; }