[bug #26945] [wishlist] locate-d: dynamic updates using dnotify, inotify or fsnotify

Update of bug #26945 (group findutils): Status: Postponed => None ___ Reply to this item at: ___ Mess

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

Follow-up Comment #11, bug #46305 (project findutils): [comment #9 comment #9:] > Oh, and the patch that tries unlink() if rmdir() failes with ENOTDIR. That patch is here: [PATCH] find: fix -L and -delete removing symlinks to directories https://lists.gnu.org/archive/html/findutils-patch

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

Follow-up Comment #10, bug #46305 (project findutils): [comment #8 comment #8:] > 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. The patch I submitted that

[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 #7, bug #46305 (project findutils): [comment #6 comment #6:] > 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. As I tried to explain earlier, I think that interpretation is incorrect and un

[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 #46305] Doing "find -L . -type d -delete" fails on symlinks to directories.

member the fact that > there was a symlink. So, when deleting, it uses rmdir rather > than unlink (or their equivalents), which fails to remove the > symlink, and that can break the overall deletion. > > Steps to repeat: > > $ mkdir t dd dd/d > $ touch dd/d/f ff > $

[bug #62480] find -D stat cannot print anything

Update of bug #62480 (project findutils): Open/Closed:Open => Closed ___ Follow-up Comment #3: Thanks, I'm hereby closing this issue. _

[bug #62480] find -D stat cannot print anything

Follow-up Comment #2, bug #62480 (project findutils): Thank you very much, I am interested in this program so I am learning it ___ Reply to this item at: __

[bug #62480] find -D stat cannot print anything

o bs=1 count=$f > f$f; done # -ls needs stat(). $ find -D stat -ls 409613 4 drwxr-xr-x 2 bernyusers4096 May 17 17:07 . debug_stat (f0) 394313 0 -rw-r--r-- 1 bernyusers 0 May 17 17:07 ./f0 debug_stat (f100) 393551 0 -rw-r--r-- 1 berny

[bug #62480] find -D stat cannot print anything

URL: <https://savannah.gnu.org/bugs/?62480> Summary: find -D stat cannot print anything Project: findutils Submitted by: zhoushuiqing Submitted on: Tue 17 May 2022 01:16:55 PM UTC Category: find Se

[bug #59083] enhancement: find -D exec

Update of bug #59083 (project findutils): Open/Closed:Open => Closed ___ Reply to this item at: ___

[bug #59083] enhancement: find -D exec

Update of bug #59083 (project findutils): Fixed Release:None => 4.8.0 ___ Reply to this item at: ___

[bug #59083] enhancement: find -D exec

gth of the arguments ... the sum of which always a bit below 128k (apart from the last run, obviously): $ ~/findutils/find/find -D exec /usr -exec echo {} + 2>&1 \ | grep 'DebugExec.*argc=' \ | awk '{print $1, $2, $3, $4, length($0)}' DebugExec: launchi

[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: lau

[bug #59083] enhancement: find -D exec

gt; berny ___ Follow-up Comment #1: Good spot. The attached addresses it. (file #49799) ___ Additional Item Attachment: File name: 0001-find-improve-D-exec-debug-output.patch Size:4 KB

[bug #59083] enhancement: find -D exec

URL: <https://savannah.gnu.org/bugs/?59083> 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 -

[bug #52220] 'find -D' segfaults

Update of bug #52220 (project findutils): Open/Closed:Open => Closed ___ Reply to this item at: ___

[bug #52220] 'find -D' segfaults

Update of bug #52220 (project findutils): Fixed Release: 4.6.0 => 4.7.0 ___ Reply to this item at: ___

[PATCH] find: add '-D all' to enable all debug flags

now outputs a better hint in case the user passed an unquoted shell- glob pattern to options like -name, i.e., when the offending argument is an existing file. +find now supports the debug option '-D all' to include all of the other +debug options at once. + xargs now supports the

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

Follow-up Comment #3, bug #46305 (project findutils): With "-L bar -delete", find would have to delete 2 files: a) the symlink target '../foo', and b) the symlink itself 'bar/baz'. I agree with James that trying to fix (or work around) this would probably more ask for trouble than being of help.

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

delete ‘bar’: Directory not empty (No -type d necessary.) strace shows that find tried to unlinkat(AT_FDCWD, "bar/baz", AT_REMOVEDIR) = -1 ENOTDIR (Not a directory) but "bar/baz" is not a directory so AT_REMOVEDIR is wrong. _

Re: [PATCH] ftsfind.c: avoid buffer overflow in -D code

On 07/09/2018 05:23 PM, Jim Meyering wrote: > On Mon, Jul 9, 2018 at 5:57 AM, Bernhard Voelker > wrote: >> On 07/08/2018 06:19 AM, Jim Meyering wrote: >>> On Sat, Jul 7, 2018 at 4:13 PM, Bernhard Voelker >>> wrote: - static char buf[10]; + static char buf[14]; >>> >>> Or maybe this, s

Re: [PATCH] ftsfind.c: avoid buffer overflow in -D code

On Mon, Jul 9, 2018 at 5:57 AM, Bernhard Voelker wrote: > On 07/08/2018 06:19 AM, Jim Meyering wrote: >> On Sat, Jul 7, 2018 at 4:13 PM, Bernhard Voelker >> wrote: >>> - static char buf[10]; >>> + static char buf[14]; >> >> Or maybe this, since you already use the intprops module, just add >> t

Re: [PATCH] ftsfind.c: avoid buffer overflow in -D code

On 07/08/2018 06:19 AM, Jim Meyering wrote: > On Sat, Jul 7, 2018 at 4:13 PM, Bernhard Voelker > wrote: >> - static char buf[10]; >> + static char buf[14]; > > Or maybe this, since you already use the intprops module, just add > this somewhere prior: #include "intprops.h" > > static char buf

Re: [PATCH] ftsfind.c: avoid buffer overflow in -D code

On Sat, Jul 7, 2018 at 4:13 PM, Bernhard Voelker wrote: > Reported by GCC 8.1.1: > > ftsfind.c: In function ‘get_fts_info_name’: > ftsfind.c:164:23: warning: ‘%d’ directive writing between 1 and 11 bytes into > a region of size 9 [-Wformat-overflow=] > sprintf

[PATCH] ftsfind.c: avoid buffer overflow in -D code

Reported by GCC 8.1.1: ftsfind.c: In function ‘get_fts_info_name’: ftsfind.c:164:23: warning: ‘%d’ directive writing between 1 and 11 bytes into a region of size 9 [-Wformat-overflow=] sprintf (buf, "[%d]", info); ^~ ftsfind.c:164:7: note: ‘sprintf’ output

[bug #52220] 'find -D' segfaults

Update of bug #52220 (project findutils): Status: Ready For Test => Fixed ___ Follow-up Comment #5: Thanks for the review - pushed (with the duplicate "the" in the commit message removed) at: ht

[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

to handle NULL in the first call. Patch attached - please check. (file #42192) ___ Additional Item Attachment: File name: 0001-find-avoid-segfault-with-D-without-argument.patch Size:4

[bug #52220] 'find -D' segfaults

process_debug_options (arg=0x0) at util.c:851 #2 process_leading_options (argc=, argv=) at util.c:973 #3 0xafba in main (argc=2, argv=0x7fffdcf8) at ftsfind.c:693 The code does else if (0 == strcmp ("-D", argv[i])) { process_debug_options (argv[i+1]);

[bug #52220] 'find -D' segfaults

can't reproduce here: $ find/find -D find/find: Empty argument to the -D option. $ find/find --version find (GNU findutils) 4.6.0 ... and with the latest source from Git: $ find/find -D find/find: Empty argument to the -D option. Try 'find/find --help' for more informati

[bug #52220] 'find -D' segfaults

URL: <http://savannah.gnu.org/bugs/?52220> Summary: 'find -D' segfaults Project: findutils Submitted by: None Submitted on: Thu 12 Oct 2017 08:30:12 PM UTC Category: find Seve

[PATCH 5/6] doc: improve description of the -D option in find.1

* find/find.1 (-D): Change argument name from "debugoptions" to "debugopts" to match the synopsis, thus making searching in the man page easier. While at it, sort possible arguments alphabetically. --- find/find.1 | 24 ++-- 1 file changed, 14 inserti

[PATCH 3/3] Retire configure --enable-debug in favour of find -D ...

From: James Youngman * find/defs.h (enum DebugOption): add DebugTime. * find/util.c (debugassoc): -D time sets the DebugTime debug flag. * find/oldfind.c (main): print the value of options.cur_day_start when "-D time" is in effect (instead of when DEBUG is #defined). * find/ftsfi

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

Additional Item Attachment, bug #46305 (project findutils): File name: sv-43605-base.sh Size:1 KB ___ Reply to this item at: ___ Message

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

Update of bug #46305 (project findutils): Status:None => Wont Fix ___ Follow-up Comment #1: > The '-L' option makes '-type d' detect symlinks to directories, b

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

Update of bug #46305 (project findutils): Severity: 3 - Normal => 4 - Important Assigned to:None => jay ___ Reply to this item at:

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

URL: <http://savannah.gnu.org/bugs/?46305> Summary: Doing "find -L . -type d -delete" fails on symlinks to directories. Project: findutils Submitted by: pfudd Submitted on: Tue 27 Oct 2015 01:23:12 AM GMT

Re: Regression: "find dir/. -type d -empty -delete" claims 'unsuccessful', breaking scripts.

ry to mean it's contents on a recursive or copy (compare cp -al src/. dst/.). However, "find dir/. -type d -empty -delete" works, but Does it? Definition: The ".." and "." entries are structurally required entries that appear to exist inside

Re: Regression: "find dir/. -type d -empty -delete" claims 'unsuccessful', breaking scripts.

in a directory to mean it's contents > >>on a recursive or copy (compare cp -al src/. dst/.). > >> > >>However, "find dir/. -type d -empty -delete" works, but > > > >Does it? > > > >$ mkdir dir && strace -eunlinkat -- find dir/. -

Re: Regression: "find dir/. -type d -empty -delete" claims 'unsuccessful', breaking scripts.

On 18/11/2013 16:29, Dmitry V. Levin wrote: On Mon, Nov 18, 2013 at 03:55:52PM -0800, Linda A. Walsh wrote: In coreutils 8.21-7.1.3. It has been standard to use "." in a directory to mean it's contents on a recursive or copy (compare cp -al src/. dst/.). However, "find

Re: Regression: "find dir/. -type d -empty -delete" claims 'unsuccessful', breaking scripts.

On 18/11/2013 20:04, Eric Blake wrote: On 11/18/2013 06:20 PM, Linda Walsh wrote: >>> However, "find dir/. -type d -empty -delete" works, but exits with >>> a failure code causing scripts to break. >>> >> This behavior is required by POSIX.

Re: Regression: "find dir/. -type d -empty -delete" claims 'unsuccessful', breaking scripts.

On 11/18/2013 05:25 PM, Linda Walsh wrote: > They don't require it for the case of "find ."? > > or cp -al a/. b/. > > ? I couldn't parse this question. > > > Are you saying we need an alternate core utils? Nothing is stopping you from writing your own software that behaves the way you want.

Re: Regression: "find dir/. -type d -empty -delete" claims 'unsuccessful', breaking scripts.

On 11/18/2013 06:20 PM, Linda Walsh wrote: >>> >>> However, "find dir/. -type d -empty -delete" works, but >>> exits with a failure code causing scripts to break. >>> >> >> This behavior is required by POSIX. Sorry. POSIX requir

Re: Regression: "find dir/. -type d -empty -delete" claims 'unsuccessful', breaking scripts.

On 18/11/2013 16:15, Eric Blake wrote: On 11/18/2013 04:55 PM, Linda A. Walsh wrote: In coreutils 8.21-7.1.3. It has been standard to use "." in a directory to mean it's contents on a recursive or copy (compare cp -al src/. dst/.). However, "find dir/. -type d -e

Re: Regression: "find dir/. -type d -empty -delete" claims 'unsuccessful', breaking scripts.

On Mon, Nov 18, 2013 at 03:55:52PM -0800, Linda A. Walsh wrote: > In coreutils 8.21-7.1.3. > > It has been standard to use "." in a directory to mean it's contents > on a recursive or copy (compare cp -al src/. dst/.). > > However, "find dir/. -type

Re: Regression: "find dir/. -type d -empty -delete" claims 'unsuccessful', breaking scripts.

They don't require it for the case of "find ."? or cp -al a/. b/. ? Are you saying we need an alternate core utils?

Re: Regression: "find dir/. -type d -empty -delete" claims 'unsuccessful', breaking scripts.

On 11/18/2013 04:55 PM, Linda A. Walsh wrote: > In coreutils 8.21-7.1.3. > > It has been standard to use "." in a directory to mean it's contents > on a recursive or copy (compare cp -al src/. dst/.). > > However, "find dir/. -type d -empty -delete&qu

Regression: "find dir/. -type d -empty -delete" claims 'unsuccessful', breaking scripts.

In coreutils 8.21-7.1.3. It has been standard to use "." in a directory to mean it's contents on a recursive or copy (compare cp -al src/. dst/.). However, "find dir/. -type d -empty -delete" works, but exits with a failure code causing scripts to break. Surprisingl

[bug #26945] [wishlist] locate-d: dynamic updates using dnotify, inotify or fsnotify

Update of bug #26945 (project findutils): Severity: 3 - Normal => 1 - Wish ___ Reply to this item at: ___ M

[bug #26945] [wishlist] locate-d: dynamic updates using dnotify, inotify or fsnotify

Follow-up Comment #6, bug #26945 (project findutils): There is now an implementation of a system-wide filesystem monitor using fanotify: ​http://www.piware.de/2012/02/fatrace-report-system-wide-file-access-events/ ___ Reply to this item at

[bug #29698] Correct and clarify documentation of xargs -d option

Update of bug #29698 (project findutils): Open/Closed:Open => Closed Fixed Release:None => 4.5.11 ___ Reply to this item at:

[bug #29698] Correct and clarify documentation of xargs -d option

otes and backslash are not special; ev‐ ery character in the input is taken literally. The -d option disables any end-of-file string, which is treated like any other argument. You can use this option when the input consists of simply newline-separated items, although it is almost alway

[bug #29698] Correct and clarify documentation of xargs -d option

Update of bug #29698 (project findutils): Status: Need Info => None ___ Reply to this item at: ___ M

[bug #29698] Correct and clarify documentation of xargs -d option

Follow-up Comment #3, bug #29698 (project findutils): I see what you're saying now about the input vs. the -d argument. The way the help reads, I thought it was saying there's nothing special about a backslash in the -d argument, which isn't true, because of C backslash escap

[bug #29698] Correct and clarify documentation of xargs -d option

Follow-up Comment #2, bug #29698 (project findutils): (if no response within a couple of weeks, I'll close this bug) ___ Reply to this item at: ___ Mes

[bug #29698] Correct and clarify documentation of xargs -d option

ot special, as specified by this text: << -d delim Input items are terminated by the specified character. Quotes and backslash are not special; every character in the input is taken literally. >> If you are talking about backslashes within delim, then this is specified by this text:

[bug #29698] Correct and clarify documentation of xargs -d option

URL: <http://savannah.gnu.org/bugs/?29698> Summary: Correct and clarify documentation of xargs -d option Project: findutils Submitted by: jonjensen Submitted on: Wed 28 Apr 2010 04:04:59 AM GMT Category: documen

[bug #26945] [wishlist] locate-d: dynamic updates using dnotify, inotify or fsnotify

Update of bug #26945 (project findutils): Status:None => Postponed ___ Follow-up Comment #5: updatedb would probably be best rewritten. I'm going to mark the updatedb-related bus as "P

[PATCH 1/5] Adopt the use of the gnulib module d-type.

* import-gnulib.config (modules): Import the d-type module. * configure.ac: Remove old struct dirent.d_type detection logic (since we now use the gnulib macro from the d-type module for this). * find/parser.c (parse_version): Use HAVE_STRUCT_DIRENT_D_TYPE (since the d-ino module still defines it

[bug #27017] find -D opt / -fstype ext3 -print , -quit coredumps

Update of bug #27017 (project findutils): Open/Closed:Open => Closed Fixed Release:None => 4.5.6b ___ Reply to this item at:

[bug #27017] find -D opt / -fstype ext3 -print , -quit coredumps

Update of bug #27017 (project findutils): Status: In Progress => Fixed ___ Follow-up Comment #1: Applied and pushed to 4.4.x and 4.5.x. _

Re: [PATCH] Fix Savannah bug #27017: find -D opt / -fstype ext3 -print , -quit coredump (vs. 4.5.x)

On Sat, Jul 11, 2009 at 9:29 PM, James Youngman wrote: > Fix Savannah bug #27017: find -D opt / -fstype ext3 -print , -quit > coredumps. Applied and pushed to 4.4.x and 4.5.x.

[PATCH] Fix Savannah bug #27017: find -D opt / -fstype ext3 -print , -quit coredump (vs. 4.5.x)

Fix Savannah bug #27017: find -D opt / -fstype ext3 -print , -quit coredumps. * find/tree.c (set_new_parent): Initialise struct predicate->arg_text to NULL (instead of leaving it uninitialised). (get_new_pred_noarg): Likewise. (get_new_pred): Initialise predicate->arg_t

[bug #27017] find -D opt / -fstype ext3 -print , -quit coredumps

Additional Item Attachment, bug #27017 (project findutils): File name: 0001-Fix-Savannah-bug-27017-find-D-opt-fstype-ext3.patch Size:29 KB ___ Reply to this item at: <http://savannah.gnu.org/bugs/?27

[PATCH] Fix Savannah bug #27017: find -D opt / -fstype ext3 -print , -quit coredump.

Fix Savannah bug #27017: find -D opt / -fstype ext3 -print , -quit coredumps. * find/tree.c (set_new_parent): Initialise struct predicate->arg_text to NULL (instead of leaving it uninitialised). (get_new_pred_noarg): Likewise. (get_new_pred): Initialise predicate->arg_t

Fix Savannah bug #27017: find -D opt / -fstype ext3 -print , -quit core dumps.

This patch is against 4.4.x.

[bug #27017] find -D opt / -fstype ext3 -print , -quit coredumps

URL: <http://savannah.gnu.org/bugs/?27017> Summary: find -D opt / -fstype ext3 -print , -quit coredumps Project: findutils Submitted by: jay Submitted on: Sat 11 Jul 2009 06:48:52 PM GMT Category

[bug #26945] [wishlist] locate-d: dynamic updates using dnotify, inotify or fsnotify

Follow-up Comment #4, bug #26945 (project findutils): Eric Paris wrote: It could, although fanotify doesn't have good (really any?) handling of mv. I've been thinking about how to handle those but haven't had the time to try to code something, and I'm sure that the VFS people are going to give

[bug #26945] [wishlist] locate-d: dynamic updates using dnotify, inotify or fsnotify

Follow-up Comment #3, bug #26945 (project findutils): I'm sending a mail to the fsnotify/fanotify author and will report back to this bug. ___ Reply to this item at: ___

[bug #26945] [wishlist] locate-d: dynamic updates using dnotify, inotify or fsnotify

Follow-up Comment #2, bug #26945 (project findutils): I believe fsnotify will allow this: http://lwn.net/Articles/311850/ If it doesn't, contacting the fsnotify/fanotify author and asking for the feature might be a good idea. For inotify it appears that Linux allows the number of watches to be

[bug #26945] [wishlist] locate-d: dynamic updates using dnotify, inotify or fsnotify

Follow-up Comment #1, bug #26945 (project findutils): I believe the problem with this approach is that it requires an open fd per directory to be monitored. There are over 140,000 directories just on my desktop machine. If you can think of a way to do this with a daemon that uses less than (sa

[bug #26945] [wishlist] locate-d: dynamic updates using dnotify, inotify or fsnotify

URL: <http://savannah.gnu.org/bugs/?26945> Summary: [wishlist] locate-d: dynamic updates using dnotify, inotify or fsnotify Project: findutils Submitted by: pabs Submitted on: Fri 03 Jul 2009 03:53:04 PM WST Ca

[bug #19904] xargs produces different output with similar "-d" parameter

Update of bug #19904 (project findutils): Open/Closed:Open => Closed ___ Follow-up Comment #3: No response from submitter; closing. ___

[bug #19904] xargs produces different output with similar "-d" parameter

Update of bug #19904 (project findutils): Summary: xargs produces different output with similar parameter => xargs produces different output with similar "-d" parameter ___ Reply to this item

[bug #15167] find . -type d output is not in order

Update of bug #15167 (project findutils): Status:None => Invalid Open/Closed:Open => Closed ___ Reply to this item at:

[bug #15167] find . -type d output is not in order

Follow-up Comment #1, bug #15167 (project findutils): Actually in your example the contents of the directory are not sorted. Instead, ls is sorting them (ls is required to sort its arguments). The find program, on the other hand, is not required to do this. The find program just prints the fil

[bug #15167] find . -type d output is not in order

URL: <http://savannah.gnu.org/bugs/?func=detailitem&item_id=15167> Summary: find . -type d output is not in order Project: findutils Submitted by: None Submitted on: Wed 12/07/05 at 19:44 Cate



___ Bug-findutils mailing list Bug-findutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-findutils