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

Release: 4.6.0 Discussion Lock: Any Fixed Release: None ___ Follow-up Comments: --- Date: Thu 18 Apr 2024 01:36:17 PM UTC By: Anonymous This is a "wishlis

[bug #65386] unknown predicate error when using '-1M' as lt 1

4.9.0 Discussion Lock: Any Fixed Release: None ___ Follow-up Comments: --- Date: Thu 29 Feb 2024 03:58:40 AM UTC By: Anonymous find . (-type f) -a (-size -1M) recup_dir.10

[bug #65378] B or b?

: None ___ Follow-up Comments: --- Date: Tue 27 Feb 2024 06:39:27 PM UTC By: Anonymous findutils doc for Test: -newerXY reference. ‘B’ Birth time of reference while in the text just followi

[bug #65349] Wrong statement in -xtype documentation

k: Any Fixed Release: None ___ Follow-up Comments: --- Date: Fri 23 Feb 2024 05:20:48 PM UTC By: Anonymous findutils 4.9.0 The docs [1] say that for a symbolic link `-L -xtype X` is

[bug #65337] Unexepected results from complete tests on -mtime/-mmin/-daystart

Follow-up Comment #2, bug#65337 (group findutils): Sorry error sign in the creation times, the correction is: * x0 modified at T0 - epsi0 => AGE = epsi0/P * x1 modified at T0 - P/2 - epsi1 => AGE = 1/2 + epsi1/P * x2 modified at T0 - P - epsi2 => AGE = 1 + epsi2/P * x3 modified at

[bug #65337] Unexepected results from complete tests on -mtime/-mmin/-daystart

Follow-up Comment #1, bug#65337 (group findutils): Sorry my email was cut during submission: r.duc...@gmail.com ___ Reply to this item at: ___ Message

[bug #65337] Unexepected results from complete tests on -mtime/-mmin/-daystart

: Open Release: 4.9.0 Discussion Lock: Any Fixed Release: None ___ Follow-up Comments: --- Date: Tue 20 Feb 2024 04:58:22 PM UTC By: Anonymous 1 the version of finduti

[bug #65305] @var{name} should be @var{NAME}

Fixed Release: None ___ Follow-up Comments: --- Date: Tue 13 Feb 2024 03:50:11 PM UTC By: Anonymous To conform with @deffn Test -samefile NAME in 872 all @var{name} should be @var{NAME} b

[bug #65297] -regexp incompatible statements concerning default

k: Any Fixed Release: None ___ Follow-up Comments: --- Date: Mon 12 Feb 2024 07:40:12 PM UTC By: Anonymous "There are several varieties of regular expressions; by defaul

[bug #65283] Misleading statement, I believe

Fixed Release: None ___ Follow-up Comments: --- Date: Fri 09 Feb 2024 08:12:46 PM UTC By: Anonymous "The differences are that the locate information might be out of date, and that loc

[bug #65282] Positional option -regextype not mentioned

k: Any Fixed Release: None ___ Follow-up Comments: --- Date: Fri 09 Feb 2024 08:06:27 PM UTC By: Anonymous Positional option -regextype not mentioned below: "Therefore,

[bug #64876] Minor typo in updatedb(1) man page

Fixed Release: None ___ Follow-up Comments: --- Date: Thu 09 Nov 2023 03:06:44 PM UTC By: Anonymous Line 31 in locate/updatedb.1 is ".B LOCATGE02" -- should

[bug #64741] Graceful stop of xargs

: None ___ Follow-up Comments: --- Date: Tue 03 Oct 2023 04:36:19 PM UTC By: Anonymous Hello. At this time there is no way to gracefully stop xargs. If I kill main process all current runnin

[bug #64717] find-4.9.0: aborted after assertion at line 3179 of parser.c

elease: 4.9.0 Discussion Lock: Any Fixed Release: None ___ Follow-up Comments: --- Date: Tue 26 Sep 2023 12:03:18 PM UTC By: Anonymous On find-4.9.0, "find -amin N

[bug #64605] Add support for extended attributes

: None Discussion Lock: Any Fixed Release: None ___ Follow-up Comments: --- Date: Mon 28 Aug 2023 04:49:02 PM UTC By: Anonymous XDG Extended Attributes guidelines include metadata about

[bug #64451] Unexpected behaviour of xargs when multiple children exit with 255 in parallel

Follow-up Comment #5, bug #64451 (project findutils): >From wait(2): *WIFSTOPPED(*_wstatus_*)* returns true if the child process was stopped by delivery of a signal; this is possible only if the call was done using *WUNTRACED* or when the child is being traced (see *ptrace*(2)). OK so I

[bug #64451] Unexpected behaviour of xargs when multiple children exit with 255 in parallel

Follow-up Comment #4, bug #64451 (project findutils): I still can't figure out how catching SIGSTOP is supposed to work. Neither SIGSTOP nor SIGTSTP seem to be caught. ___ Reply to this item at:

[bug #64451] Unexpected behaviour of xargs when multiple children exit with 255 in parallel

Follow-up Comment #3, bug #64451 (project findutils): I've been able to fix this behaviour by explicitly calling _wait_for_proc_all_(). I can't imagine any reprocussions from doing this, but the current code expects _wait_for_proc_all_() to be called _atexit_() so I would need some insight into

[bug #64451] Unexpected behaviour of xargs when multiple children exit with 255 in parallel

Follow-up Comment #2, bug #64451 (project findutils): Because checks for WSTOPSIG and WTERMSIG are done in the same place, sending SIGTERM or SIGSTOP to the children should also cause the same behaviour. In reality though trying to _kill_ chuldren with this tester seq 3 | xargs -n1 -P0 sh -c

[bug #64451] Unexpected behaviour of xargs when multiple children exit with 255 in parallel

Follow-up Comment #1, bug #64451 (project findutils): A workaround for scripts is to perform checks as soon as possible and exit 1 (or other value) instead. Potentially hundreds of processes will still be spawned but this avoids potentially processing outputs that are not yet complete.

[bug #64451] Unexpected behaviour of xargs when multiple children exit with 255 in parallel

4.9.0 Discussion Lock: Any Fixed Release: None ___ Follow-up Comments: --- Date: Thu 20 Jul 2023 07:46:06 AM UTC By: Anonymous = Synopsis = When xargs is invoked wi

[bug #64442] xargs closes stdin on receiving SIGUSR1 or SIGUSR2

Follow-up Comment #11, bug #64442 (project findutils): It is probably more reasonable to test with USR2 as pkill will signal any xargs running on the system. ___ Reply to this item at:

[bug #64442] xargs closes stdin on receiving SIGUSR1 or SIGUSR2

Follow-up Comment #10, bug #64442 (project findutils): An automated test for this issue can be done with sleep 0.2 && pkill -USR1 xargs & { sleep 0.5 && echo success; } | xargs ___ Reply to this item at:

[bug #64442] xargs closes stdin on receiving SIGUSR1 or SIGUSR2

Follow-up Comment #9, bug #64442 (project findutils): I decided to strace xargs on my phone and curiously read() is interrupted there as well but does not cause any problems. (file #54945) ___ Additional Item Attachment: File name:

[bug #64442] xargs closes stdin on receiving SIGUSR1 or SIGUSR2

Follow-up Comment #8, bug #64442 (project findutils): I retract my previous statement the patch works, I just accidentaly ran system xargs instead of the locally built one. ___ Reply to this item at:

[bug #64442] xargs closes stdin on receiving SIGUSR1 or SIGUSR2

Follow-up Comment #7, bug #64442 (project findutils): After testing further I found that SA_RESTART only fixes the case of waiting on read. I managed to trigger _xargs: error closing file_ by running this c=1; while true; do printf '%s\n' "$c"; c=$((c+1)); done | xargs and sending USR1 to

[bug #64442] xargs closes stdin on receiving SIGUSR1 or SIGUSR2

Follow-up Comment #6, bug #64442 (project findutils): Setting _sa_flags_ to SA_RESTART fixes this. (file #54944) ___ Additional Item Attachment: File name: sa_flags.diff Size:0 KB

[bug #64442] xargs closes stdin on receiving SIGUSR1 or SIGUSR2

Follow-up Comment #5, bug #64442 (project findutils): >From sigaction(3p) ... The _sa_flags_ field can be used to modify the behavior of the specified signal. ... SA_RESTART This flag affects the behavior of interruptible functions; that is, those specified to fail with errno set to *[EINTR]*.

[bug #64442] xargs closes stdin on receiving SIGUSR1 or SIGUSR2

Follow-up Comment #4, bug #64442 (project findutils): Here is a diff between a normal xargs execution and one interrupted with SIGUSR1. Normal execution is just running xargs and entering ^D. --- strace-normal.txt 2023-07-19 14:31:18.639157032 +0300 +++ strace-usr1.txt 2023-07-19

[bug #64442] xargs closes stdin on receiving SIGUSR1 or SIGUSR2

Follow-up Comment #1, bug #64442 (project findutils): I got same behaviour after building from findutils-4.9.0.tar.xz and master branch commit 81bcf2b9b39a107a5417867edeb7d65c731a1720 ___ Reply to this item at:

[bug #64442] xargs closes stdin on receiving SIGUSR1 or SIGUSR2

k: Any Fixed Release: None ___ Follow-up Comments: --- Date: Tue 18 Jul 2023 02:52:32 PM UTC By: Anonymous 1. the version of findutils you are using: $ xargs --version xarg

[bug #64253] Suggestion - Add support for libmagic and xattr

ussion Lock: Any Fixed Release: None ___ Follow-up Comments: --- Date: Thu 25 May 2023 07:18:47 PM UTC By: Anonymous I've gone through past patches, bugs and suggestions

[bug #64088] find should support file attribute flags (immutable, append-only, fscrypt, etc.)

: Open Release: None Discussion Lock: Any Fixed Release: None ___ Follow-up Comments: --- Date: Fri 21 Apr 2023 10:55:41 PM UTC By: Anonymous It

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

Follow-up Comment #9, bug #46305 (project findutils): Oh, and the patch that tries unlink() if rmdir() failes with ENOTDIR. ___ Reply to this item at:

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

Follow-up Comment #8, bug #46305 (project findutils): You bring up great points. I'd welcome a new, separate command-line option for a symlink-following delete, and the documentation change stating that -L is used during traversal only.

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

Follow-up Comment #6, bug #46305 (project findutils): It looks like the right thing to do is to delete the link and the thing the link points to, if the `-L` option (follow links) is enabled. ___ Reply to this item at:

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

Follow-up Comment #5, bug #46305 (project findutils): (Wow, I'd forgotten all about this bug report!) The interactions between find and symlinks have complicated implications, that's for sure. As said: > Finally, also rm(1) and rmdir(1) do not have an -L option - probably > for a good reason.

[bug #62227] Incorrect warning for -name /

Follow-up Comment #6, bug #62227 (project findutils): [comment #5 comment #5:] > Okay, I agree. > > The attached patch changes the behavior (with the first one doing > a trivial cleanup), and I'd like to improve the documentation further in a separate patch. > > Please check. > > (file #53051,

[bug #62255] find -iname *Word* and find -iname *word* give different results

Follow-up Comment #1, bug #62255 (project findutils): it seems the wildcard in front and behind of compact turned it into bold [comment #0 original submission:] > find (GNU findutils) 4.9.0 > Copyright (C) 2022 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later

[bug #62255] find -iname *Word* and find -iname *word* give different results

URL: Summary: find -iname *Word* and find -iname *word* give different results Project: findutils Submitted by: None Submitted on: Mon 04 Apr 2022 10:13:54 PM UTC Category: find

[bug #62227] Incorrect warning for -name /

Follow-up Comment #4, bug #62227 (project findutils): [comment #3 comment #3:] > So for my understanding: > if 'find / -prune -name /' boils down to 'echo /', then what is > the real use case behind? In that case it does not do anything useful, sure. To get something useful we would need to add

[bug #62227] Incorrect warning for -name /

Follow-up Comment #2, bug #62227 (project findutils): [comment #1 comment #1:] > I personally like to get such a warning, as one should try to use -name/-iname > with patterns for basenames only, and I think that the use case 'find / -prune -name /' > is quite exotic (and I would never have tried

[bug #62089] find -size -1024k different from -size -1M

Follow-up Comment #2, bug #62089 (project findutils): I think I know why, in `man find`, it actually gives an example: ``` -size n[cwbkMG] ... The + and - prefixes signify greater than and less than, as usual; i.e., an exact size of n units does not match. Bear in mind that the size is

[bug #62089] find -size -1024k different from -size -1M

Follow-up Comment #1, bug #62089 (project findutils): I also asked my question here: https://stackoverflow.com/questions/71200433/linux-find-by-size-bug ___ Reply to this item at:

[bug #61640] find -ls gives no UFT-8 output

URL: Summary: find -ls gives no UFT-8 output Project: findutils Submitted by: None Submitted on: Wed 08 Dec 2021 01:44:52 PM UTC Category: find Severity: 3 - Normal

[bug #61518] Typo in find --help documentation

URL: Summary: Typo in find --help documentation Project: findutils Submitted by: None Submitted on: Sun 21 Nov 2021 10:29:59 AM UTC Category: documentation Severity:

[bug #61501] find -execdir wrong root item path

URL: Summary: find -execdir wrong root item path Project: findutils Submitted by: None Submitted on: Wed 17 Nov 2021 04:39:21 PM UTC Category: find Severity: 3 -

[bug #61009] xargs need option to immediately stop on command fail

Follow-up Comment #8, bug #61009 (project findutils): [comment #7 comment #7:] > The idiom 'find -type f | xargs -IX cp X ...' is per se unsafe: > `xargs -I` reads the input line by line - but yes, files can > have a newline in their name! > Alternatively, use 'find ... -print0 | xargs -0 ...'

[bug #61009] xargs need option to immediately stop on command fail

Follow-up Comment #6, bug #61009 (project findutils): [comment #5 comment #5:] > Sorry, that had an obvious bug, here's a fix: > > find . -type f \( -exec cp -t "${IMGDIR_DST}" {} + -o -quit \) IMHO, this isn't _less_complex_ :-). There are: - \( \) - \+ - -o -quit This is complex. There are

[bug #61009] xargs need option to immediately stop on command fail

Follow-up Comment #3, bug #61009 (project findutils): > This is my guess because the shown use of find/xargs > is quite excessive (one cp(1) invocation per file) and unsafe (unusual filenames > would break the construct). About unsafe filenames. If you talk about this: find . -type f | xargs

[bug #61009] xargs need option to immediately stop on command fail

Follow-up Comment #2, bug #61009 (project findutils): [comment #1 comment #1:] > POSIX [1] specifies the following conditions when xargs shall terminate processing: > * child exits with 255, > * child was killed by a signal, or > * when reading the 'eofstr' string if the '-E eofstr' option is

[bug #61009] xargs need option to immediately stop on command fail

URL: Summary: xargs need option to immediately stop on command fail Project: findutils Submitted by: None Submitted on: Wed 04 Aug 2021 08:50:38 AM UTC Category: xargs

[bug #60822] Missing "@" in worked example

URL: Summary: Missing "@" in worked example Project: findutils Submitted by: None Submitted on: Fri 25 Jun 2021 11:20:07 AM UTC Category: documentation Severity: 3 -

[bug #60823] Missing "@" in worked example

URL: Summary: Missing "@" in worked example Project: findutils Submitted by: None Submitted on: Fri 25 Jun 2021 11:20:41 AM UTC Category: documentation Severity: 3 -

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

Follow-up Comment #3, bug #59766 (project findutils): well I've guessed, that this may a performance-problem, if stat() is called every time, so I would be completely satisfied with a new option, which let me force stat()-calls in certain situations.

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

Follow-up Comment #1, bug #59766 (project findutils): addon: find -inum ### also uses the inodes from getdent() for comparison... this also should be checked against the inodes from stat() ___ Reply to this item at:

[bug #59083] enhancement: find -D exec

Follow-up Comment #2, bug #59083 (project findutils): Thanks, that certainly helps for the original grep example. Interesting to see the argc count varying across a large run, e.g. $ ./find -D exec /usr -exec echo {} + |& grep 'DebugExec.*argc=' | cut -c1-41 | head DebugExec: launching process

[bug #59083] enhancement: find -D exec

URL: Summary: enhancement: find -D exec Project: findutils Submitted by: None Submitted on: Tue 08 Sep 2020 09:07:23 PM UTC Category: find Severity: 3 - Normal

[bug #59012] find examples wrong in man page

URL: Summary: find examples wrong in man page Project: findutils Submitted by: None Submitted on: Tue 25 Aug 2020 09:33:26 PM UTC Category: documentation Severity: 3

[bug #59012] find examples wrong in man page

Follow-up Comment #1, bug #59012 (project findutils): Well, after reading it a second time, the result is not that wrong as expected. Maybe its a little bit confusing that the result is not printed instad just one sentence explains what happens. To make the example more clear maybe the exact

[bug #58149] Whitespace parsing differs with and without -i

Follow-up Comment #2, bug #58149 (project findutils): [comment #1 comment #1:] > That is documented behavior. I see that in `man`, but not with `--help` which doesn't hint to that critical second part: -I R same as --replace=R -i, --replace[=R]replace R

[bug #58149] Whitespace parsing differs with and without -i

URL: Summary: Whitespace parsing differs with and without -i Project: findutils Submitted by: None Submitted on: Thu 09 Apr 2020 05:55:59 PM UTC Category: xargs

[bug #57839] Remove/fix getdtablesize tests

URL: Summary: Remove/fix getdtablesize tests Project: findutils Submitted by: None Submitted on: Mon 17 Feb 2020 05:47:01 PM UTC Category: None Severity: 3 - Normal

[bug #57775] Typo in find manpage

URL: Summary: Typo in find manpage Project: findutils Submitted by: None Submitted on: Sun 09 Feb 2020 07:54:01 AM UTC Category: find Severity: 3 - Normal

[bug #57461] Configure leaves directory trees that cannot be removed on PowerPC Mac OS X 10.5.8, Leopard

URL: Summary: Configure leaves directory trees that cannot be removed on PowerPC Mac OS X 10.5.8, Leopard Project: findutils Submitted by: None Submitted on: Sun 22 Dec 2019 12:37:32 PM UTC

[bug #57025] find -mtime will ignore large files

Follow-up Comment #4, bug #57025 (project findutils): Ok, I believed it's my fault... Quote from man page: *-atime n* File was last accessed n*24 hours ago. When find figures out how many 24-hour periods ago the file was last accessed, any fractional part is

[bug #57025] find -mtime will ignore large files

Follow-up Comment #2, bug #57025 (project findutils): find *.part -mtime 4 -type f -ls 18483504 128096 -rw-rw-r-- 1 threewaters threewaters 201725004 Oct 6 15:12 007.part 18486530 56768 -rw-rw-r-- 1 threewaters threewaters 559563054 Oct 6 10:17 1051.part 18487093 29816 -rw-rw-r-- 1

[bug #57025] find -mtime will ignore large files

URL: Summary: find -mtime will ignore large files Project: findutils Submitted by: None Submitted on: Wed 09 Oct 2019 12:14:44 PM UTC Category: find Severity: 3 -

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

Follow-up Comment #3, bug #45930 (project findutils): Hello, I can confirm "-ignore_readdir_race" not working: - On CentOS-7 with find v4.5.11 - On OpenSuse with find v4.5.12 EXAMPLE: root|dev-opensuse-server01|10:57|0|~: find /proc -ignore_readdir_race -maxdepth 3 -path "/proc/[0-9]*/fd/*"

[bug #56198] Typo in xargs.1: 'ouptut'

URL: Summary: Typo in xargs.1: 'ouptut' Project: findutils Submitted by: None Submitted on: Tue 23 Apr 2019 01:17:20 PM UTC Category: xargs Severity: 3 - Normal

[bug #55190] xargs documentation is confusing about the usage of -i and -I (capital i), and doesn't have any examples on this options

URL: Summary: xargs documentation is confusing about the usage of -i and -I (capital i), and doesn't have any examples on this options Project: findutils Submitted by: None Submitted on: Mon 10 Dec

[bug #46815] problem when testing file size

Follow-up Comment #7, bug #46815 (project findutils): I'm a decades-long professional programmer, and even I just found the present behavior of rounding up very surprising, which is why I'm here posting. If I can get confused, an ordinary user has no chance, and may well miss the fact that the

[bug #54591] gnulib components in findutils do not compile with glibc 2.28

Follow-up Comment #4, bug #54591 (project findutils): Thanks for the pointers to specific commits! Perhaps it would make sense to make a new release soon? ___ Reply to this item at:

[bug #54591] gnulib components in findutils do not compile with glibc 2.28

URL: Summary: gnulib components in findutils do not compile with glibc 2.28 Project: findutils Submitted by: None Submitted on: Wed 29 Aug 2018 12:33:36 PM UTC Category: None

[bug #54509] `-execdir command ;` returns 0 when it should not

URL: Summary: `-execdir command ;` returns 0 when it should not Project: findutils Submitted by: None Submitted on: Mon 13 Aug 2018 08:23:38 PM UTC Category: find

[bug #52890] `find --name` ignores files with non-printable character in the filename

Follow-up Comment #2, bug #52890 (project findutils): I give up :-( asterisk ERR asterisk ___ Reply to this item at: ___ Message sent via/by Savannah

[bug #52890] `find --name` ignores files with non-printable character in the filename

Follow-up Comment #1, bug #52890 (project findutils): Sorry markup has rotten the report - it shoud be: `find -name '*ERR*' ' ___ Reply to this item at:

[bug #52890] `find --name` ignores files with non-printable character in the filename

URL: Summary: `find --name` ignores files with non-printable character in the filename Project: findutils Submitted by: None Submitted on: Sun 14 Jan 2018 11:35:30 PM UTC Category:

[bug #52592] Documentation for 'find' unclear on default regex type

URL: Summary: Documentation for 'find' unclear on default regex type Project: findutils Submitted by: None Submitted on: Tue 05 Dec 2017 08:26:27 PM UTC Category: documentation

[bug #52409] `find -print0 -name ...` ignores `-name ...`

Follow-up Comment #2, bug #52409 (project findutils): Ah makes sense! Thanks for the thorough explanation -- didn't realize `print` was considered a predicate and thought it just controlled the final output. This can be closed -- apparently I can't do that since I posted anonymously.

[bug #52220] 'find -D' segfaults

URL: Summary: 'find -D' segfaults Project: findutils Submitted by: None Submitted on: Thu 12 Oct 2017 08:30:12 PM UTC Category: find Severity: 3 - Normal

[bug #52129] find lacks "-older" option symmetric to "-newer"

URL: Summary: find lacks "-older" option symmetric to "-newer" Project: findutils Submitted by: None Submitted on: Wed 27 Sep 2017 10:57:39 PM UTC Category: None

[bug #51711] non-helping error output with find

Follow-up Comment #10, bug #51711 (project findutils): thank you berny. and for the other point: is it so obvious, that '-name' only takes one argument? Because, as I pointed out several times it is not pointed out either in the "info"-file nor in the "man"-file. Instead, I found an plural 's'

[bug #51711] non-helping error output with find

Follow-up Comment #8, bug #51711 (project findutils): >> -the number of acceptable -name arguments > > I tried to find a place both in find's manpage and the Texinfo > manual (in latest Git), but didn't find an ambiguous place where > I could read that -name would accept more than 1 argument. >

[bug #51711] non-helping error output with find

Follow-up Comment #6, bug #51711 (project findutils): I think the discussion missed a bit what I pointed on: -the non-helping error message -the number of acceptable -name arguments -the insufficient non-bug explananation in man find, in relationship to the number of -name arguments

[bug #51711] non-helping error output with find

Follow-up Comment #5, bug #51711 (project findutils): Dale wrote : As far as I can tell, the error message means, Syntactically, this is a situation where a predicate must occur, but this argument is not a predicate. It looks like what would happen if you tried to specify a directory, but didn't

[bug #51711] non-helping error output with find

URL: Summary: non-helping error output with find Project: findutils Submitted by: None Submitted on: Wed 09 Aug 2017 11:12:29 PM UTC Category: find Severity: 3 -

[bug #51345] find shows different results despite using same command

URL: Summary: find shows different results despite using same command Project: findutils Submitted by: None Submitted on: Fri 30 Jun 2017 07:45:45 AM UTC Category: find

[bug #51069] find changes access time on directories

URL: Summary: find changes access time on directories Project: findutils Submitted by: None Submitted on: Fri 19 May 2017 03:44:12 PM UTC Category: find Severity: 3 -

[bug #50758] Incorrect example in find.info docs for '-perm'

URL: Summary: Incorrect example in find.info docs for '-perm' Project: findutils Submitted by: None Submitted on: Sat 08 Apr 2017 10:04:59 AM UTC Category: documentation

[bug #49466] xargs with 2>&1 returns error code in macOS 10.12

Follow-up Comment #4, bug #49466 (project findutils): This only appears on MaxOS 10.12. ___ Reply to this item at: ___ Message sent via/by Savannah

[bug #48683] possible regression: "no such file or directory" error when directory is removed during execution

URL: Summary: possible regression: "no such file or directory" error when directory is removed during execution Project: findutils Submitted by: None Submitted on: Tue 02 Aug 2016 10:07:42 PM UTC

[bug #48169] find makes unnecessary syscalls

URL: Summary: find makes unnecessary syscalls Project: findutils Submitted by: None Submitted on: Wed 08 Jun 2016 01:10:23 AM UTC Category: find Severity: 3 - Normal

[bug #48030] -exec + does not pass all arguments for ceratin specific filename lengths

URL: Summary: -exec + does not pass all arguments for ceratin specific filename lengths Project: findutils Submitted by: None Submitted on: Thu 26 May 2016 04:07:06 PM UTC Category:

[bug #47261] find produces two different results for the same command

URL: Summary: find produces two different results for the same command Project: findutils Submitted by: None Submitted on: Thu 25 Feb 2016 07:24:54 PM UTC Category: find

[bug #46815] problem when testing file size

Follow-up Comment #2, bug #46815 (project findutils): Hi James, Thanks for your quick response! Before I decided to submit this report I checked out the current version of GNU findutils as recommended on the project's website. The code for comparing file sizes, which I've quoted in the report,

[bug #46815] problem when testing file size

URL: Summary: problem when testing file size Project: findutils Submitted by: None Submitted on: Di 05 Jan 2016 06:08:51 UTC Category: find Severity: 3 - Normal

[bug #46670] Find terminates after searching an auto mounted nfs directory

Follow-up Comment #3, bug #46670 (project findutils): This does appear to be the same bug as reported in Gentoo, and it does appear to be fixed by 4.5.15. I'm not 100% sure because some things have changed in my system since I first reported the bug. Today, I've only been able trigger it

[bug #46670] Find terminates after searching an auto mounted nfs directory

URL: Summary: Find terminates after searching an auto mounted nfs directory Project: findutils Submitted by: None Submitted on: Sat 12 Dec 2015 02:46:51 AM UTC Category: find

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

URL: Summary: -ignore_readdir_race ineffective in find 4.5.11 and 4.5.14 Project: findutils Submitted by: None Submitted on: Fri 11 Sep 2015 01:05:25 PM UTC Category: find

  1   2   3   >