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

Duy Nguyen [off-list ref] writes:

quoted

quoted

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.