On Wed, Aug 05, 2015 at 10:59:09AM +0200, Linus Torvalds wrote: > On Tue, Aug 4, 2015 at 11:03 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > > > > I would agree it is a good idea to clear it after seeing the first > > open fail due to lack of O_NOATIME before trying open for the second > > time, iow, more like this? Looks good to me. > So I don't think this is _wrong_ per se, but I think the deeper issue > is that somebody cares about 'errno' here in the first place. > > A stale 'errno' generally shouldn't matter, because we either > > (a) return success (and nobody should look at errno) > > or > > (b) return an error later, without setting errno for that _later_ error. > > and I think either of those two situations are the real bug, and this > "clear stale errno" is just a workaround. I agree. But I do not see how to get there easily. We are trying to read an object. We first try to read from a pack. We may encounter broken pack files, missing index files, unreadable files, but those errors are not necessarily fatal since we may still be able to read the object from the next pack file or from a sha1 file. If finally we do not find the object anywhere, in read_sha1_file_extended we try our best to die with an appropriate error message, for example by looking at errno, and otherwise we just return NULL. Most callers seem to die explicitly or they dereference the null pointer. I think we should instead output error messages closer to the source, like for example in map_sha1_file, but continue anyway. In particular we should immediately report failures due to EPERM or unexpected ENOENT. In the end we may return NULL without another message, but at least the user should have some hints about what went wrong along the way. -- 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