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

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 (buf, "[%d]", info); >

Re: [PATCH] maint: use an optimal-for-findutils xz compression setting

On Sun, Oct 29, 2017 at 2:24 PM, Bernhard Voelker wrote: > On 10/28/2017 08:06 PM, Andreas Metzler wrote: >> On 2017-10-28 Bernhard Voelker wrote: >>> * cfg.mk: Set XZ_OPT = -7e (determined empirically). >>> The compressed tarball size is identical to the default settings (-9e), >>> but using -9e

Re: Proposed stable release of GNU findutils: opinions?

On Wed, Dec 23, 2015 at 9:45 AM, James Youngman wrote: > On Sun, Dec 20, 2015 at 5:30 PM, Andreas Metzler wrote: >> On 2015-12-18 James Youngman wrote: >>> I'm considering making a stable release (i.e. 4.6.0) of GNU findutils >>> in the next few days, essentially identical to the recent 4.5.15 >

Re: [PATCH] fts: reduce two or more trailing spaces to just one, usually

James Youngman wrote: > On Fri, Nov 16, 2012 at 10:33 PM, Paul Eggert wrote: >> On 11/16/12 14:10, Dmitry V. Levin wrote: >>> As I said, my proposal is to introduce a new FTS_ flag that would make >>> fts_open behave as before that change, and use this flag in findutils. >>> I haven't heard yet ne

Re: [PATCH] fts: reduce two or more trailing spaces to just one, usually

Dmitry V. Levin wrote: > On Fri, Nov 16, 2012 at 09:52:06PM +, James Youngman wrote: >> Did anybody do any further work on whether it worked best to fix this >> in gnulib or in findutils? > > As I said, my proposal is to introduce a new FTS_ flag that would make > fts_open behave as before that

[bug #37356] excessive memory usage when using -printf and %A %C or %T

Additional Item Attachment, bug #37356 (project findutils): File name: find-leaks-v2.patchSize:2 KB ___ Reply to this item at: ___ Message

[bug #37356] excessive memory usage when using -printf and %A %C or %T

Follow-up Comment #1, bug #37356 (project findutils): Note that the V2 patch should be applied after the three patches I posted here: http://thread.gmane.org/gmane.comp.gnu.findutils.bugs/5216 However, they are really independent, and that order is imposed solely due to the fact that ChangeLog is

build fixes and clean-up

import-gnulib.sh failure find: minor tweaks >From adb5b90eeb47bf74754ee5a7c9dbddc78f921c28 Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Tue, 18 Sep 2012 11:42:23 +0200 Subject: [PATCH 1/3] build: stop using now-obsolete macro, AM_C_PROTOTYPES * configure.ac: Don't use

[bug #37356] excessive memory usage when using -printf and %A %C or %T

Additional Item Attachment, bug #37356 (project findutils): File name: find-leaks.patch Size:1 KB ___ Reply to this item at: ___ Message

[PATCH] Fix a typo in find.texi.

Hi, Just noticed this... >From 57e807f64c61b225adc7006edc667ea3afec0514 Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Sun, 11 Sep 2011 15:54:41 +0200 Subject: [PATCH] Fix a typo in find.texi. * doc/find.texi (Error Messages From find): Fix typo s/an/a/. --- ChangeLog |5 +

Re: [PATCH] rm, du, chmod, chown, chgrp: use much less memory for large directories

Voelker, Bernhard wrote: > Jim Meyering wrote: > >> Voelker, Bernhard wrote: >> >> > Jim Meyering wrote: >> > >> > +++ b/tests/rm/4-million-entry-dir >> > ... >> > +# Put 4M files in a directory. >> > +mkdir d &&

Re: [PATCH] rm, du, chmod, chown, chgrp: use much less memory for large directories

Voelker, Bernhard wrote: > Jim Meyering wrote: > > +++ b/tests/rm/4-million-entry-dir > ... > +# Put 4M files in a directory. > +mkdir d && cd d || framework_failure_ > +seq 400|xargs touch || framework_failure_ > + > +cd .. > + > +# Restricted to 50M

Re: [PATCH 1/4] Reduce memory consumption of fts.

James Youngman wrote: > * gnulib: update to latest, mainly to include a bugfix (gnulib > commit 47cb657eca1abf2c26c32c8ce03def994a3ee37c) which limits the > memory consumed by fts. > * find/testsuite/sv-34079.sh: New test, verifying that memory > growth in ftsfind does not grow indefinitely as the

Re: [PATCH 2/4] Reduce memory consumption of oldfind on large directories.

James Youngman wrote: > * find/find.c (process_dir): Reduce memory consumption for large > directories. Don't save the whoel directory content with whoel -> whole > xsavedir, instead just loop over the results of readdir. This > means that oldfind will consume one file descriptor per directory

Re: [PATCH 4/4] Describe recent memory savings on very large directories.

James Youngman wrote: > * NEWS: Describe the recent changes which reduce the amount of > heap memory used in processing directories containing very many > entries. ... Thanks for the quick work. There's a typo below: > diff --git a/NEWS b/NEWS > index 2f031d4..7828704 100644 > --- a/NEWS > +++ b/

[PATCH] rm, du, chmod, chown, chgrp: use much less memory for large directories

ck -C tests TESTS=rm/4-million-entry-dir VERBOSE=yes \ RUN_VERY_EXPENSIVE_TESTS=yes I'll wait at least a couple hours before pushing this. >From 0ba576979a10a11e5652fd155266464b1e784892 Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Fri, 19 Aug 2011 17:51:45 +0200 Subject: [PATCH]

Re: [PATCH] fts: introduce FTS_NOATIME

Eric Blake wrote: > This gives clients the option to try a non-invasive traversal, > where merely visiting a directory does not update its timestamp, > where such is supported by the kernel. > > Note that whiteout support and O_NOATIME support are orthogonal: > there is no way to get O_NOATIME beha

Re: fts and O_NOATIME

Eric Blake wrote: > http://savannah.gnu.org/bugs/?33724 raised the issue that findutils is > updating directory atime as part of traversing a hierarchy (and, > according to POSIX, this behavior is the correct default). However, it > would be nice to support the use of fts in a mode where O_NOATIME

Re: Fwd: [Findutils-patches] [PATCH 1/3] xargs: patch for varying parallelism

James Youngman wrote: > I've just pushed this patch to the public repository (with the date of > the ChangeLog entry updated and, obviously, having ported the change > to the current tree). > > I'd like to thank John for the contribution and being patient, and > Sven for testing the change - and re

assertion failed! find: ftsfind.c:470: consider_visiting: ...

Hello, I've just hit this assertion: find: ftsfind.c:470: consider_visiting: Assertion `ent->fts_info == 11 || state.type != 0' failed. I suspect that one process was traversing a hierarchy with find while another was deleting it via rm -rf. Neither command was run directly, so it may be ha

[PATCH] frcode: avoid link failure due to multiple program_name definitions

(.bss+0x0): multiple definition of `program_name' frcode.o:(.bss+0x0): first defined here collect2: ld returned 1 exit status make[4]: *** [frcode] Error 1 Doing the following solved it for me: >From 5c771a65a3739395011d1ecfcc84778fd87b1635 Mon Sep 17 00:00:00 2001 From: Jim Meyering Da

Re: [PATCH] fts: do not fail on a submount during traversal

Kamil Dudka wrote: > we've discussed with Jim the issue with mounts triggered during directory > tree traversal and we've decided to make a trade-off for now - enable the > extra stat call only if the FTS_TIGHT_CYCLE_CHECK is set. This means it only > affects find and du for now and leaves other ut

Re: Using gnulib's maint.mk (and perhaps, using gnulib as a git submodule)

James Youngman wrote: > On Mon, Nov 9, 2009 at 12:46 PM, Eric Blake wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> According to James Youngman on 11/9/2009 3:09 AM: >>> On Mon, Nov 9, 2009 at 9:44 AM, Jim Meyering wrote: >>>

[PATCH] Adjust two xargs diagnostics (was: Localization bugs in findutils

erting %s " > + "days to a number of seconds"); >struct timespec origin; > >if (!collect_arg(argv, arg_ptr, &timearg)) Hi James, I spotted at least one more with this: $ grep -nE '\From 333b90e420200f8c083264ba1781dc01221d2807 Mo

Re: keep find from trying to spider directories where it has no permission

James Youngman wrote: > On Sat, Sep 19, 2009 at 4:41 PM, wrote: >> EB> Untested, but: >> EB> -type d \! -readable -prune >> EB> seems like it should do the trick of telling find to not descend into >> EB> unreadable directories. >> >> Well, I hope there can be an example added to the find man pag

Re: [PATCH 1/2] find: add SELinux support

Kamil Dudka wrote: > On Thu August 6 2009 12:36:06 Kamil Dudka wrote: >> On Thu August 6 2009 12:16:58 Jim Meyering wrote: >> > Kamil Dudka wrote: >> > > On Thu July 30 2009 13:57:00 Jim Meyering wrote: >> > >> > The attached incremental patch fix

Re: [PATCH 1/2] find: add SELinux support

Kamil Dudka wrote: > On Thursday 06 of August 2009 14:01:37 Jim Meyering wrote: >> ... >> >> >> I'll move them to gnulib. >> > >> > Thanks! >> > >> > Just let me note there is no explicit dependency on the openat module >&g

Re: [PATCH 1/2] find: add SELinux support

... >> I'll move them to gnulib. > > Thanks! > > Just let me note there is no explicit dependency on the openat module (namely > lib/at-func.c). Is the dependency implied somehow? Good point. I'll add that module dependency. Thanks. I'll also do a stand-alone test, which should expose any other

Re: [PATCH 1/2] find: add SELinux support

Kamil Dudka wrote: > On Thu August 6 2009 12:16:58 Jim Meyering wrote: >> Kamil Dudka wrote: >> > On Thu July 30 2009 13:57:00 Jim Meyering wrote: >> >> > The attached incremental patch fixes it. Now it works on both Fedora >> >> > and Debian. Bu

Re: [PATCH 1/2] find: add SELinux support

Kamil Dudka wrote: > On Thu July 30 2009 13:57:00 Jim Meyering wrote: >> > The attached incremental patch fixes it. Now it works on both Fedora and >> > Debian. But unfortunately it does not work with the stable version >> > (4.4.2) of findutils. Could anybody poin

Re: [PATCH 1/2] find: add SELinux support

Kamil Dudka wrote: > On Tue July 14 2009 21:31:22 Eric Blake wrote: >> Kamil Dudka redhat.com> writes: >> > In other words on Debian find does not change the working directory >> > before calling lgetxattr syscall. That's why lgetxattr does not see the >> > file and returns ENOENT (No such file or

[bug #26281] find -depth sometimes visits nodes in the wrong order

Follow-up Comment #3, bug #26281 (project findutils): Hi James, It looks to me like find/fts are doing just what is required. I.e,. processing all entries in a directory before processing the directory itself. It's easier to see with an example like this, where directories are actually processe

Re: [Findutils-patches] [PATCH] Optimise away calls to stat if all we need is the inode number (bug #24342).

James Youngman wrote: > On Sun, Mar 8, 2009 at 4:35 PM, Jim Meyering wrote: >> James Youngman wrote: >> ... >>> +#24342: -inum predicate shoud use dirent.d_ino instead of stat.st_ino >>> +(this is a performance bug). >> >> You might want to mention th

Re: [Findutils-patches] [PATCH] Optimise away calls to stat if all we need is the inode number (bug #24342).

James Youngman wrote: ... > +#24342: -inum predicate shoud use dirent.d_ino instead of stat.st_ino > +(this is a performance bug). You might want to mention that dirent.d_ino values are unreliable on some systems (Linux, Solaris, *BSD get it wrong, but Cygwin gets it right). The problem is with mo

make find *much* faster on reiserfs

, and valgrind says they do so cleanly. And my daily updatedb-run find now runs in just 3-4 minutes instead of over 30. >From 167e1bb018f4a336b57a792e3b552dfc9993459b Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Sun, 15 Feb 2009 13:03:52 +0100 Subject: [PATCH 1/2] find: enable fts's F

3 patches: avoid warnings, unnecessary include

Hi, Here are three tiny patches. >From 4af19b0784919915be4341b9917192c0d7dd232e Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Sun, 11 Jan 2009 19:32:29 +0100 Subject: [PATCH 1/3] find: avoid warning about unused local * find/pred.c (scan_for_digit_differences): Remove declaration of unu

Re: fts: make find *much* faster on dirent.d_type-challenged FS

Jim Meyering wrote: ... > Here's an incremental, then the adjusted full patch. > > BTW, I test this with coreutils by running chcon -R[*] on a directory > containing 1000 files. With the patch, strace -c reports *1* > calls to newfstatat, but without, it reports 1001 of them. Pushed.

Re: fts: make find *much* faster on dirent.d_type-challenged FS

tion in the dir, FTS_CWD_FD? */ + opt_ok = leaf_optimization_applies (sp->fts_cwd_fd); t2->opt_ok = opt_ok; + t2->st_dev = p->fts_statp->st_dev; - struct LCO_ent *e = hash_insert (h, t2); - if (e == NULL) + ent = hash_insert (h, t2); + if (ent == NULL) { /* in

fts: make find *much* faster on dirent.d_type-challenged FS

shing. >From 86014dca17f984dbb6c8e66dfcce0f655f7bd3eb Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Wed, 11 Feb 2009 21:08:11 +0100 Subject: [PATCH 1/2] fts: move a function definition "up" (no semantic change) * lib/fts.c (dirent_inode_sort_may_be_useful): Move definition "up" to precede upcoming use

Re: [bug #25294] assertion failure on dangling symlink to //

Eric Blake wrote: > According to Jim Meyering on 1/11/2009 3:06 PM: >> I tried your "find -L dir-containing-loop" example >> on ext3, tmpfs, and xfs, and it appears d_type is always DT_LNK, > > Is there any file system on Linux where you can always get DT_UNKNOW

Re: [bug #25294] assertion failure on dangling symlink to //

LINK(Errno) ((Errno) == ENOENT) #endif I checked a few Linux/GNU systems and found no ENOSHARE definition. I.e,. how about this patch? >From e5661c09cb915e2a3f24f9824be23ecd03fc Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Sun, 11 Jan 2009 22:57:37 +0100 Subject: [PATCH] fts: avoid

[PATCH 3/3] find: take advantage of new gnulib/fts leaf-optimization

t takes only 80 seconds (2.6.26, athlon64 3400+, 2yr-old disk), while using the latest unmodified find, at over 16 minutes, it takes 12 times as long. I'll post again when I have an fts patch implementing the approach outlined above. >From 5ca0d569635c801910c813a9f5c027759bafdf99 Mon Sep

[PATCH 2/3] find: avoid using undefined statbuf

* find/ftsfind.c (consider_visiting): Use local variable, mode, rather than possibly undefined statbuf.st_mode. --- Without this, and with some soon-to-be-posted changes to fts.c, find would read from the uninitialized statbuf.st_mode. But "mode" is already guaranteed to be set in the preceding co

[PATCH 1/3] fix a typo in a comment

* find/ftsfind.c (consider_visiting): s/fill/full/ --- find/ftsfind.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/find/ftsfind.c b/find/ftsfind.c index e505518..f14b2af 100644 --- a/find/ftsfind.c +++ b/find/ftsfind.c @@ -432,7 +432,7 @@ consider_visiting(FTS *p, FTS

[PATCH] avoid build failure when compiling with -DGNULIB_PORTCHECK

failure. >From df26314645bd992bbc1a97b9070f23bed3b8758c Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Fri, 26 Dec 2008 18:19:55 +0100 Subject: [PATCH] avoid build failure when compiling with -DGNULIB_PORTCHECK * find/parser.c (parse_time): #undef ctime. --- find/parser.c |4 1 files changed,

Re: [Patch] Add dirent.d_type support to Cygwin 1.7 ?

Jim Meyering <[EMAIL PROTECTED]> wrote: > Jim Meyering <[EMAIL PROTECTED]> wrote: >> "James Youngman" <[EMAIL PROTECTED]> wrote: >>> As far as I can see, the variable type is assigned in the function >>> above, but never used. Did you mean

Re: Fwd: [Patch] Add dirent.d_type support to Cygwin 1.7 ?

= false; // FIXME: depends on FTS_NOSTAT Here's the identical patch, but without that C++ style // FIXME comment. It was more a note to myself than anything. >From 317bfcc76c5b522a5cfa51ce5c0b256306a9e888 Mon Sep 17 00:00:00 2001 From: Jim Meyering <[EMAIL PROTECTED]> Date: Fri,

Re: [Patch] Add dirent.d_type support to Cygwin 1.7 ?

Jim Meyering <[EMAIL PROTECTED]> wrote: > "James Youngman" <[EMAIL PROTECTED]> wrote: >> As far as I can see, the variable type is assigned in the function >> above, but never used. Did you mean to use "type" rather than >> "dtype" i

Re: [Patch] Add dirent.d_type support to Cygwin 1.7 ?

variable. --- ChangeLog |4 lib/fts.c |2 +- 2 files changed, 5 insertions(+), 1 deletions(-) diff --git a/ChangeLog b/ChangeLog index 9a4ae1f..b6ce284 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,7 @@ +2008-11-29 James Youngman <[EMAIL PROTECTED]> + + * lib/fts.c

Re: [Patch] Add dirent.d_type support to Cygwin 1.7 ?

"James Youngman" <[EMAIL PROTECTED]> wrote: >> +static void >> +set_stat_type (struct stat *st, unsigned int dtype) >> +{ >> + mode_t type; >> + switch (dtype) >> +{ >> +case DT_BLK: >> + type = S_IFBLK; >> + break; >> +case DT_CHR: >> + type = S_IFCHR; >> + break;

Re: [Patch] Add dirent.d_type support to Cygwin 1.7 ?

"James Youngman" <[EMAIL PROTECTED]> wrote: > On Fri, Nov 28, 2008 at 7:19 PM, Jim Meyering <[EMAIL PROTECTED]> wrote: > > First, many thanks for looking at this! > > >> +/* Map the dirent.d_type value, DTYPE, to the corresponding stat.st_mode >>

Re: [Patch] Add dirent.d_type support to Cygwin 1.7 ?

s fts.c to expose the d_type information, and the second, in find, to use that newly-available data. Now, on a file system type e.g., ext3 or ext4, that provide usable dirent.d_type, a use like "find . -type d" will stat only the directories. Before, it would stat everything. I'll a

tiny typo fix

>From 9dbe9a747a2330a09d9fab04a39bb9c3de40fc19 Mon Sep 17 00:00:00 2001 From: Jim Meyering <[EMAIL PROTECTED]> Date: Thu, 25 Sep 2008 09:49:47 +0200 Subject: [PATCH] README-CVS: fix a tiny typo --- README-CVS |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/REA

Re: Why does -inum require stat(2)?

"George Spelvin" <[EMAIL PROTECTED]> wrote: > "James Youngman" <[EMAIL PROTECTED]> wrote: >> This is something that find has needed for quite a while. There is a >> somewhat more general problem too - the ftsfind program itself seems >> to stat files that fts() already stated, I think. >> >> Ther

[bug #23443] find regression: now fooled when crossing mountpoints

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

[bug #23443] find regression: now fooled when crossing mountpoints

Follow-up Comment #10, bug #23443 (project findutils): Hi James. Actually, yes. Whereas the gnulib-fts cycle checks only device and inode numbers (because that's all it needs to do on POSIX-conforming file system), some tools resort to comparing additional members of struct stat. For example di

Re: Empty tree in the git repo

"James Youngman" <[EMAIL PROTECTED]> wrote: > Judging from > http://git.savannah.gnu.org/gitweb/?p=findutils.git;a=tree;h=master;hb=master > it looks like Dmitry is right. Are we looking in the wrong place? I'm looking into it now. To start, I've regenerated from cvs, and things look good, thou

[PATCH] Fix doc typos.

Hi James, Here's a fix for two doc typos. ChangeLog |6 ++ doc/find-maint.texi |6 +++--- 2 files changed, 9 insertions(+), 3 deletions(-) diff --git a/ChangeLog b/ChangeLog index cdae6bf..7dcd73f 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,9 @@ +2008-03-08

Re: [bug #15384] find misbehaves when parent directory is not readable

"James Youngman" <[EMAIL PROTECTED]> wrote: > On 8/22/07, Eric Blake <[EMAIL PROTECTED]> wrote: >> At this point, since we are about to create a stable 4.4 branch where the >> fts()-based find works, do we still need to worry about the home-grown >> oldfind, which still has the bug? > > Yes, for th

Re: human interface change?!? [Re: xstrtol.h

Paul Eggert <[EMAIL PROTECTED]> wrote: > Jim Meyering <[EMAIL PROTECTED]> writes: > >> find's locate.c uses it, too. > > Thanks for mentioning that. Here's a patch for that, which I've > verified with 'make check' in findutils. It can b

Re: fts vs. simulated-inode file systems: FUSE-based, FAT, smbfs, cifs, ...

Jim Meyering <[EMAIL PROTECTED]> wrote: ... > Here's the patch (same as proposed, but with a comment), > followed by a patch to add a findutils test that exercises the bug. ... I didn't include ChangeLog entries for the new find test case. Here they are. BTW, without the p

Re: fts vs. simulated-inode file systems: FUSE-based, FAT, smbfs, cifs, ...

Jim Meyering <[EMAIL PROTECTED]> wrote: > Miklos Szeredi <[EMAIL PROTECTED]> wrote: >> I've tried out the CVS version of findutils+gnulib, and it does indeed >> seem to fix the problem with inode-less filesystems, in addition to >> using noticably less syste

Re: fts vs. simulated-inode file systems: FUSE-based, FAT, smbfs, cifs, ...

Miklos Szeredi <[EMAIL PROTECTED]> wrote: > I've tried out the CVS version of findutils+gnulib, and it does indeed > seem to fix the problem with inode-less filesystems, in addition to > using noticably less system time. > > I've also found that the -xdev option of find no longer works: it > output

Re: fts vs. simulated-inode file systems: FUSE-based, FAT, smbfs, cifs, ...

Miklos Szeredi <[EMAIL PROTECTED]> wrote: >> Separating the patch into parts wasn't really an option after all. >> I've checked this in: > > Looks great. Thanks. > > What's the easiest way to try this out? The patch doesn't apply to > the gnulib present in findutils-4.3.1, and I have no idea how

Re: fts vs. simulated-inode file systems: FUSE-based, FAT, smbfs, cifs, ...

du, chmod, chown, chgrp, > and via "make check" for find] > > FWIW, I plan to separate this into at least two separate patches > before checking it in. Separating the patch into parts wasn't really an option after all. I've checked this in: 2006-10-12 Jim Meyerin

fts vs. simulated-inode file systems: FUSE-based, FAT, smbfs, cifs, ...

, chown, chgrp, and via "make check" for find] FWIW, I plan to separate this into at least two separate patches before checking it in. 2006-10-11 Jim Meyering <[EMAIL PROTECTED]> * modules/fts (Depends-on): Add d-type. Alphabetize. * l

Re: Fwd: [bug #17877] Invalid "No such file or directory" error on filesystem without stable inode numbers

"James Youngman" <[EMAIL PROTECTED]> wrote: > On 10/4/06, Jim Meyering <[EMAIL PROTECTED]> wrote: > >> The resulting down side is that the old version of find is >> susceptible to a nasty type of attack when traversing a directory >> that is writable

Re: [bug #17877] Invalid "No such file or directory" error on filesystem without stable inode numbers

Eric Blake <[EMAIL PROTECTED]> wrote: ... >> > > For the gnulib crowd, a summary of the above link is that find 4.3.0, > which uses gnulib's fts, is sometimes reporting "No such file or > directory" in the middle of traversal on non-POSIX file systems such as

Re: filutils 4.1

"James Youngman" <[EMAIL PROTECTED]> wrote: > On 6/16/06, James Youngman <[EMAIL PROTECTED]> wrote: >> On 6/16/06, Paul Eggert <[EMAIL PROTECTED]> wrote: >> > Jim Meyering <[EMAIL PROTECTED]> writes: >> > >> > > find $P

xargs: exec's with too many arguments

'|xargs echo xargs: echo: Argument list too long [Exit 126] This is because Linux's execve implementation requires that the sum of the sizes of all argument string pointers not exceed 128K (the actual limit is ARG_MAX - sizeof (void*)). The difference between 32- and 64-bit systems is

patch for locate.c

type int: casebuf.soffs = &procdata.count; But that .soffs member is never used, so the fix is easy: remove it. 2005-09-01 Jim Meyering <[EMAIL PROTECTED]> * locate/locate.c (struct stringbuf) [soffs]: Remove unused member. (locate): Remove initialization, too.

typo in find.texi

Index: doc/find.texi === RCS file: /cvsroot/findutils/findutils/doc/find.texi,v retrieving revision 1.106 diff -u -p -r1.106 find.texi --- doc/find.texi 29 Jul 2005 22:04:07 - 1.106 +++ doc/find.texi 1 Sep 2005 16:

Re: Conversion of GNU find to use gnulib's fts interface

James Youngman <[EMAIL PROTECTED]> wrote: > I have made a CVS branch and modified findutils to use fts also. This Great! Thank you for doing that! I'll certainly switch to that version for my personal use. In working on coreutils, sometimes I've wanted to use find on pathologically deep hierarch

Re: -fprint F corrupts output, F, when stderr is closed

[EMAIL PROTECTED] (James Youngman) wrote: > On Fri, Jul 01, 2005 at 12:33:35PM +0200, Jim Meyering wrote: > >> Here's the patch: > > Thanks! > >> (assuming you get lib/stdio-safer.[ch] from coreutils -- >> I'll see about getting it into gnulib) >

complete patch for -fprint vs. closed stderr bug

e that it's fixed in the patched find: $ ./find no-such -fprint FF 2>&- || cat FF 2005-07-01 Jim Meyering <[EMAIL PROTECTED]> With `-fprint F' or `-fprintf F', don't write diagnostics to F when stderr is closed. * find/parser.c: Includ

-fprint F corrupts output, F, when stderr is closed

[ Sorry to report a bug to the list, but I dislike filling in web forms. If there were a mail-to-savannah-bug gateway I'd be happy to use it. ] When stderr is initially closed, find's `-fprint F' and `-fprintf F' predicates can corrupt their output file F with diagnostic output intended for t

Re: [patch #3741] Added support for Interix within mountlist.c

Paul Eggert <[EMAIL PROTECTED]> wrote: > Jim Meyering <[EMAIL PROTECTED]> writes: > >> +/* In the unlikely event that opendir and each readdir >> + succeed, but all statvfs calls fail, ensure that we >> + fail with a valid errno value.

Re: [patch #3741] Added support for Interix within mountlist.c

James Youngman <[EMAIL PROTECTED]> wrote: > I've received a patch for findutils from Darren R. Starr. The patch > adds support for Interix to the mountlist.c file. This file is > distributed with findutils, but is not present in the findutils CVS > code (insteead, findutils uses gnulib's CVS code