Re: [PATCH] ls-files: do not trust stat info if lstat() fails
- From
Duy Nguyen <pclouds@gmail.com>
- Date
- Apr 5, 2014, 08:03 UTC
- Message-ID
- <CACsJy8CTv5jZKjqq6fAJeVj-sqJHAF761V6TofVWs-V5GPnbcA@mail.gmail.com>
- In-Reply-To
- <xmqqvbuqqstn.fsf@gitster.dls.corp.google.com>
On Thu, Apr 3, 2014 at 11:30 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 24 quoted lines
> Duy Nguyen <pclouds@gmail.com> writes: > >> On Thu, Apr 3, 2014 at 1:15 AM, Junio C Hamano <gitster@pobox.com> wrote: >>> I am guessing that, even though this was discovered during the >>> development of list-files, is a fix applicable outside the context >>> of that series. >>> >>> I do think the patched result is an improvement than the status quo, >>> but at the same time, I find it insufficient in the context of the >>> whole codepath. What if errno were other than ENOENT and we were >>> told to show_deleted (with or without show_modified)? We would end >>> up saying the path was deleted and modified at the same time, when >>> we do not know either is or is not true at all, because of the >>> failure to lstat() the path. >>> >>> Wouldn't it be saner to add tag_unknown and do something like this >>> instead, I wonder? >> >> Or even better to show an error message when the error code is >> unexpected? The unkown tag '!' says "there are problems" but if it >> shows up sort of permanently, '!' won't help much, I think. > > I am OK with that approach, but then one question remains: should we > say it is deleted, modified, both, or neither?
The question is moot if the user does not ignore stderr because they should just ignore those error-reported entries. If they do 2>/dev/null, I think we should err on the safe side and say modified. We only say deleted if lstat() returns ENOENT or ENOTDIR like in your patch.
-- Duy