On Jan 11, 2008 7:36 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > In this case, a failure while closing that small .keep file is > highly unlikely, and if we ever mange to trigger such a highly > unlikely failure, I think we would rather want to *know* about > it, as it is likely there is something more seriously wrong > going on. On a slightly related note: I've got a patch that handles the issue that I reported a couple of months back that tmp pack/index objects where a write fails partway through are not deleted by any git processing, ie, when for example during git gc --prune we get fatal: sha1 file '/media/usbdiskc/v.git/objects/tmp_pack_QCYYAi' write error (No space left on device) error: failed to run repack but the tmp_pack_* isn't deleted. I put my patch on the back burner when Junio declared a moratorium on new behaviours until after 1.5.4 gets released, but will post once things open up again. As it relates to this discussion: one of the awkward things is that the die stuff doesn't leave any programatic indication (ie, not just a message to stderr) that a file is malformed due to a writing failure. Per Nicolas Pitre's suggestion to delete failed tmp_ files during a "git gc --prune", I just delete ALL tmp_ files at that time. This approach seems a bit risky -- can something like a git-svn fetch which generated tmp_ files by a different route be going on at the same time as a git gc? -- but I couldn't think of another way to do it. -- cheers, dave tweed__________________________ david.tweed@xxxxxxxxx Rm 124, School of Systems Engineering, University of Reading. "we had no idea that when we added templates we were adding a Turing- complete compile-time language." -- C++ standardisation committee - 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
