Re: [PATCH] find: add option -fail_exec

On Wed, May 21, 2025 at 1:51 AM Bernhard Voelker wrote: > [snip] > Although I like in general the idea to have more control over > exit values in the caller, I have the suspicion that mapping to > EXIT_FAILURE may be too simple: > > How to distinguish that from other find(1) errors? > In your case

[bug #66965] Multiple -files0-from args overwrite each other

4.10.0 Fixed Release: None ___ Follow-up Comments: --- Date: Sun 30 Mar 2025 02:45:33 PM UTC By: Tavian Barnes If you specify -files0-from twice, only the last one takes

[bug #45930] -ignore_readdir_race ineffective in find 4.5.11 and 4.5.14

Follow-up Comment #10, bug #45930 (group findutils): > gnulib/lib/ftc.c (FTC) Do you mean FTS? > This means that when find recurses into a subdirectory, it complains when > that subdirectory doesn't exist. Ah, you mean something like this: $ mkdir -p foo $ find -ignore_readdir_race -name .

[bug #66374] Permissions errors from unnecessary attemp to read symlink targets

Follow-up Comment #4, bug #66374 (group findutils): Looks like https://savannah.gnu.org/bugs/?51926#comment5 ___ Reply to this item at: ___ Message sent

[bug #66135] loop: different error messages describe an identical (?) error

Follow-up Comment #2, bug #66135 (group findutils): ln -s link link is a symbolic link loop. You can't dereference this link at all: $ ln -s link link $ stat -L link stat: cannot statx 'link': Too many levels of symbolic links $ cat link cat: link: Too many levels of symbolic links $ ls -L link

[bug #65895] Expression order matters?

Follow-up Comment #6, bug #65895 (group findutils): [comment #5 comment #5:] > Sorry I didn't make myself clear enough. I wasn't suggesting that "find . -delete" stop working. I was suggesting that it become an error for -delete to be followed by one or more pure predicate options (e.g. -name) but

[bug #65834] -mmin 1 and -mmin -1 are both true at once

: find Severity: 3 - Normal Item Group: Wrong result Status: None Privacy: Public Assigned to: None Originator Name: Tavian Barnes Originator Email: Open/Closed: Open Release: 4.9.0 Disc

[bug #65831] Test -type l is unsuccessful for symlink loops

Follow-up Comment #1, bug #65831 (group findutils): Hmm, I just found https://savannah.gnu.org/bugs/?19605#comment8 where Geoff Clare argues that ELOOP should in fact be an error, not just a broken link. ___ Reply to this item at:

[bug #51926] -xtype l fails on symbolic links that have a loop

Follow-up Comment #8, bug #51926 (group findutils): Commit b12fb8c ("Fix sv bug #51926: -xtype l fails on symlinks that have a loop") fixes this for -xtype, but what about $ ln -s loop loop $ find -L loop -type l ___ Reply to this item at

[bug #58941] wishlist: Support for -xattr -xattrname

Follow-up Comment #7, bug #58941 (group findutils): [comment #5 comment #5:] > bug #64088 specifically concerned the attributes append-only, immutable, nodump, fscrypt, verity, dax, projinherit Those are not technically extended attributes. getxattr(2) and friends don't return them. They are in

[bug #65609] [wishlist] give find a "secure" or "safe" option

Follow-up Comment #2, bug #65609 (group findutils): Also note that on some BSD find implementations [1], -s means "sort". It would be nice to not have a conflicting meaning for -s between implementations. [1]: https://man.freebsd.org/cgi/man.cgi?find(1)

Re: clarification regarding the evaluation of global options

n in the manual page should > clarify > that all global options are (probably) evaluated only once and before the > rest of > the expression. No, that's not correct. The behaviour is like $ find . \( -depth -a -name a.txt \) -o -name b.txt -depth is always true, but "true and something else" is the same as "something else" so it still has to check -name a.txt. -- Tavian Barnes

[bug #62621] xargs/find: buildcmd incorrectly sizes argv and envp

Follow-up Comment #1, bug #62621 (project findutils): Another thing: hypothetically, `xargs` could be built as a 32-bit binary, launching a 64-bit binary. In that case, `sizeof(void *)` is not enough, since `xargs` will think it's 4 while the kernel will think it's 8. __

[bug #62622] E2BIG misbehaviour

Follow-up Comment #1, bug #62622 (project findutils): I noticed this a while ago but forgot to report it: https://github.com/sharkdp/argmax/issues/1#issuecomment-972035652 `xargs` is trying to find the real limit with binary search: https://git.savannah.gnu.org/cgit/findutils.git/tree/lib/buildcm

[bug #62268] [feature request] -quit N to make find exit immediately with a certain exit code

Follow-up Comment #1, bug #62268 (project findutils): NetBSD find supports this as -exit [N] (https://man.netbsd.org/find.1) The difference with -quit is that -exit suppresses the default -print, which is often what you want if you're just checking the exit code. ___

Re: Report 2 UBSan bugs found by an automatic tool

; } pr = &p->pred_right; + assert(p->pred_left); pl = &p->pred_left->pred_right; if (!reason) $ make ... $ ./find/find nothing -delete find: tree.c:538: consider_arm_swap: Assertion `p->pred_left' failed. [2]94356 abort (core dumped) ./find/find nothing -delete -- Tavian Barnes

[bug #59766] printf %i doesn't show same result in all situations

Follow-up Comment #2, bug #59766 (project findutils): I've noticed this before too: https://savannah.gnu.org/bugs/?54913#comment5 The problem is, d_type and d_ino will be wrong for bind mounts. This is a known bug (even a POSIX violation for d_ino), but with little interest in fixing it from the

Re: [bug #58941] wishlist: Support for -xattr -xattrname

> * '-xattr' (without argument) to test if a file has extended attributes, > > * '-xattrname PATTERN' to check with a file has extended attributes > > matching > > the given PATTERN, and > > * '-xattrvalue PATTERN' to check if a file has an extended attribute > > with a value matching the given pattern. macOS provides -xattrname, but it's an exact match, not a pattern. Maybe -xattrvalue should be -xattrvalue NAME VALUE to allow you to match specific xattrs. -- Tavian Barnes

Re: find inodes of a dir

e POSIX version will specify that -mount should skip mount points entirely: http://austingroupbugs.net/view.php?id=1133. > But it is still doesn’t explain why the number is 15 — less than 23. > > May I ask for help to find all hard links to the directory within one > filesystems using `find`? > > > --- > Best Regards, > Andrei Enshin -- Tavian Barnes

[bug #58427] Cost-base optimiser breaks short-circuit evaluation

Follow-up Comment #1, bug #58427 (project findutils): I noticed something similar before too with -xtype, which was agreed to be a bug: https://savannah.gnu.org/bugs/?51926#comment5 ___ Reply to this item at:

Re: Is there another way to find a file that was created|modified|accessed before a certain time?

On Wed, 5 Feb 2020 at 15:00, Jeff Silverman wrote: > > I would like to get a list of all of the files modified between 2 dates. I > see that there is a -newermt DATE predicate, which works as documented and > which is half the problem. But I do not see an -oldermt DATE predicate. > In reading th

[bug #56855] find -printf %h gives an empty string for the root directory '/'

URL: Summary: find -printf %h gives an empty string for the root directory '/' Project: findutils Submitted by: tavianator Submitted on: Tue 03 Sep 2019 03:56:18 PM UTC Category: find

Re:

quot; does a post-order traversal that is still depth first, i.e. $ find . -depth ./a/b ./a ./c/d ./c . Breadth-first would look like $ bfs . . ./a ./c ./a/b ./c/d and can be accomplished with Dale R. Worley's -{min,max}depth loop (which makes it an iterative deepening search actually), or with tools other than find (like bfs above that I wrote). -- Tavian Barnes

[bug #54913] find: "-type"-test wrong on bind-mounted char device

Follow-up Comment #5, bug #54913 (project findutils): Linux has similar behaviour about d_ino, returning the inode number from the parent filesystem rather than the mount point itself. This is a POSIX violation, but there's little interest in fixing it: https://groups.google.com/forum/#!topic/lin

[bug #54913] find: "-type"-test wrong on bind-mounted char device

Follow-up Comment #2, bug #54913 (project findutils): So this issue basically happens because d_type comes from the parent filesystem right? Honestly this kernel behavior seems suboptimal to me. If it's too expensive to resolve d_type from the bind mount, it could at least return DT_UNKNOWN.

[bug #54263] find -L treats ENOENT and ENOTDIR differently

Follow-up Comment #2, bug #54263 (project findutils): > find -L . -type l prints a list of symbolic links reachable from the current directory that do not resolve to accessible files. Hmm. I never considered this before, but does the use of "accessible" here imply that EACCES should also count?

[bug #54667] find -type l fails to find symlink on NTFS volumes under linux

Follow-up Comment #3, bug #54667 (project findutils): I don't have ufsd to test with, but if I had to guess I'd say it's probably returning DT_REG in d_type for symlinks, but still returning S_IFLNK from stat() for them. Depending on whether stat() is called, you may get the right or the wrong ty

[bug #54667] find -type l fails to find symlink on NTFS volumes under linux

Follow-up Comment #1, bug #54667 (project findutils): What ntfs driver are you using? I couldn't reproduce this with ntfs-3g. ___ Reply to this item at: ___

Re: Introduce posix_spawn

n the case when there are file actions The glibc implementation uses clone() on Linux regardless of whether there are file actions, which should give performance closer to vfork() than fork(). https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/spawni.c -- Tavian Barnes

RE: Introduce posix_spawn

th the posix_spawn, and then the only > thing left to do is the integration. One thing you'll probably run into is that posix_spawn() has no interface for running the spawned process in a new working directory. That makes implementing -execdir/-okdir somewhat awkward. -- Tavian Barnes

[bug #54262] -printf %Y doesn't output N for broken links

Follow-up Comment #3, bug #54262 (project findutils): Better: $ ln -s nowhere broken $ ln -s find/find/find notdir $ find broken notdir -printf '%p %Y\n' broken l notdir l $ ./find/find broken notdir -printf '%p %Y\n' broken N notdir ?./find/find: ‘notdir’: Not a directory I think ENOTDIR should

[bug #46305] Doing "find -L . -type d -delete" fails on symlinks to directories.

Follow-up Comment #2, bug #46305 (project findutils): I think this is an actual bug, despite the general danger of running -delete together with -L. In this setup: $ mkdir foo $ mkdir bar $ ln -s ../foo bar/baz $ find -L bar -delete find: cannot delete ‘bar/baz’: Not a directory find: cannot del

[bug #54263] find -L treats ENOENT and ENOTDIR differently

URL: Summary: find -L treats ENOENT and ENOTDIR differently Project: findutils Submitted by: tavianator Submitted on: Sat 07 Jul 2018 07:39:49 PM UTC Category: find Sev

[bug #54262] -printf %Y doesn't output N for broken links

Follow-up Comment #1, bug #54262 (project findutils): The code in print.c is /* If we would normally follow links, do not do so. * If we would normally not follow links, do so. */ if ((following_links () ? optionp_stat : optionl_st

[bug #54262] -printf %Y doesn't output N for broken links

URL: Summary: -printf %Y doesn't output N for broken links Project: findutils Submitted by: tavianator Submitted on: Sat 07 Jul 2018 06:54:23 PM UTC Category: locate Se

[bug #54171] find -depth skips unreadable directories

URL: Summary: find -depth skips unreadable directories Project: findutils Submitted by: tavianator Submitted on: Sat 23 Jun 2018 10:34:28 PM UTC Category: find Severity

[bug #52220] 'find -D' segfaults

Follow-up Comment #4, bug #52220 (project findutils): Works for me, thanks! $ ./find/find -D ./find/find: Missing argument after the -D option. Try './find/find --help' for more information. ___ Reply to this item at:

[bug #52220] 'find -D' segfaults

Follow-up Comment #2, bug #52220 (project findutils): Reproduces here: Program received signal SIGSEGV, Segmentation fault. 0x7775c2d2 in strtok_r () from /usr/lib/libc.so.6 (gdb) bt #0 0x7775c2d2 in strtok_r () from /usr/lib/libc.so.6 #1 0x55561359 in process_debug_opt

[bug #51926] -xtype l fails on symbolic links that have a loop

Follow-up Comment #5, bug #51926 (project findutils): In fact the error can occur even when you wouldn't expect it due to find's arm-swapping optimizations: $ ln -s loop loop $ find -links 100 -xtype l find: ‘./loop’: Too many levels of symbolic links Even though -xtype appears guarded by the -l

[bug #51926] -xtype l fails on symbolic links that have a loop

Follow-up Comment #4, bug #51926 (project findutils): > It turns out that find treats "-xtype (anything)" as false on a broken link, which doesn't seem to be specified in the manual page. So it would be plausible to treat it as false on a circular link as well. Not really: $ ln -s nowhere broken

[bug #50859] fstype btrfs isn't supported

Follow-up Comment #2, bug #50859 (project findutils): Ah okay, you're actually parsing the device number out of /proc/self/mountinfo? When I implemented -fstype for bfs, I didn't bother getting it from there, as it's not returned by getmntent(). I just stat() the mount point itself, which obviou

[bug #50859] fstype btrfs isn't supported

URL: Summary: fstype btrfs isn't supported Project: findutils Submitted by: tavianator Submitted on: Sun 23 Apr 2017 02:44:50 PM UTC Category: find Severity: 3 - Normal

[bug #50259] -printf %h behaves weirdly with trailing slashes

Follow-up Comment #6, bug #50259 (project findutils): Great! Why limit it to a single trailing slash though? ___ Reply to this item at: ___ Message sen

[bug #50259] -printf %h behaves weirdly with trailing slashes

Follow-up Comment #2, bug #50259 (project findutils): > If the file's name contains no slashes (for example because it was named on the command line and is in the current working directory), then “%h” expands to “.”. This prevents “%h/%f” expanding to “/foo”, which would be surprising and probably

[bug #50259] -printf %h behaves weirdly with trailing slashes

: find Severity: 3 - Normal Item Group: Wrong result Status: None Privacy: Public Assigned to: None Originator Name: Tavian Barnes Originator Email: Open/Closed: Open Discussion Loc

[bug #48169] find makes unnecessary syscalls

Follow-up Comment #2, bug #48169 (project findutils): > Is there are measurable performance difference? Hard to say. find is now much better at avoiding stat() calls on non-directories, so it's overall faster. Anyway I tracked down where some of these are coming from. First off, the unused F_D