[bug #27213] consider_visiting: invalid assertion for FTS_NS due to access permissions.

[Martin von Gagern]

URL:
  <http://savannah.gnu.org/bugs/?27213>

                 Summary: consider_visiting: invalid assertion for FTS_NS due
to access permissions.
                 Project: findutils
            Submitted by: gagern
            Submitted on: Mo 10 Aug 2009 10:08:34 GMT
                Category: find
                Severity: 3 - Normal
              Item Group: Wrong result
                  Status: None
                 Privacy: Public
             Assigned to: None
         Originator Name: 
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
                 Release: 4.5.4
           Fixed Release: None

    _______________________________________________________

Details:

This bug is related to bug #25294 but doesn't match its description. It is
also covered by http://bugs.gentoo.org/253570 .

Steps to reproduce:
$ mkdir -p foo/bar
$ chmod a-x foo
$ find foo
foo
find: ftsfind.c:475: consider_visiting: Assertion `ent->fts_info == 11 ||
state.type != 0' failed.
Aborted

Could reproduce with current git master as well.
I assume the problem here lies with commit acb82fe4 and hasn't been fixed by
commit e3bcac43.

Looking at the former, I find that an assertion "state.have_type" had been
changed into "state.type != 0" which sounds like the exact opposite of the
original assumption. As all of this is in the case of either FTS_NS
(indicating a failed stat) or FTS_NSOK (indicating an omitted stat due to ), I
would assume that state.type == 0 should be expected at least in the FTS_NS
case.

So maybe you want to have these assertions instead:
assert (ent->fts_info != FTS_NS || state.type == 0);
assert (ent->fts_info != FTS_NSOK || state.type != 0);
These can be read as logical implications:
"Assert that if ent->fts_info == FTS_NS, then state.type == 0"
and
"Assert that if ent->fts_info == FTS_NSOK, then state.type != 0"

I'm none too sure about the FTS_NSOK case. In discussing this, it might make
sense to investigate both why these assertions should be expected to be true
from an abstract point of view as well as how they affect correct behaviour.

I'm also wondering whether some kind of error message for an un-stat-able
node would be better than silently using wrong file modes and perhaps even
pruning the tree, as the implementation with the above fixes would do instead.




    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?27213>

_______________________________________________
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/