Follow-up Comment #5, bug #23920 (project findutils):
Oops. I was thinking that -path added an implicit leading and trailing *,
but that is not the case. Just like -name, the pattern does not match an
internal substring unless explicit globs are provided. So, revisiting the
examples:
$ find 2
On Sat, Sep 6, 2008 at 4:33 PM, Miloslav Trmač <[EMAIL PROTECTED]> wrote:
>
> It might make sense to automatically look for a database on every
> mounted file system (assuming a specific relative path). I don't know
> whether it should be the default.
It probably should not, I would guess. Most
Follow-up Comment #4, bug #23920 (project findutils):
I don't know how I missed it in 5.1. Sorry.
I agree with your first two examples.
But I can't imagine that it was intended for "-path ./src/emacs/" to match
./src/emacs/foo.c, any more than "-name austin" is intended to match
"austin-d5.1
Hello,
just a few comments based on my (unrealized) plans to implement
something similar for mlocate:
Peter Breitenlohner píše v Pá 05. 09. 2008 v 15:57 +0200:
> 2.1 The database format is not modified but slightly reinterpreted as
> follows: The current implementation cannot contain an empty file
Follow-up Comment #3, bug #23920 (project findutils):
Huh? -path was added for POSIX 200x; in draft 5.1, it is line 89102. At any
rate, based on line 89051 ("Each path operand shall be evaluated unaltered as
it was provided, including all trailing characters; all pathnames for
other files enco
Follow-up Comment #2, bug #23920 (project findutils):
My mistake. I just read IEEE P1003.1 Draft 5.1 (that is, the current draft
of the POSIX spec), and it does not include find -path.
Anyway, I think we can go further than you suggest; we can issue a warning
for -path ./src/emacs/ since it
Update of bug #23443 (project findutils):
Summary: find regression: now fooled when crossing
mountpoints => cycle detection in ftsfind yields false positives on some
filesystems with imperect POSIX compliance
___
Reply to
Follow-up Comment #13, bug #23443 (project findutils):
That sounds useful. In fact the non-POSIX-semantics detection could also be
useful, perhaps in a module form, for figuring out if we can trust st_nlink on
directories as well.We might need a bitmap for an answer (i.e. one bit per
POSIX-
Follow-up Comment #12, bug #23443 (project findutils):
I've realized there's a better way to do this. When the current code detects
a loop (looking solely at dev/ino), call fstatvfs to determine the type of the
current file system, and if it's of a type that may exhibit non-POSIX
semantics, perfo
Follow-up Comment #11, bug #23443 (project findutils):
If we save additional information from stuct stat as potentially
disambiguating information, we run the risk of (more) false negatives. For
example while we are searching /a/b/c/d something could concurrently modify
/a/b, changing its mtime
10 matches
Mail list logo
