Re: [PATCH] ls-files: do not trust stat info if lstat() fails

[Duy Nguyen <pclouds@gmail.com>]

On Thu, Apr 3, 2014 at 11:30 PM, Junio C Hamano <gitster@pobox.com> wrote:
> 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