[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #27213] consider_visiting: invalid assertion for FTS_NS due to acce

From: Martin von Gagern
Subject: [bug #27213] consider_visiting: invalid assertion for FTS_NS due to access permissions.
Date: Mon, 10 Aug 2009 10:08:35 +0000
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20090806 Gentoo Firefox/3.5.2


                 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



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
find: ftsfind.c:475: consider_visiting: Assertion `ent->fts_info == 11 ||
state.type != 0' failed.

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

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"
"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:


  Nachricht geschickt von/durch Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]