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

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 7, 2014, 17:13 UTC
Message-ID: <xmqqzjjxm5ac.fsf@gitster.dls.corp.google.com>
In-Reply-To: <CACsJy8CTv5jZKjqq6fAJeVj-sqJHAF761V6TofVWs-V5GPnbcA@mail.gmail.com>

Duy Nguyen <pclouds@gmail.com> writes:

Show 12 quoted lines

>>> 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.

Doesn't the same reasoning behind "when we do not know for sure that a path is not modified, it would be safe if we said the path may be modified" also tell us that it is safer to say a path may be lost if we cannot tell?

One likely case where we cannot tell if it is modified would be when we cannot read the path (perhaps the parent directory accidentally lost its x-bit). Saying "it may be modified" would be one way to have the user take notice, for an interactive user. A script that runs ls-files may be using the paths to drive "git add", "tar cf -", etc. and emitting such an unreadable path is one way to make these downstream commands signal that something fishy is going on by erroring out.

So, I am not sure if we should be silent on an unexpected error when we are asked to report deletes when we would be vocal when we are asked to report modifications.