{"thread":{"id":"2340","subject":"Empty temp files in the .git/objects subdirectories","startedAt":"2005-11-04T00:56:58Z","lastAt":"2005-11-04T02:32:54Z","messageCount":3,"participants":["walt","Nick Hengeveld","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"11104","messageId":"dkebkq$ova$1@sea.gmane.org","threadId":"2340","inReplyTo":null,"subject":"Empty temp files in the .git/objects subdirectories","fromName":"walt","fromEmail":"wa1ter@myrealbox.com","sentAt":"2005-11-04T00:56:58Z","receivedAt":"2005-11-04T00:56:58Z","isPatch":false,"sender":{"key":"wa1ter@myrealbox.com","avatar":null},"body":"I've noticed (sometimes) after using cg-update to\npull from Linus's kernel tree, that I have multiple\nempty files named *.temp in the various subdirectories\nof .git/objects/.\n\nThese *.temp files don't exist in Linus's repository\non kernel.org, so I am assuming they must be created\nlocally at my end by either cogito or git (dunno which).\n\nThey cause no problems except for annoying warning\nmessages, for example, while doing a git-fsck-*.\n\nI'm using git and cogito(HEAD), both updated by using\ncg-update from their git repositories on kernel.org,\nso I'm current up to the very last minute :o)\n\nAny suggestions how I can discover who is leaving\nbehind all these spurious empty *.temp files?\n"},{"id":"11106","messageId":"20051104015452.GB3001@reactrix.com","threadId":"2340","inReplyTo":"dkebkq$ova$1@sea.gmane.org","subject":"Re: Empty temp files in the .git/objects subdirectories","fromName":"Nick Hengeveld","fromEmail":"nickh@reactrix.com","sentAt":"2005-11-04T01:54:52Z","receivedAt":"2005-11-04T01:54:52Z","isPatch":false,"sender":{"key":"nickh@reactrix.com","avatar":null},"body":"On Thu, Nov 03, 2005 at 04:56:58PM -0800, walt wrote:\n\n> I've noticed (sometimes) after using cg-update to\n> pull from Linus's kernel tree, that I have multiple\n> empty files named *.temp in the various subdirectories\n> of .git/objects/.\n\nThese are created by git-http-fetch to hold data as it's being\nfetch from the remote repository.  They are left behind after a transfer\nerror so that the next time git-http-fetch runs it can pick up where it\nleft off.  If they're empty though, it would make more sense to delete\nthem rather than leaving them behind for the next attempt.\n\nThis should fix it:\n\n[PATCH] Remove the temp file if it is empty after the request has failed\n\nSigned-off-by: Nick Hengeveld <nickh@reactrix.com>\n\n\n---\n\n http-fetch.c |    5 +++++\n 1 files changed, 5 insertions(+), 0 deletions(-)\n\napplies-to: 55caf3fd962e3b5a25ee12e09c781e6f5a240672\n28738a32636e9f0a326f5d9e662df1e6c594851f\ndiff --git a/http-fetch.c b/http-fetch.c\nindex a1b03cd..b12779d 100644\n--- a/http-fetch.c\n+++ b/http-fetch.c\n@@ -520,12 +520,17 @@ static void start_request(struct transfe\n \n static void finish_request(struct transfer_request *request)\n {\n+\tstruct stat st;\n+\n \tfchmod(request->local, 0444);\n \tclose(request->local);\n \n \tif (request->http_code == 416) {\n \t\tfprintf(stderr, \"Warning: requested range invalid; we may already have all the data.\\n\");\n \t} else if (request->curl_result != CURLE_OK) {\n+\t\tif (stat(request->tmpfile, &st) == 0)\n+\t\t\tif (st.st_size == 0)\n+\t\t\t\tunlink(request->tmpfile);\n \t\treturn;\n \t}\n \n---\n0.99.9.GIT\n"},{"id":"11107","messageId":"7vvez95ei1.fsf@assigned-by-dhcp.cox.net","threadId":"2340","inReplyTo":"20051104015452.GB3001@reactrix.com","subject":"Re: Empty temp files in the .git/objects subdirectories","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-11-04T02:32:54Z","receivedAt":"2005-11-04T02:32:54Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nick Hengeveld <nickh@reactrix.com> writes:\n\n> These are created by git-http-fetch to hold data as it's being\n> fetch from the remote repository.  They are left behind after a transfer\n> error so that the next time git-http-fetch runs it can pick up where it\n> left off.  If they're empty though, it would make more sense to delete\n> them rather than leaving them behind for the next attempt.\n\nThat makes sense.  Thanks.\n"}]}