Re: race condition gnulib-tool's mostlyclean-local rule

Ralf Wildenhues <[EMAIL PROTECTED]> wrote: ... > IMVHO it's ugly (and resource-wasting) to have a $(MAKE) reinvocation > to paper over limitations in the extensibility of Automake-generated > Makefiles; the right fix would be to add dependency information > mostlyclean-local: mostlyclean-compile

FYI: chown: add missing dependent

2006-08-10 Jim Meyering <[EMAIL PROTECTED]> * modules/chown (Depends-on): Add stat-macros. Index: modules/chown === RCS file: /sources/gnulib/gnulib/modules/chown,v retrieving revision 1.6 diff -u -p -r1.6

FYI: new single-.h-file modules: dev-ino, same-inode

revision 1.600 diff -u -p -r1.600 ChangeLog --- ChangeLog 10 Aug 2006 13:30:55 - 1.600 +++ ChangeLog 10 Aug 2006 13:37:06 - @@ -1,5 +1,15 @@ 2006-08-10 Jim Meyering <[EMAIL PROTECTED]> + * modules/same-inode: New module. + * modules/dev-ino: New module. + * m

Re: FYI: new single-.h-file modules: dev-ino, same-inode

Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > m4/cycle-check.m4 does not exist in gnulib at the moment. Thanks, Ralf. I've just added it: * cycle-check.m4: New file. Require gl_STRUCT_DEV_INO and gl_SAME_INODE. --- #serial 3 dnl Copyright (C) 2005, 2006 Free Software

Re: please update FDL license version in standards.texi, make-stds.texi

[EMAIL PROTECTED] (Karl Berry) wrote: > Karl, can you please update the FDL license version iin standards.texi > and make-stds.texi? > > Strange, I have a strong memory of doing this once before. Oh well. > > Also, while you're at it there's some trailing > white space to remove.

FYI, coreutils-6.0 released

FYI, I've just released coreutils-6.0. Here's the announcement: http://article.gmane.org/gmane.comp.gnu.core-utils.bugs/7725

Re: coreutils 6.0

ies ($LIB_CLOCK_GETTIME) are needed by gethrxtime.c only if CLOCK_MONOTONIC is *not* defined. Here's the patch: 2006-08-18 Jim Meyering <[EMAIL PROTECTED]> * gethrxtime.m4 (gl_PREREQ_GETHRXTIME): Reverse sense of test for CLOCK_MONOTONIC. Otherwise, linking a geth

Re: coreutils 6.0

Jim Meyering <[EMAIL PROTECTED]> wrote: > "Gabor Z. Papp" <[EMAIL PROTECTED]> wrote: > ... >> Tried to compile coreutils 6.0 from alpha.gnu, and here is the result. > ... >> gcc -std=gnu99 -g -O2 -Wl,--as-needed -o dd dd.o ../lib/libcoreu

Re: coreutils 6.0 patch for gethrxtime.m4

Paul Eggert <[EMAIL PROTECTED]> wrote: > Thanks; I installed that patch into gnulib too, Thanks. > since I'm working on getting coreutils to use gnulib-tool. Great!

Re: gnulib changes to make it easier for coreutils to use gnulib-tool

Paul Eggert <[EMAIL PROTECTED]> wrote: > I am changing coreutils so that it will use gnulib-tool. As the first > part of this project I'm installing the following changes into gnulib. > I've tried to keep the changes "minimal", but that's a relative term > when talking about a change of this magni

FYI: check-module: add at-func.c to white-list

Checking openat produced this: $ cd modules && ../check-module openat check-module: ../lib/openat.c: duplicate inclusion of at-func.c check-module: ../lib/openat.c: duplicate inclusion of at-func.c So I fixed it: * check-module (find_included_lib_files): Add at-func.c to the

FYI: acl module missing dependencies

Running check-module on the "acl" module reported this: lib/acl.c: error.h is `#include'd, but not listed in module's Files: section lib/acl.c: quote.h is `#include'd, but not listed in module's Files: section So I added the missing dependencies: * modules/acl (Depends-on): Add error

getting past coreutils' "make distcheck"

"make distcheck" was failing due to three missing header files. These changes fixed it. 2006-08-22 Jim Meyering <[EMAIL PROTECTED]> * modules/mkdir-p (Makefile.am): Fix typo: s/lib+SOURCES/lib_SOURCES/. * modules/getpass-gnu (Makefile.am): Add getpass.h to EX

Re: coreutils-6.0 on BeOS (9)

Hi Bruno, Thanks for all of your recent BeOS porting work. We've received very few reports about BeOS problems, other than yours. I'm curious: what's your motivation for using it? Bruno Haible <[EMAIL PROTECTED]> wrote: ... > After producing this patch, I noticed that the replacement 'statfs' tha

fix typo in visibility.texi

FYI: * visibility.texi: Remove duplicate word: "pointer". Index: visibility.texi === RCS file: /sources/gnulib/gnulib/doc/visibility.texi,v retrieving revision 1.2 diff -u -r1.2 visibility.texi --- visibility.texi 14 Aug

Re: proposed gnulib module 'configmake', plus use by 'localcharset'

comment, and omit > the CONFIGMAKE_ prefix from generated macro names. Suggested > by Bruno Haible. Here's one more little change I've applied. Without it, rerunning coreutils' bootstrap and building would not update a stale copy of configmake.h, containing the

Re: proposed gnulib module 'configmake', plus use by 'localcharset'

Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > Hello Jim, > > * Jim Meyering wrote on Tue, Aug 29, 2006 at 05:52:02PM CEST: >> >> Here's one more little change I've applied. Without it, rerunning >> coreutils' bootstrap and building would not update

Re: [Bug 204567] New: base64 -d doesn't accept base64 output

In https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=204567, James Antill wrote: > Summary: base64 -d doesn't accept base64 output > > Description of problem: > base64 -d doesn't accept returns (which the base64 encoding should put > every 76 characters and at the end of the encoding). > > Ve

new shadowing warning in isapipe.c

Hi Paul, How about this, so coreutils' "make distcheck" passes once again? It avoids a warning from -Wshadow. 2006-08-30 Jim Meyering <[EMAIL PROTECTED]> * isapipe.c (isapipe): Rename local s/fd/fd_pair/ to avoid shadowing the parameter.

Re: coreutils-6.0 on platforms without fchdir

Paul Eggert <[EMAIL PROTECTED]> wrote: > Thanks for working on it, but I think we'd prefer a solution that > doesn't require the maintainer having to think about obsolete > platforms that lack fchdir. > > How about the following idea instead? On platforms lacking fchdir, > put a wrapper around 'op

ensure that generated files are read-only

one objects, I'll quickly revert the objectionable change. Bruno, would you mind if I changed the uses of "t-$@" to "[EMAIL PROTECTED]" in modules/localcharset? That minor inconsistency nearly made me miss the two rules in that file. 2006-09-06 Jim Meyering <[E

Re: ensure that generated files are read-only

Paul Eggert <[EMAIL PROTECTED]> wrote: > Jim Meyering <[EMAIL PROTECTED]> writes: > >> alloca.h: alloca_.h >> rm -f [EMAIL PROTECTED] $@ >> cp $(srcdir)/alloca_.h [EMAIL PROTECTED] >> chmod a-x [EMAIL PROTECTED] >> mv [EMAIL

Re: ensure that generated files are read-only

Paul Eggert <[EMAIL PROTECTED]> wrote: > Jim Meyering <[EMAIL PROTECTED]> writes: > >> alloca.h: alloca_.h >> rm -f [EMAIL PROTECTED] $@ >> cp $(srcdir)/alloca_.h [EMAIL PROTECTED] >> chmod a-x [EMAIL PROTECTED] >> mv [EMAIL PROT

Re: ensure that generated files are read-only

Bruce Korb <[EMAIL PROTECTED]> wrote: > Bruno Haible wrote: >> Jim Meyering wrote: >> >>>I learned long enough ago that >>>files like Makefile, Makefile.in, configure, etc. are generated, >>>so that their being writable isn't a big deal. But

Re: ensure that generated files are read-only

Bruno Haible <[EMAIL PROTECTED]> wrote: > Jim Meyering wrote: >> I've always taken the stand that >> generated files should be read-only, and this is just another >> reason to follow that policy. > > I'm vehemently opposed to such a change. On the contrar

Re: ensure that generated files are read-only

Paul Eggert <[EMAIL PROTECTED]> wrote: > Jim Meyering <[EMAIL PROTECTED]> writes: >> If it's really a major annoyance, you should switch to >> an editor that lets you circumvent such things more easily. >> In Emacs, C-xC-q is the typical binding to toggle read

bootstrap: marking gnulib-copied/generated files as such

I've just made this change. It doesn't handle bourne shell scripts or ABOUT-NLS, but it's enough for now. 2006-09-08 Jim Meyering <[EMAIL PROTECTED]> * bootstrap (cp_mark_as_generated): New function. (slurp): Use it to prepend editor hints and a warning

Re: bootstrap: marking gnulib-copied/generated files as such

Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > Hello Jim, > > * Jim Meyering wrote on Fri, Sep 08, 2006 at 08:54:50AM CEST: >> --- bootstrap7 Sep 2006 21:00:58 - 1.8 >> +++ bootstrap8 Sep 2006 06:48:43 - >> @@ -212

Re: bootstrap: marking gnulib-copied/generated files as such

Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > Hello Jim, > > * Jim Meyering wrote on Fri, Sep 08, 2006 at 09:44:31AM CEST: >> Ralf Wildenhues <[EMAIL PROTECTED]> wrote: >> > >> > Just FYI: this bootstrap script will not work any more with som

Re: ensure that generated files are read-only

Paul Eggert <[EMAIL PROTECTED]> wrote: > Jim Meyering <[EMAIL PROTECTED]> writes: > >> alloca.h: alloca_.h >> rm -f [EMAIL PROTECTED] $@ >> cp $(srcdir)/alloca_.h [EMAIL PROTECTED] >> chmod a-x [EMAIL PROTECTED] >> mv [EMAIL PROT

Re: bootstrap: marking gnulib-copied/generated files as such

"Mark D. Baushke" <[EMAIL PROTECTED]> wrote: > Jim Meyering <[EMAIL PROTECTED]> writes: > >> case $CVS_RSH in >> '') export CVS_RSH=ssh;; >> esac > > One of the following would be better, given that not all shells &g

Re: [bug #17643] Include sys/param.h when testing whether getmntinfo() fills struct statvfs.

eBSD needs sys/param.h too be included too. I guess that Darwin systems > are also affected but I cannot test . Please, > apply the attached patch or similiar. Thank you for the fine report and patch. I've applied it, in the gnulib project, since that's where coreutils gets

nanosleep.c vs. NetBSD 6.0's

or: parse error before '}' token make[2]: *** [nanosleep.o] Error 1 2006-09-12 Jim Meyering <[EMAIL PROTECTED]> * nanosleep.c: Include before sys/select.h, to avoid compilation failure (due to use of pid_t in latter) on NetBSD 1.6. Reported by

Re: ensure that generated files are read-only

Bruno Haible <[EMAIL PROTECTED]> wrote: > Jim Meyering wrote: >> > 2) For the user who needs to fix a compilation problem, or do minor >> >developments in a package. >> > >> >In this case I _do_ want to change the Makefile or config.h, to

Re: ensure that generated files are read-only

Paul Eggert <[EMAIL PROTECTED]> wrote: > Jim Meyering <[EMAIL PROTECTED]> writes: > >> I'm surprised that the compromise of adding advisory comments rubs >> you (Bruno) so hard the wrong way. Does anyone else object to >> adding both lines? > > I&

FYI: rename macro renamed

AME +gl_FUNC_RENAME Makefile.am: @@ -22,4 +22,3 @@ Maintainer: Jim Meyering - Index: m4/rename.m4 === RCS file: /sources/gnulib/gnulib/m4/rename.m4,v retrieving revision 1.12 diff -u -r1.12 rename.m4 --- m4/rename.m424 Apr 2006 07

Re: ensure that generated files are read-only

Paul Eggert <[EMAIL PROTECTED]> wrote: > Jim Meyering <[EMAIL PROTECTED]> writes: > >> aren't the warning and possible annoyance at least a little more >> appropriate for the build-generated files whose rules I was proposing >> to change in gnulib? > &

Re: bug fix: mv and 'cp -r' no longer fail when ...

on: +rename() function: change the name or location of a file. + +Files: +lib/rename-dest-slash.c +m4/rename-dest-slash.m4 + +Depends-on: +xalloc +dirname + +configure.ac: +gl_FUNC_RENAME_TRAILING_DEST_SLASH + +Makefile.am: + +Include: + + +License: +GPL + +Maintainer: +Jim Meyering Index: MODU

FYI: regex_internal.c: avoid a warning

Since this file is already different from libc, this shouldn't hurt... 2006-09-15 Jim Meyering <[EMAIL PROTECTED]> Avoid a warning about an unused variable. * regex_internal.c (re_dfa_add_node): Move declaration of "type" into the #ifdef block wh

Re: bug fix: mv and 'cp -r' no longer fail when ...

Bruno Haible <[EMAIL PROTECTED]> wrote: > Jim Meyering wrote: ... > then shouldn't the first test be this? > > if (len <= FILE_SYSTEM_PREFIX_LEN (file) + 1) >return false; Yes, that is better: more efficient on non-POSIX systems. Thanks. >> + { &

Re: new module savewd, plus changes to mkdir-p

Hi Ralf, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > * Paul Eggert wrote on Sat, Sep 16, 2006 at 10:00:27PM CEST: >> I installed this fix as part of updates to coreutils. > > The file modules/savewd does not exist in the current CVS, neither > do lib/savewd.[ch], m4/savewd.m4. I suspect he'll ad

FYI: savewd.c: avoid shadowing warning

This fixes a "make distcheck" failure in coreutils: * savewd.c (savewd_restore): Don't shadow: s/status/child_status/. Index: savewd.c === RCS file: /sources/gnulib/gnulib/lib/savewd.c,v retrieving revision 1.1 diff -u -r1.1

Re: 2G tmpfile of sort

Paul Eggert <[EMAIL PROTECTED]> wrote: > Eric Blake <[EMAIL PROTECTED]> writes: > >> Thanks for the report. Which platform, which compiler, and which version >> of coreutils was this? If it is still present in coreutils 6.2, we would >> like to get it fixed before 6.3. > > Yes, likewise. > > Look

Re: unused variables and other nits in gnulib/m4

Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > Hello Simon, Jim, Paul, Bruno, all, > > OK to apply these patches to make > ./configure CC='gcc -Wall -Werror -fno-builtin' > > work better (tested on GNU/Linux) with these tests? > (Mind you, I haven't tested any of these changes on other systems.) H

Re: some missing module dependencies

Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > Hello Jim, Paul, all, > > Is this patch ok, or would you rather factor out clock_time.m4 into its > own module (as it is listed by 3 modules already)? > > * modules/fts-lgpl: Depend on openat. > * modules/mkancesdirs: Depend on savewd. >

vc-dwim 0.2: a version-control-agnostic ChangeLog diff and commit tool

Hello, I've written a little tool that has saved me some typing and trouble. It's called vc-dwim, as in "do what I mean", and helps manage version- controlled working directories. You can get a tarball here: http://et.redhat.com/~meyering/vc-dwim-0.2.tar.gz Or check out the latest: hg clone

Re: vc-dwim 0.2: a version-control-agnostic ChangeLog diff and commit tool

Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > Hello Jim, > * Jim Meyering wrote on Fri, Sep 22, 2006 at 09:58:26AM CEST: Hi Ralf, Thanks for the quick and voluminous feedback! >> hg clone http://hg.et.redhat.com/hg/emd/applications/vc-dwim >> >> If you know of

Re: vc-dwim 0.2: a version-control-agnostic ChangeLog diff and commit tool

Thanks for persevering :) I'll address your other points later, probably tomorrow. Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > In a gnulib CVS checkout (with modifications), I get: > > $ vc-dwim ChangeLog > | vc-dwim: ChangeLog: no unidiff output Does ChangeLog have changes, i.e., does "cvs diff

Re: getloadavg and LIBOBJDIR

Bruno Haible <[EMAIL PROTECTED]> wrote: > There were no objections in 4 days, so I applied this patch. Hi Bruno, Four days wasn't long enough, especially, since I'm hoping to make a "stable" coreutils release soon. >> 2006-09-17 Bruno Haible <[EMAIL PROTECTED]> >> >> * gnulib-tool (func_i

Re: vc-dwim 0.2: a version-control-agnostic ChangeLog diff and commit tool

Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > * Jim Meyering wrote on Fri, Sep 22, 2006 at 04:28:27PM CEST: >> Ralf Wildenhues <[EMAIL PROTECTED]> wrote: >> >> > ... I can't get it to build. Even after I updated by `hg' tool to the >> > late

Re: getloadavg and LIBOBJDIR

Jim Meyering <[EMAIL PROTECTED]> wrote: ... > That change breaks coreutils' configure. > It happens because of this assignment in configure: > > gl_source_base='.#bootmp/lib' > > When configure is run, .#bootmp/lib no longer exists, so the > check for ex

ls-mntd-fs.m4 bug fix

c: "conftest.c", line 310: error 1563: Expression in if must be scalar. I've made this change: 2006-09-24 Jim Meyering <[EMAIL PROTECTED]> * ls-mntd-fs.m4 (gl_LIST_MOUNTED_FILE_SYSTEMS): Don't use '>' to compare a pointer against a liter

FYI: typo fix for fcntl_h.m4

The intent is to exit nonzero if open-nofollow succeeds on a symlink, not only in the highly unlikely (probably impossible, in a configure script) event it returns FD 0. 2006-09-25 Jim Meyering <[EMAIL PROTECTED]> * fcntl_h.m4 (gl_FCNTL_H): Fix typo in test for faile

Re: coreutils-6.2: various runtime problems on Darwin-8.7.0 HFS+ (including attachment this time)

<[EMAIL PROTECTED]> wrote: > I am new to this list, but not at all new to building and using > open source projects. (Please CC me if needed as I haven't yet > joined this list. Or I think I can access and post via > news.gmane.org with regular newsreaders.) > > I built coreutils-6.2 on Darwin-8.

Re: Fix chdir-long.m4 caching

Ralf Wildenhues <[EMAIL PROTECTED]> wrote: >> 7 checking whether this system has an arbitrary file name length >> limit... yes > > OK to apply this patch? I think this variable isn't used elsewhere in > gnulib nor coreutils, so renaming this shouldn't be a problem. > > * chdir-long.m4

Re: coreutils-6.2: various runtime problems on Darwin-8.7.0 HFS+ (including attachment this time)

mwoehlke <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] wrote: >> [let me see if gmane lets me reply to posts] > > gmane works great, it's the only way I read this list (and several > others). :-) > > btw, thanks for the mails... I just built coreutils on Darwin also, and > had a good number of 'ma

acl.m4: patch required to work around Darwin 8.7.0 bug

With this change, coreutils (bootstrapped from CVS) passes "make check" on Darwin 8.7.0. In case you missed it, details are here: http://article.gmane.org/gmane.comp.gnu.core-utils.bugs/8263 2006-09-26 Jim Meyering <[EMAIL PROTECTED]> * acl.m4 (AC_FUNC_ACL): Dis

Re: coreutils-6.2: various runtime problems on Darwin-8.7.0 HFS+ (including attachment this time)

mwoehlke <[EMAIL PROTECTED]> wrote: > Jim Meyering wrote: >> mwoehlke <[EMAIL PROTECTED]> wrote: >>> [EMAIL PROTECTED] wrote: >>>> [let me see if gmane lets me reply to posts] >>> gmane works great, it's the only way I read this list (and se

Re: coreutils-6.2: various runtime problems on Darwin-8.7.0 HFS+ (including attachment this time)

of > the GNU General Public License <http://www.gnu.org/licenses/gpl.html>. > There is NO WARRANTY, to the extent permitted by law. > > Written by Paul Rubin, David MacKenzie, Richard Stallman, and Jim Meyering. > $ ls coreutils-5.97 > ls: coreutils-5.97: No such file or

Re: coreutils-6.2: various runtime problems on Darwin-8.7.0 HFS+ (including attachment this time)

mwoehlke <[EMAIL PROTECTED]> wrote: > $ uname -srvmpio > Darwin 8.6.1 Darwin Kernel Version 8.6.1: Tue Mar 7 16:55:45 PST 2006; > root:xnu-792.9.22.obj~1/RELEASE_I386 i386 i386 iMac4,1 Darwin > > Ah, but it's also a much newer Darwin... so... > >> I'm working on building test output (including ver

Re: Darwin HFS+ bug

Bruno Haible <[EMAIL PROTECTED]> wrote: > mwoehlke wrote: >> I am also noticing that >> after making coreutils (and some other packages, I think bash was one), >> to remove the directory, I have to 'rm -rf coreutils-5.97' as many as >> four times before it fully goes away. Odd that just doing it s

Re: vc-dwim 0.2: a version-control-agnostic ChangeLog diff and commit tool

ne changes yet. > > FWIW, it would be really nice to see the changes from 0.2.1 also in the > hg tree (I prefer a vcs-ed upstream when providing feedback). Maybe I don't understand what you're saying. There haven't been any changes since 0.2.1, other than this one, which I&#x

Re: coreutils-6.2: various runtime problems on Darwin-8.7.0 HFS+ (including attachment this time)

mwoehlke <[EMAIL PROTECTED]> wrote: >> Would you please try this, to confirm the theory: >> #!/bin/bash >> for i in $(seq 150 200); do >> echo i=$i >> mkdir b; (cd b; mkdir $(seq $i) ); Rm -r b || { echo bug at i=$i; break; } >> done >> That should find the minimum number of entries for which r

Re: coreutils-6.2: various runtime problems on Darwin-8.7.0 HFS+ (including attachment this time)

mwoehlke <[EMAIL PROTECTED]> wrote: > Have you considered making this conditional to broken Darwin versions? :-) Yes. For a long time, there was an autoconf-run-test to determine the limit, but that is insufficient, since it's hard to test all file systems that are available at build time, and im

Re: now getting a build error with coreutils-cvs (Re: coreutils-6.2: various runtime problems on Darwin-8.7.0 HFS+ (including attachment this time))

<[EMAIL PROTECTED]> wrote: > On 2006-09-25 17:25:01 -0500, <[EMAIL PROTECTED]> said: > >> I will pull coreutils and gnulib from CVS also and report back. > > Okay I got a fresh clean copy of coreutils+gnulib, ran ./bootstrap, > complained only a tiny bit about the hu language (smth about 2 or more

Re: now getting a build error with coreutils-cvs (Re: coreutils-6.2: various runtime problems on Darwin-8.7.0 HFS+ (including attachment this time))

<[EMAIL PROTECTED]> wrote: > On 2006-09-26 17:04:24 -0500, <[EMAIL PROTECTED]> said: > >> On 2006-09-25 17:25:01 -0500, <[EMAIL PROTECTED]> said: >> >>> I will pull coreutils and gnulib from CVS also and report back. >> Okay I got a fresh clean copy of coreutils+gnulib, ran ./bootstrap, >> complai

Re: coreutils 6.2

"Gabor Z. Papp" <[EMAIL PROTECTED]> wrote: ... > gcc -std=gnu99 -g -O2 -Wl,--as-needed -o cp cp.o copy.o cp-hash.o > ../lib/libcoreutils.a ../lib/libcoreutils.a > ../lib/libcoreutils.a(xstrndup.o): In function `xstrndup': > /home/gzp/src/coreutils-6.2/lib/xstrndup.c:37: undefined reference to

Re: coreutils-6.2: various runtime problems on Darwin-8.7.0 HFS+ (including attachment this time)

Bruno Haible <[EMAIL PROTECTED]> wrote: > Jim Meyering wrote: >> I'll use 180. >> The lower we go, the more of a performance penalty >> we impose for directories with very many entries. > > I tried the value 180. It worked fine in some cases, but still fail

Re: coreutils-6.2: various runtime problems on Darwin-8.7.0 HFS+ (including attachment this time)

Jim Meyering <[EMAIL PROTECTED]> wrote: > Bruno Haible <[EMAIL PROTECTED]> wrote: >> Jim Meyering wrote: >>> I'll use 180. >>> The lower we go, the more of a performance penalty >>> we impose for directories with very many entries. >>

Re: coreutils-6.2: various runtime problems on Darwin-8.7.0 HFS+ (including attachment this time)

Bruno Haible <[EMAIL PROTECTED]> wrote: > Jim Meyering wrote: >> I'll use 180. >> The lower we go, the more of a performance penalty >> we impose for directories with very many entries. > > I tried the value 180. It worked fine in some cases, but still fai

FYI: strndup portability fix [was Re: coreutils 6.2

Jim Meyering <[EMAIL PROTECTED]> wrote: > "Gabor Z. Papp" <[EMAIL PROTECTED]> wrote: > ... >> gcc -std=gnu99 -g -O2 -Wl,--as-needed -o cp cp.o copy.o cp-hash.o >> ../lib/libcoreutils.a ../lib/libcoreutils.a >> ../lib/libcoreutils.a(xstrndu

FYI: tiny change in mkdir-p.c

FYI, I noticed that mkdir-p.c includes dirchownmod.c, rather than dirchownmod.h. I think that must have been unintentional, since it leads to warnings from ranlib on some systems. Once changed, I found that it also needs , for its close prototype. Here's the patch: 2006-09-28 Jim Mey

Re: coreutils-6.2: various runtime problems on Darwin-8.7.0 HFS+ (including attachment this time)

Bruno Haible <[EMAIL PROTECTED]> wrote: > Hello Jim, > >> Is there any type of file system where readdir works? > > Yes. It does work on vfat file systems. No readdir bug reproducible there. Thanks for checking. >> What version of Darwin are you using? > > Darwin 7.9.0 = MacOS X 10.3.9. > > I wro

FYI: coreutils/lib once again has automatically-generated dependencies

de an option to suppress them. At the very least, it should provide an option to reenable dependencies if its default remains as it is. The following change fixes things via coreutils' bootstrap script: 2006-09-28 Jim Meyering <[EMAIL PROTECTED]> Automatically generated

GNU rm now works around Darwin 0.7.9 (MaxOS X 10.3.9) readdir bug

gure" on a buggy system, the build directory must not be on a file system of type vfat; there, the configure-time test would not detect the bug. But I don't think that's a problem, since all of the systems I know about use only NFS and hfs. If it proves to be a problem, I'll

Re: proposed change to closeout module

Bruno Haible <[EMAIL PROTECTED]> wrote: > Hi Paul and Jim, > > The closeout module currently ignores write failures on stderr. > This patch makes it report failures on stderr through an exit status. Hi Bruno, I like the idea, but I've never worried about this case on the principle that if a progr

Re: proposed change to close-stream module

Bruno Haible <[EMAIL PROTECTED]> wrote: > Hi Paul and Jim, > > It bothers me that in order to implement a basic functionality like the > 'closeout' module, you need the __fpending module, which is not based on > POSIX but rather a case-by-case hack for various platforms. > > Here is a proposed patc

Re: GNU rm now works around Darwin 0.7.9 (MaxOS X 10.3.9) readdir bug

Bruno Haible <[EMAIL PROTECTED]> wrote: > Hi Jim, > > The Darwin HFS+ bug is even reproducible on Linux, on NFS mounts from a > Darwin 10.3.9 machine. Here is that same directory, of which Darwin's > readdir() bug occurred after 178 removals. Here it occurs already after > 13 removals on average:

really fixed, this time [Re: GNU rm now works around Darwin 0.7.9 (MaxOS X 10.3.9) readdir bug

I hope this is the final iteration for a while. Thanks to Bruno for helping to get this done right. 2006-09-29 Jim Meyering <[EMAIL PROTECTED]> Since any system may be affected by the Darwin readdir bug, perform the extra rewinddir unconditionally. The perfo

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: FYI: coreutils/lib once again has automatically-generated dependencies

Bruno Haible <[EMAIL PROTECTED]> wrote: > I'm applying this. > 2006-10-02 Bruno Haible <[EMAIL PROTECTED]> > > * gnulib-tool (func_emit_lib_Makefile_am): Don't add no-dependencies > to the AUTOMAKE_OPTIONS. Thanks. With that, I've just reverted the work-around in coreutils' bootstrap

Re: [PATCH] io/fts.c: Remove redundant checks

"Dmitry V. Levin" <[EMAIL PROTECTED]> wrote: > 2006-10-02 Dmitry V. Levin <[EMAIL PROTECTED]> > > * io/fts.c (fts_close, fts_build, fts_palloc): Remove redundant > checks. Thank you. I've applied those changes to the version of fts.c in gnulib, too. If you have applications that use

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

[I'm moving the discussion to the bug-gnulib mailing list, since this concerns the gnulib fts module. ] "James Youngman" <[EMAIL PROTECTED]> wrote: > For your info. Hi James, Thanks for forwarding that. I confess I hadn't looked at the original bug report. Just did, and see that it's a differe

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: Fwd: [bug #17877] Invalid "No such file or directory" error on filesystem without stable inode numbers

Miklos Szeredi <[EMAIL PROTECTED]> wrote: >> Thanks for forwarding that. >> I confess I hadn't looked at the original bug report. >> Just did, and see that it's a different problem than I first thought. >> I now see that this is about the dev/ino check when traversing "up" >> to return to a previou

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

Miklos Szeredi <[EMAIL PROTECTED]> wrote: ... >> Are you saying that with your FUSE patch, the above is to be expected? >> Meaning, the inode numbers are expected to differ, even if nothing >> happens to "/mnt/fuse/tmp/test" during the "..." period? > > No, what I'm saying that some filesystem can

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

Miklos Szeredi <[EMAIL PROTECTED]> wrote: >> > This one should work, since the file descriptor in the working >> > directory should prevent the inode from going away. Or is there >> > something I'm missing? >> >> We like to have a way of searching a directory hierarchy 10 levels >> deep withou

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

Miklos Szeredi <[EMAIL PROTECTED]> wrote: >> I suspect that it is possible, and maybe even feasible, to work around >> this violation of fundamental assumptions in some limited cases. >> However, in general, I think it's not possible, or at least not >> worth the effort. >> >> In spite of that, I h

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

Miklos Szeredi <[EMAIL PROTECTED]> wrote: >> For example, consider the classic symlink attack. >> We're not supposed to follow symlinks and our system lacks support >> for open's O_NOFOLLOW flag. So we lstat the target directory, >> determine that it is indeed a directory, then open it. But betwe

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

Miklos Szeredi <[EMAIL PROTECTED]> wrote: >> >> For example, consider the classic symlink attack. >> >> We're not supposed to follow symlinks and our system lacks support >> >> for open's O_NOFOLLOW flag. So we lstat the target directory, >> >> determine that it is indeed a directory, then open it

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

Miklos Szeredi <[EMAIL PROTECTED]> wrote: >> > But what about symlinks? >> > >> > a g >> >b h->a >> > c >> > f->g >> > >> > The moment you traverse the f->g symlink above, >> > the entire tree, a/b/c/f, is no longer referenced, >> > so the h->a link may take you back to

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

Miklos Szeredi <[EMAIL PROTECTED]> wrote: >> > Shouldn't holding the current directory open prevent the ancestor from >> > changing inodes in this case? >> >> No. >> What's changed is the identity (dev/inode) of the parent directory, >> once you try to chdir("..") "up" beyond the renamed directory.

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

Miklos Szeredi <[EMAIL PROTECTED]> wrote: >> > In which case the check is not >> > needed (if O_NOFOLLOW is also available). >> >> Unfortunately, we can't yet afford to target only systems with >> open/O_NOFOLLOW support, and we do care about security on other systems. > > I think you misunderstand

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

Miklos Szeredi <[EMAIL PROTECTED]> wrote: ... >> What you're saying here is inconsistent with the strace snippet you posted >> showing the offending lstat and open with almost no intervening syscalls. >> Perhaps you edited it and forgot to indicate that? > > No I didn't edit. You're right, that my

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

Miklos Szeredi <[EMAIL PROTECTED]> wrote: >> That's close. >> To clarify: with the current fts implementation, the interval between the >> initial lstat and subsequent open of the same directory may be arbitrarily >> long, but only for 2nd or subsequent command-line arguments -- which >> usually t

Re: proposed change to closeout module

Eric Blake <[EMAIL PROTECTED]> wrote: > According to Paul Eggert on 9/29/2006 11:38 AM: >> >> I like the basic idea. As I understand it this affects only programs >> that issue "warnings" (i.e., they output to stderr but then continue >> without affecting the exit status) but it's useful for that

fix inadvertent change to modules/inttypes

Bruno, I'm sure you didn't mean to substitute s,|,/, in modules/inttypes. That change makes builds fail on any system for which ABSOLUTE_INTTYPES_H is nonempty. 2006-10-07 Jim Meyering <[EMAIL PROTECTED]> * modules/inttypes (inttypes.h): Revert what seems to have

Re: one ChangeLog for gnulib, or many?

Paul Eggert <[EMAIL PROTECTED]> wrote: > Bruno Haible <[EMAIL PROTECTED]> writes: > >> I took the liberty of moving this ChangeLog entry to m4/ChangeLog and >> lib/ChangeLog, respectively. > > I'd prefer having just one ChangeLog for all of gnulib, since it's > easier to follow changes that affect

minor bug in fts cycle-detection code

I found what appears to be a probabilistically harmless bug in fts-related code. By that, I mean the odds of the bug resulting in a malfunction (false-positive cycle detection) would seem to be very small. I've checked in this fix: 2006-10-09 Jim Meyering <[EMAIL PROTECTED]>

Re: changelogs merged in gnulib

Bruno Haible <[EMAIL PROTECTED]> wrote: > Paul Eggert wrote: >> I merged all the gnulib ChangeLog files into one ChangeLog, at the >> top. > > And I redid the line breaking, to fit in 80 columns (actually 79 columns > where possible). That change also removed all "(tiny change)" annotations. Here

<    1   2   3   4   5   6   7   8   9   10   >