Re: [bug #17900] rm -f should ignore ENOTDIR
Eric Blake [EMAIL PROTECTED] writes: Shouldn't this also include ELOOP? With ELOOP, we don't know whether the file exists. It could merely be a symlink chain that's too long. So it's safer for rm to print a diagnostic. This is in contrast with ENOTDIR, where we know for sure that the file does not exist. The POSIX spec is a bit weird here; it says to print a diagnostic if the file does not exist. But suppose we lack permission to search the directory D, and the file D/F exists. Should rm -f D/F report a diagnostic? There's no way for rm to tell that D/F exists here, so there's no way to implement the POSIX spec as written. In this particular case GNU rm is cautious and prints a diagnostic; Solaris rm is lackadaisical and doesn't. I'd prefer GNU rm to be more cautious in this area, so I think it should print a diagnostic for ELOOP, as well as for EACCES. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [bug #17903] cp/mv only read/write 512 byte blocks when filesystem blksize 4MB
Tony Ernst [EMAIL PROTECTED] writes: XFS filesystems can have legitimate st_blksize values that greatly exceed 4MB. Thanks for reporting this. What is the largest legitimate st_blksize value that XFS file systems can have? We can simply increase the value to that limit. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [bug #17900] rm -f should ignore ENOTDIR
Jim Meyering [EMAIL PROTECTED] wrote: It should also include ENAMETOOLONG: $ rm -rf /t/$(printf %0257 1)/x 2 /dev/null || echo bug bug Whoops. Two problems above: most people don't have a /t directory. and printf needs a format character: $ rm -rf $(printf %0257d 1)/x 2 /dev/null || echo bug bug ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [bug #17900] rm -f should ignore ENOTDIR
Paul Eggert [EMAIL PROTECTED] wrote: I'd prefer GNU rm to be more cautious in this area, so I think it should print a diagnostic for ELOOP, as well as for EACCES. I agree. Good catch. Thanks. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
chown --no-dereference broken in coreutils 6.3 ?
Hi,
I just downloaded coreutils-6.3 and the testsuite fails in chown/basic:
# make TESTS=basic VERBOSE=yes check
+ chgrp --version
+ . ./../envvar-check
++ as_unset=unset
++ envvar_check_failed=0
++ vars='
_POSIX2_VERSION
BLOCKSIZE
BLOCK_SIZE
CDPATH
COLUMNS
DF_BLOCK_SIZE
DU_BLOCK_SIZE
LS_BLOCK_SIZE
LS_COLORS
POSIXLY_CORRECT
QUOTING_STYLE
SIMPLE_BACKUP_SUFFIX
TABSIZE
TERM
TIME_STYLE
TMPDIR
VERSION_CONTROL
'
++ for var in '$vars'
++ unset _POSIX2_VERSION
++ eval test '${_POSIX2_VERSION+set}'FAIL: basic
==
1 of 1 tests failed
Please report to bug-coreutils@gnu.org
==
make[1]: Leaving directory `/usr/src/RPM/BUILD/coreutils-6.3/tests/chown'
t
++ for var in '$vars'
++ unset CDPATH
++ eval test '${CDPATH+set}' = set
+++ test '' = set
++ for var in '$vars'
++ unset COLUMNS
++ eval test '${COLUMNS+set}' = set
+++ test '' = set
++ for var in '$vars'
++ unset DF_BLOCK_SIZE
++ eval test '${DF_BLOCK_SIZE+set}' = set
+++ test '' = set
++ for var in '$vars'
++ unset DU_BLOCK_SIZE
++ eval test '${DU_BLOCK_SIZE+set}' = set
+++ test '' = set
++ for var in '$vars'
++ unset LS_BLOCK_SIZE
++ eval test '${LS_BLOCK_SIZE+set}' = set
+++ test '' = set
++ for var in '$vars'
++ unset LS_COLORS
++ eval test '${LS_COLORS+set}' = set
+++ test '' = set
++ for var in '$vars'
++ unset POSIXLY_CORRECT
++ eval test '${POSIXLY_CORRECT+set}' = set
+++ test '' = set
++ for var in '$vars'
++ unset QUOTING_STYLE
++ eval test '${QUOTING_STYLE+set}' = set
+++ test '' = set
++ for var in '$vars'
++ unset SIMPLE_BACKUP_SUFFIX
++ eval test '${SIMPLE_BACKUP_SUFFIX+set}' = set
+++ test '' = set
++ for var in '$vars'
++ unset TABSIZE
++ eval test '${TABSIZE+set}' = set
+++ test '' = set
++ for var in '$vars'
++ unset TERM
++ eval test '${TERM+set}' = set
+++ test '' = set
++ for var in '$vars'
++ unset TIME_STYLE
++ eval test '${TIME_STYLE+set}' = set
+++ test '' = set
++ for var in '$vars'
++ unset TMPDIR
++ eval test '${TMPDIR+set}' = set
+++ test '' = set
++ for var in '$vars'
++ unset VERSION_CONTROL
++ eval test '${VERSION_CONTROL+set}' = set
+++ test '' = set
++ test '' = 1
+ . ./../lang-default
++ LC_ALL=C
++ export LC_ALL
++ unset LANGUAGE NLSPATH
++ unset LANG LC_COLLATE LC_CTYPE LC_MESSAGES LC_MONETARY LC_NUMERIC LC_TIME
+ PRIV_CHECK_ARG=require-root
+ . ./../priv-check
++ case $PRIV_CHECK_ARG in
++ who='as root'
+++ id -u
++ my_uid=0
++ test 0 = 0
++ case $my_uid in
++ test 0 = 0
++ : nobody
+++ id -u nobody
++ coreutils_non_root_uid=65534
++ test 0 = 0
++ test 65534 = 0
++ give_msg=no
++ case $PRIV_CHECK_ARG:$my_uid in
++ test no = yes
++ pwd
+ pwd=/usr/src/RPM/BUILD/coreutils-6.3/tests/chown
+ tmp=basic.12764
+ trap 'status=$?; cd $pwd; rm -rf $tmp exit $status' 0
+ trap '(exit $?); exit' 1 2 13 15
+ framework_failure=0
+ mkdir basic.12764
+ cd basic.12764
+ touch f
+ test 0 = 1
+ fail=0
+ chown -R --preserve-root 0:1 f
++ ls -n f
+ set _ -rw-r--r-- 1 0 1 0 Oct 3 12:08 f
+ shift
+ test 0:1 = 0:1
+ chown --from=0:1 2:010 f
++ ls -n f
+ set _ -rw-r--r-- 1 2 10 0 Oct 3 12:08 f
+ shift
+ test 2:10 = 2:10
+ ln -s f slink
+ chown --no-dereference 0:1 slink
++ ls -n slink
+ set _ lrwxrwxrwx 1 0 0 1 Oct 3 12:08 slink '-' f
+ shift
+ test 0:0 = 0:1
+ fail=1
++ ls -n f
+ set _ -rw-r--r-- 1 0 1 0 Oct 3 12:08 f
+ shift
+ test 0:1 = 2:10
+ fail=1
+ chown --no-dereference --from=0:1 2:010 slink
++ ls -n slink
+ set _ lrwxrwxrwx 1 0 0 1 Oct 3 12:08 slink '-' f
+ shift
+ test 0:0 = 2:10
+ fail=1
+ exit 1
+ exit 1
+ status=1
+ cd /usr/src/RPM/BUILD/coreutils-6.3/tests/chown
+ rm -rf basic.12764
+ exit 1
make[1]: *** [check-TESTS] Error 1
make: *** [check-am] Error 2
I verified by hand that chown --no-dereference 6.3 does not work, while
the one from coreutils-5.97 is fine. My system is a linux-2.6.17 system
with glibc-2.4.
Please CC any answers, because MTA madness on my ISP does not allow me to
subscribe (again) to the list.
Regards,
Theodoros Kalamatianos
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: coreutils-6.3: spurious stat_dtype failure
Michael Deutschmann [EMAIL PROTECTED] wrote: When testing coreutils-6.3, I observed a make check failure which I have judged to be spurious. Thank you for the report. The test was ls/stat_dtype, which verifies that `ls' is using the dirent.d_type feature -- which is not provided by all kernels and filesystems. While the test does try to skip systems that don't support it, it assumes the feature is available on all ext2 filesystems. This is not so. I'm not surprised. I was counting on someone like you to tell me how to perform the check reliably :-) In my case, I'm using the lightweight Linux 2.0.40 kernel, which doesn't support that feature for any filesystem type. Also, I understand that even on a cutting edge kernel, the feature will not be available if the given ext2 filesystem was originally formatted for compatibility to old kernels. Can you point to documentation supporting that? For now, I'll skip the test for linux-2.0.x ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [bug #17900] rm -f should ignore ENOTDIR
Here's the patch I've checked in:
[but there's one small remaining patch coming right up...]
2006-10-03 Jim Meyering [EMAIL PROTECTED]
With --force (-f), rm no longer fails for ENOTDIR.
* src/remove.c (ignorable_missing): New function.
Use it everywhere, rather than open-coding the test.
Andreas Schwab reported the ENOTDIR problem.
(ignorable_missing): Similarly, don't fail for ENAMETOOLONG.
* NEWS: Mention the bug fix.
* tests/rm/ignorable: New file. Test for the ENOTDIR case.
* tests/rm/ignore-name-too-long: New file. Test for ENAMETOOLONG.
* tests/rm/Makefile.am (TESTS): Add the new file names.
Index: src/remove.c
===
RCS file: /fetish/cu/src/remove.c,v
retrieving revision 1.162
diff -u -r1.162 remove.c
--- src/remove.c29 Sep 2006 15:58:05 - 1.162
+++ src/remove.c3 Oct 2006 10:37:01 -
@@ -899,7 +899,7 @@
return RM_OK; \
} \
\
- if (errno == ENOENT (X)-ignore_missing_files)
\
+ if (ignorable_missing (X, errno))
\
return RM_OK; \
} \
while (0)
@@ -915,7 +915,7 @@
return RM_OK; \
} \
\
- if (errno == ENOENT (X)-ignore_missing_files)\
+ if (ignorable_missing (X, errno))\
return RM_OK; \
\
if (errno == ENOTEMPTY || errno == EEXIST) \
@@ -923,6 +923,32 @@
} \
while (0)
+/* When a function like unlink, rmdir, or fstatat fails with an errno
+ value of ERRNUM, return true if the specified file system object
+ is guaranteed not to exist; otherwise, return false. */
+static inline bool
+nonexistent_file_errno (int errnum)
+{
+ /* Do not include ELOOP here, since the specified file may indeed
+ exist, but be (in)accessible only via too long a symlink chain. */
+ switch (errnum)
+{
+case ENAMETOOLONG:
+case ENOENT:
+case ENOTDIR:
+ return true;
+default:
+ return false;
+}
+}
+
+/* Encapsulate the test for whether the errno value, ERRNUM, is ignorable. */
+static inline bool
+ignorable_missing (struct rm_options const *x, int errnum)
+{
+ return x-ignore_missing_files nonexistent_file_errno (errnum);
+}
+
/* Remove the file or directory specified by FILENAME.
Return RM_OK if it is removed, and RM_ERROR or RM_USER_DECLINED if not.
But if FILENAME specifies a non-empty directory, return RM_NONEMPTY_DIR. */
@@ -1014,7 +1040,7 @@
{
if (fstatat (fd_cwd, filename, st, AT_SYMLINK_NOFOLLOW))
{
- if (errno == ENOENT x-ignore_missing_files)
+ if (ignorable_missing (x, errno))
return RM_OK;
error (0, errno, _(cannot remove %s),
@@ -1195,7 +1221,7 @@
/* CAUTION: this test and diagnostic are identical to
those following the other use of fd_to_subdirp. */
- if (errno == ENOENT x-ignore_missing_files)
+ if (ignorable_missing (x, errno))
{
/* With -f, don't report file not found. */
}
@@ -1281,7 +1307,7 @@
{
/* CAUTION: this test and diagnostic are identical to
those following the other use of fd_to_subdirp. */
- if (errno == ENOENT x-ignore_missing_files)
+ if (ignorable_missing (x, errno))
{
/* With -f, don't report file not found. */
}
@@ -1426,7 +1452,7 @@
{
if (cache_fstatat (AT_FDCWD, filename, st, AT_SYMLINK_NOFOLLOW) != 0)
{
- if (errno == ENOENT x-ignore_missing_files)
+ if (ignorable_missing (x, errno))
return RM_OK;
error (0, errno, _(cannot remove %s), quote (filename));
return RM_ERROR;
Index: NEWS
===
RCS file: /fetish/cu/NEWS,v
retrieving revision 1.436
diff -u -r1.436 NEWS
--- NEWS2 Oct 2006 11:47:48 - 1.436
+++ NEWS3 Oct 2006 10:36:19 -
@@ -2,6 +2,12 @@
* Major changes in release 6.4-cvs (2006-??-??) [?]
+** Bug fixes
+
+ With --force (-f), rm no longer fails for ENOTDIR or ENAMETOOLONG.
+ For example, rm -f existing-non-directory/anything now exits
+ successfully,
Re: chown --no-dereference broken in coreutils 6.3 ?
On Tue, 3 Oct 2006, Jim Meyering wrote: Theodoros V. Kalamatianos [EMAIL PROTECTED] wrote: I just downloaded coreutils-6.3 and the testsuite fails in chown/basic: ... make[1]: Leaving directory `/usr/src/RPM/BUILD/coreutils-6.3/tests/chown' ... ++ ls -n slink + set _ lrwxrwxrwx 1 0 0 1 Oct 3 12:08 slink '-' f + shift + test 0:0 = 0:1 + fail=1 Thank you for reporting that. This is not a bug in the coreutils. Rather, you may be using a buggy version of glibc. I reported a month ago that the underlying problem affects Ubuntu/edgy's version of glibc 2.4: Yet another glibc bug I stumbled on... seems to be happening a lot lately... Subject: fchownat ignores AT_SYMLINK_NOFOLLOW flag https://lists.ubuntu.com/archives/ubuntu-users/2006-September/093218.html https://launchpad.net/distros/ubuntu/+source/glibc/+bug/59083 Status: Unconfirmed Importance: Undecided(!) I verified by hand that chown --no-dereference 6.3 does not work, while the one from coreutils-5.97 is fine. My system is a linux-2.6.17 system with glibc-2.4. Please specify _which_ glibc-2.4 and linux-2.6.17, if you didn't build them from pristine sources. Both were built from vanilla sources. glibc was slightly patched to fix some nscd issues and an irritating gconv bug - nothing that would affect one of the chown functions AFAICT. FYI, this doesn't affect upstream glibc, since the tests have passed on rawhide with both 2.6.17 and 2.6.18. So glibc-2.5 does not have this issue ? If so then I'll try updating to that one... Thanks for the fast reply, Theodoros Kalamatianos ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: coreutils-6.3: c89 patch insufficent
Michael Deutschmann [EMAIL PROTECTED] wrote: coreutils-6.3 includes a patch, c99-to-c89.diff, to allow it to be compiled on platforms that don't support declarations after statements. However, this patch is not sufficent -- I had to fix two other areas to get coreutils to compile under GCC 2.95.3. I've appended my fixes. They are to be applied after the existing c99-to-c89.diff. Thank you. I've applied those. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [bug #17900] rm -f should ignore ENOTDIR
Jim Meyering [EMAIL PROTECTED] writes: It should also include ENAMETOOLONG: Actually, isn't ENAMETOOLONG in the same category as ELOOP? That is, ENAMETOOLONG sometimes indicates the file isn't there, but sometimes not. For example, rm -f ./././././././.../foo (where the ... stands for lots of ./s) will fail due to ENAMETOOLONG, even though the named file actually does exist. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [bug #17903] cp/mv only read/write 512 byte blocks when filesystem blksize 4MB
Why not simply cap the size at 4 MB? If it is greater than 4 MB just go with 4 MB instead of 512 bytes. In fact, you might even want to cap it at less than 4 MB, say 1 MB or 512 KB. I think you will find that any size larger than the 32-128 kb range yields no further performance increase and can even be detrimental due to the increased memory pressure. Tony Ernst wrote: Hi Paul, Unfortunately, there isn't really a largest legitimate st_blksize for XFS file systems, or I should say the maximum is whatever fits into a size_t (64 bits). It's dependent on the stripe width. I talked with an XFS developer who told me that 2GB is not out of the question today. Now there is also the question of whether or not we really want cp/mv allocating a 2GB buffer, but that's a different issue (and a site with that kind of disk set-up probably also has plenty of memory). Since the 4MB check was to fix a specific problem on hpux, it seems like that check should occur inside the # if defined hpux ... section. At the very least, since the bogus value returned by hpux is such an strange number, maybe we could just change: (statbuf).st_blksize = (1 22)) /* 4MB */ \ to: (statbuf).st_blksize != 2147421096) \ I would be very surprised if 2147421096 was ever a valid st_blksize on any system/filesystem. It's not a power of 2, or even a multiple of 128, 512, etc. % factor 2147421096 2147421096: 2 2 2 3 3 17 37 47417 Thanks, Tony ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: coreutils-6.3: install: basic-1 fails
Bauke Jan Douma [EMAIL PROTECTED] writes: cp: cannot open `/sw/coreutils/coreutils-6.3/tests/install/../../src/dd' for reading: What are the permissions of that file? That is, what is the output of this command: ls -l /sw/coreutils/coreutils-6.3/tests/install/../../src/dd If dd itself is unreadable, can you figure out how that happened? ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: make check failure on Itanium HPUX
mwoehlke [EMAIL PROTECTED] wrote:
mwoehlke wrote:
This is a little odd... 'make' exits non-zero when doing 'make
check' (help-version) on Itanium Linux, but the tests all seem to
pass. Here is the relevant verbose output:
[snip]
...and similarly on HPUX, although the tests pass, 'make check' just
*fails*, and in this case I'm not seeing why. I'm attaching the log in
case anyone spots something I didn't. (Maybe it's the same problem?)
Same versions of bash and make here (both built from clean sources).
...
This bit looks like the cause:
(do you have /usr/bin/posix in your shell's search path?)
t=ls-files.$$; \
(cd . ls -1 *.x) | sed 's/\.x$//' | LC_ALL=C sort $t;\
echo base64.1 basename.1 cat.1 chgrp.1 chmod.1 chown.1 chroot.1 cksum.1
comm.1 cp.1 csplit.1 cut.1 date.1 dd.1 df.1 dir.1 dircolors.1 dirname.1 du.1
echo.1 env.1 expand.1 expr.1 factor.1 false.1 fmt.1 fold.1 groups.1 head.1
hostid.1 hostname.1 id.1 install.1 join.1 kill.1 link.1 ln.1 logname.1 ls.1
md5sum.1 mkdir.1 mkfifo.1 mknod.1 mv.1 nice.1 nl.1 nohup.1 od.1 paste.1
pathchk.1 pinky.1 pr.1 printenv.1 printf.1 ptx.1 pwd.1 readlink.1 rm.1
rmdir.1 seq.1 sha1sum.1 sha224sum.1 sha256sum.1 sha384sum.1 sha512sum.1
shred.1 shuf.1 sleep.1 sort.1 split.1 stat.1 stty.1 su.1 sum.1 sync.1 tac.1
tail.1 tee.1 test.1 touch.1 tr.1 true.1 tsort.1 tty.1 uname.1 unexpand.1
uniq.1 unlink.1 uptime.1 users.1 vdir.1 wc.1 who.1 whoami.1 yes.1 | tr -s ' '
'\n' | sed 's/\.1$//' \
| LC_ALL=C sort | diff - $t || { rm $t; exit 1; };\
rm $t
/usr/bin/posix/sh[5]: 12357 Memory fault(coredump)
make[2]: *** [check-x-vs-1] Error 1
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: make check failure on Itanium HPUX
Jim Meyering wrote:
mwoehlke [EMAIL PROTECTED] wrote:
mwoehlke wrote:
This is a little odd... 'make' exits non-zero when doing 'make
check' (help-version) on Itanium Linux, but the tests all seem to
pass. Here is the relevant verbose output:
[snip]
...and similarly on HPUX, although the tests pass, 'make check' just
*fails*, and in this case I'm not seeing why. I'm attaching the log in
case anyone spots something I didn't. (Maybe it's the same problem?)
This bit looks like the cause:
t=ls-files.$$; \
(cd . ls -1 *.x) | sed 's/\.x$//' | LC_ALL=C sort $t;\
echo base64.1 basename.1 cat.1 chgrp.1 chmod.1 chown.1 chroot.1 cksum.1
comm.1 cp.1 csplit.1 cut.1 date.1 dd.1 df.1 dir.1 dircolors.1 dirname.1 du.1
echo.1 env.1 expand.1 expr.1 factor.1 false.1 fmt.1 fold.1 groups.1 head.1
hostid.1 hostname.1 id.1 install.1 join.1 kill.1 link.1 ln.1 logname.1 ls.1
md5sum.1 mkdir.1 mkfifo.1 mknod.1 mv.1 nice.1 nl.1 nohup.1 od.1 paste.1
pathchk.1 pinky.1 pr.1 printenv.1 printf.1 ptx.1 pwd.1 readlink.1 rm.1 rmdir.1
seq.1 sha1sum.1 sha224sum.1 sha256sum.1 sha384sum.1 sha512sum.1 shred.1 shuf.1
sleep.1 sort.1 split.1 stat.1 stty.1 su.1 sum.1 sync.1 tac.1 tail.1 tee.1
test.1 touch.1 tr.1 true.1 tsort.1 tty.1 uname.1 unexpand.1 uniq.1 unlink.1
uptime.1 users.1 vdir.1 wc.1 who.1 whoami.1 yes.1 | tr -s ' ' '\n' | sed
's/\.1$//' \
| LC_ALL=C sort | diff - $t || { rm $t; exit 1; };\
rm $t
/usr/bin/posix/sh[5]: 12357 Memory fault(coredump)
make[2]: *** [check-x-vs-1] Error 1
Yup, it does; didn't spot that. But...
(do you have /usr/bin/posix in your shell's search path?)
...no I don't.
$ which -a sh
/usr/bin/sh
$ ll /usr/bin/sh
-r-xr-xr-x 2 bin bin 544232 Aug 8 2002 /usr/bin/sh
So unless this is some weird HPUX thing I'm not sure where
/usr/bin/posix/sh came from. Anyway, to me that looks like a fluke since
'make check' shouldn't be doing anything in 'man', yes? IOW this one can
be safely ignored?
--
Matthew
I don't question your existence -- God (seen on a church billboard)
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [bug #17900] rm -f should ignore ENOTDIR
Paul Eggert [EMAIL PROTECTED] wrote: Jim Meyering [EMAIL PROTECTED] writes: It should also include ENAMETOOLONG: Actually, isn't ENAMETOOLONG in the same category as ELOOP? That is, ENAMETOOLONG sometimes indicates the file isn't there, but sometimes not. For example, rm -f ./././././././.../foo (where the ... stands for lots of ./s) will fail due to ENAMETOOLONG, even though the named file actually does exist. Oh! You're right. I was under the impression that ENAMETOOLONG was only for FILENAME_MAX. But I see now that it's also for PATH_MAX. Thanks. I'll remove that part of my change. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [bug #17903] cp/mv only read/write 512 byte blocks when filesystem blksize 4MB
Tony Ernst wrote: I believe the larger block sizes are especially beneficial with RAID. I'm adding Geoffrey Wehrman to the CC list, as he understands disk I/O much better than I do. I believe most kernels always performs the actual IO in the same size chunks due to the block layer and cache, even if user space passes down a large buffer. The exception to this on Linux would be when you use O_DIRECT IO, then using buffer sizes at least as large as the stripe width is definitely good for keeping all the disks spinning. In any case, the raid case falls under the pervue of the kernel buffer cache read-ahead mechanism, and is beyond the scope of coreutils. From the perspective of coreutils, using a larger buffer size has the benefit of reducing the number of system calls needed, but causes more memory to be locked down. As such you need to have some kind of limit on the size of the buffer so you don't try to exhaust system memory. On the other hand, in a way it is up to the kernel to provide a reasonable value for the block size knowing full well that applications that use that value use it as a guide to the IO buffer size to use. In that case I suspect that XFS really should not be setting that value to many megabytes. I don't think a cap is really necessary. This test and arbitrary limitation were put in to work around a specific problem on hpux. But it has side-effects that reach beyond hpux and the original problem. So the test should either be limited to hpux-only, or fixed to get rid of the side-effects by making it more specific to the original problem. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [bug #17900] rm -f should ignore ENOTDIR
Paul Eggert [EMAIL PROTECTED] wrote:
Actually, isn't ENAMETOOLONG in the same category as ELOOP? That is,
ENAMETOOLONG sometimes indicates the file isn't there, but sometimes
not. For example,
FYI, I've committed this:
2006-10-04 Jim Meyering [EMAIL PROTECTED]
* src/remove.c (nonexistent_file_errno): Remove ENAMETOOLONG.
Paul Eggert pointed out that the specified file may exist,
in spite of such an errno value.
* tests/rm/Makefile.am (TESTS): Remove ignore-name-too-long.
* tests/rm/ignore-name-too-long: Remove file.
* NEWS: Update here, too.
Index: src/remove.c
===
RCS file: /fetish/cu/src/remove.c,v
retrieving revision 1.164
diff -u -r1.164 remove.c
--- src/remove.c3 Oct 2006 13:32:56 - 1.164
+++ src/remove.c3 Oct 2006 21:57:32 -
@@ -930,10 +930,13 @@
nonexistent_file_errno (int errnum)
{
/* Do not include ELOOP here, since the specified file may indeed
- exist, but be (in)accessible only via too long a symlink chain. */
+ exist, but be (in)accessible only via too long a symlink chain.
+ Likewise for ENAMETOOLONG, since rm -f ./././.../foo may fail
+ if the ... part expands to a long enough sequence of ./s,
+ even though ./foo does indeed exist. */
+
switch (errnum)
{
-case ENAMETOOLONG:
case ENOENT:
case ENOTDIR:
return true;
Index: tests/rm/Makefile.am
===
RCS file: /fetish/cu/tests/rm/Makefile.am,v
retrieving revision 1.39
diff -u -r1.39 Makefile.am
--- tests/rm/Makefile.am3 Oct 2006 13:13:09 - 1.39
+++ tests/rm/Makefile.am3 Oct 2006 22:05:26 -
@@ -21,7 +21,6 @@
AUTOMAKE_OPTIONS = 1.1 gnits
TESTS = \
- ignore-name-too-long \
ignorable \
readdir-bug \
empty-inacc \
Index: tests/rm/ignore-name-too-long
===
RCS file: tests/rm/ignore-name-too-long
diff -N tests/rm/ignore-name-too-long
--- tests/rm/ignore-name-too-long 3 Oct 2006 13:13:09 - 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,48 +0,0 @@
-#!/bin/sh
-# Ensure that rm -f name_longer_than_FILENAME_MAX exits successfully
-
-# Copyright (C) 2006 Free Software Foundation, Inc.
-
-# This program is free software; you can redistribute it and/or modify
-# it under the terms of the GNU General Public License as published by
-# the Free Software Foundation; either version 2 of the License, or
-# (at your option) any later version.
-
-# This program is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-# GNU General Public License for more details.
-
-# You should have received a copy of the GNU General Public License
-# along with this program; if not, write to the Free Software
-# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
-# 02110-1301, USA.
-
-if test $VERBOSE = yes; then
- set -x
- rm --version
-fi
-
-PRIV_CHECK_ARG=require-non-root . $srcdir/../priv-check
-
-pwd=`pwd`
-t0=`echo $0|sed 's,.*/,,'`.tmp; tmp=$t0/$$
-trap 'status=$?; cd $pwd; chmod -R u+rwx $t0; rm -rf $t0 exit $status' 0
-trap '(exit $?); exit $?' 1 2 13 15
-
-framework_failure=0
-mkdir -p $tmp || framework_failure=1
-cd $tmp || framework_failure=1
-
-if test $framework_failure = 1; then
- echo $0: failure in testing framework 12
- (exit 1); exit 1
-fi
-
-fail=0
-
-# With coreutils-6.3, this would exit nonzero. It should not.
-long_name=$(printf %0513d 0)
-rm -f $long_name out 21 || fail=1
-
-(exit $fail); exit $fail
* NEWS: Update here, too.
Index: NEWS
===
RCS file: /fetish/cu/NEWS,v
retrieving revision 1.437
diff -u -r1.437 NEWS
--- NEWS3 Oct 2006 13:13:09 - 1.437
+++ NEWS3 Oct 2006 22:07:09 -
@@ -4,7 +4,7 @@
** Bug fixes
- With --force (-f), rm no longer fails for ENOTDIR or ENAMETOOLONG.
+ With --force (-f), rm no longer fails for ENOTDIR.
For example, rm -f existing-non-directory/anything now exits
successfully, ignoring the error about a nonexistent file.
/fetish/cu/ChangeLog,v -- ChangeLog
new revision: 1.2004; previous revision: 1.2003
/fetish/cu/NEWS,v -- NEWS
new revision: 1.438; previous revision: 1.437
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: make check failure on Itanium HPUX
mwoehlke [EMAIL PROTECTED] writes:
Jim Meyering wrote:
mwoehlke [EMAIL PROTECTED] wrote:
mwoehlke wrote:
This is a little odd... 'make' exits non-zero when doing 'make
check' (help-version) on Itanium Linux, but the tests all seem to
pass. Here is the relevant verbose output:
[snip]
...and similarly on HPUX, although the tests pass, 'make check' just
*fails*, and in this case I'm not seeing why. I'm attaching the log in
case anyone spots something I didn't. (Maybe it's the same problem?)
This bit looks like the cause:
t=ls-files.$$; \
(cd . ls -1 *.x) | sed 's/\.x$//' | LC_ALL=C sort $t;\
echo base64.1 basename.1 cat.1 chgrp.1 chmod.1 chown.1 chroot.1 cksum.1
comm.1 cp.1 csplit.1 cut.1 date.1 dd.1 df.1 dir.1 dircolors.1 dirname.1
du.1 echo.1 env.1 expand.1 expr.1 factor.1 false.1 fmt.1 fold.1 groups.1
head.1 hostid.1 hostname.1 id.1 install.1 join.1 kill.1 link.1 ln.1
logname.1 ls.1 md5sum.1 mkdir.1 mkfifo.1 mknod.1 mv.1 nice.1 nl.1 nohup.1
od.1 paste.1 pathchk.1 pinky.1 pr.1 printenv.1 printf.1 ptx.1 pwd.1
readlink.1 rm.1 rmdir.1 seq.1 sha1sum.1 sha224sum.1 sha256sum.1 sha384sum.1
sha512sum.1 shred.1 shuf.1 sleep.1 sort.1 split.1 stat.1 stty.1 su.1 sum.1
sync.1 tac.1 tail.1 tee.1 test.1 touch.1 tr.1 true.1 tsort.1 tty.1 uname.1
unexpand.1 uniq.1 unlink.1 uptime.1 users.1 vdir.1 wc.1 who.1 whoami.1
yes.1 | tr -s ' ' '\n' | sed 's/\.1$//' \
| LC_ALL=C sort | diff - $t || { rm $t; exit 1; };\
rm $t
/usr/bin/posix/sh[5]: 12357 Memory fault(coredump)
make[2]: *** [check-x-vs-1] Error 1
Yup, it does; didn't spot that. But...
(do you have /usr/bin/posix in your shell's search path?)
...no I don't.
I'd guess it's pulled in because 'configure' tries /usr/posix/bin/sh.
Anyway, to me that looks like a fluke
since 'make check' shouldn't be doing anything in 'man', yes?
'make check' does the equivalent of 'make', so it does things
in 'man'. And so it's not a fluke; it's a real problem of
some sort with your /usr/posix/bin/sh implementation.
Can you reproduce the problem by hand? For example, does the
following shell script dump core for you, when you execute it in your
man directory?
#! /bin/sh
/usr/posix/bin/sh -c 'PATH=../src:$PATH; export PATH; \
t=ls-files.$$; \
(cd . ls -1 *.x) | sed '\''s/\.x$//'\'' | LC_ALL=C sort $t;\
echo base64.1 basename.1 cat.1 chgrp.1 chmod.1 chown.1 chroot.1 cksum.1
comm.1 cp.1 csplit.1 cut.1 date.1 dd.1 df.1 dir.1 dircolors.1 dirname.1 du.1
echo.1 env.1 expand.1 expr.1 factor.1 false.1 fmt.1 fold.1 groups.1 head.1
hostid.1 hostname.1 id.1 install.1 join.1 kill.1 link.1 ln.1 logname.1 ls.1
md5sum.1 mkdir.1 mkfifo.1 mknod.1 mv.1 nice.1 nl.1 nohup.1 od.1 paste.1
pathchk.1 pinky.1 pr.1 printenv.1 printf.1 ptx.1 pwd.1 readlink.1 rm.1 rmdir.1
seq.1 sha1sum.1 sha224sum.1 sha256sum.1 sha384sum.1 sha512sum.1 shred.1 shuf.1
sleep.1 sort.1 split.1 stat.1 stty.1 su.1 sum.1 sync.1 tac.1 tail.1 tee.1
test.1 touch.1 tr.1 true.1 tsort.1 tty.1 uname.1 unexpand.1 uniq.1 unlink.1
uptime.1 users.1 vdir.1 wc.1 who.1 whoami.1 yes.1 | tr -s '\'' '\'' '\''\n'\''
| sed '\''s/\.1$//'\'' \
| LC_ALL=C sort | diff - $t || { rm $t; exit 1; };\
rm $t'
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: coreutils-6.3: install: basic-1 fails
Jim Meyering wrote: Bauke Jan Douma [EMAIL PROTECTED] wrote: Paul Eggert wrote: Bauke Jan Douma [EMAIL PROTECTED] writes: cp: cannot open `/sw/coreutils/coreutils-6.3/tests/install/../../src/dd' for reading: What are the permissions of that file? That is, what is the output of this command: ls -l /sw/coreutils/coreutils-6.3/tests/install/../../src/dd $ ls -l /sw/coreutils/coreutils-6.3/tests/install/../../src/dd -rwx--x--x 1 root staff 45532 Oct 3 18:06 /sw/coreutils/coreutils-6.3/tests/install/../../src/dd That file is readable only by root. So if you're running tests as some other user, that would explain the failure you saw. Yes, I am running the tests as root, but apparently the basic-1 test re-runs itself as user nobody (65534), which explains the failure. Presently though that doesn't explain, to me at least, why 'require-non-root' is a show-stopper when I'm running the make check as root initially. bj ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [bug #17903] cp/mv only read/write 512 byte blocks when filesystem blksize 4MB
Tony Ernst [EMAIL PROTECTED] writes: (statbuf).st_blksize != 2147421096) \ I doubt whether the HP-UX bug always results in exactly that number. Phillip Susi [EMAIL PROTECTED] writes: In that case I suspect that XFS really should not be setting that value to many megabytes. As I understand it, XFS will let a sysadmin put pretty much whatever number they like into st_blksize, regardless of the underyling I/O configuration, I guess under the theory that the sysadmin is always right. The GNU philosophy is to avoid arbitrary limits, so I installed the following patch, in an attempt to do a minimal sort of sanity check (catching the HP-UX bug, I hope) while not overly constraining st_blksize. 2006-10-03 Paul Eggert [EMAIL PROTECTED] * src/system.h (ST_BLKSIZE): Ceiling at SIZE_MAX / 8 + 1, not at 4 MiB, since XFS hosts can legitimately have large values of st_blksize. Problem reported by Tony Ernst in http://savannah.gnu.org/bugs/?17903. --- src/system.h3 Sep 2006 02:53:37 - 1.160 +++ src/system.h3 Oct 2006 22:10:15 - @@ -206,11 +206,14 @@ /* Some systems, like Sequents, return st_blksize of 0 on pipes. Also, when running `rsh hpux11-system cat any-file', cat would determine that the output stream had an st_blksize of 2147421096. - So here we arbitrarily limit the `optimal' block size to 4MB. - If anyone knows of a system for which the legitimate value for - st_blksize can exceed 4MB, please report it as a bug in this code. */ + Conversely st_blksize can be 2 GiB (or maybe even larger) with XFS + on 64-bit hosts. Somewhat arbitrarily, limit the `optimal' block + size to SIZE_MAX / 8 + 1. (Dividing SIZE_MAX by only 4 wouldn't + suffice, since cat sometimes multiplies the result by 4.) If + anyone knows of a system for which this limit is too small, please + report it as a bug in this code. */ # define ST_BLKSIZE(statbuf) ((0 (statbuf).st_blksize \ - (statbuf).st_blksize = (1 22)) /* 4MB */ \ + (statbuf).st_blksize = SIZE_MAX / 8 + 1) \ ? (statbuf).st_blksize : DEV_BSIZE) # if defined hpux || defined __hpux__ || defined __hpux /* HP-UX counts st_blocks in 1024-byte units. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
coreutils 6.3 on Tru64 - just plain broken, or...?
...is anyone else trying to build on Tru64? I'm using 4.0G to build, and I have a LOT of problems. For starters, things went badly until I removed the #define for intmax_t from config.h. shuf builds, but the linker complains about 'ftello unresolved', and then *produces a file* (but without +x), with the result that 'make' then thinks it has nothing to do to for target 'shuf' and continues on to success if re-run. 'make check' bombed because it failed to find perl (despite it being in my path the whole time), although it looks like my perl may be broken (didn't find strict.pm after I forcibly pointed the Makefile's at it). Building perl is not going to happen; after an hour trying to get the POS Configure to run I gave up and deleted it with extreme prejudice. Instead I ran the 'make check' on a 5.1 box, and then got memory faults all over the place (log attached; I also have the full verbose run, but it's ~45kb bzip2'd). So... has anyone else tried Tru64? -- Matthew I don't question your existence -- God (seen on a church billboard) *** NOTICE: Some tests may be run only as root. Do `make check-root' as `root' to run these tests. *** Making check in chgrp make[1]: Entering directory `/home/install/gnu/src/coreutils-6.3/tests/chgrp' make check-TESTS make[2]: Entering directory `/home/install/gnu/src/coreutils-6.3/tests/chgrp' ./no-x: this test requires that you be a member of more than one group, but running `id -G' either failed or found just one. If you really are a member of at least two groups, then rerun this test with COREUTILS_GROUPS set in your environment to the space-separated list of group names or numbers. E.g., env COREUTILS_GROUPS='users cdrom' make check SKIP: no-x ./posix-H: this test requires that you be a member of more than one group, but running `id -G' either failed or found just one. If you really are a member of at least two groups, then rerun this test with COREUTILS_GROUPS set in your environment to the space-separated list of group names or numbers. E.g., env COREUTILS_GROUPS='users cdrom' make check SKIP: posix-H ./basic: this test requires that you be a member of more than one group, but running `id -G' either failed or found just one. If you really are a member of at least two groups, then rerun this test with COREUTILS_GROUPS set in your environment to the space-separated list of group names or numbers. E.g., env COREUTILS_GROUPS='users cdrom' make check SKIP: basic ./deref: this test requires that you be a member of more than one group, but running `id -G' either failed or found just one. If you really are a member of at least two groups, then rerun this test with COREUTILS_GROUPS set in your environment to the space-separated list of group names or numbers. E.g., env COREUTILS_GROUPS='users cdrom' make check SKIP: deref ./recurse: this test requires that you be a member of more than one group, but running `id -G' either failed or found just one. If you really are a member of at least two groups, then rerun this test with COREUTILS_GROUPS set in your environment to the space-separated list of group names or numbers. E.g., env COREUTILS_GROUPS='users cdrom' make check SKIP: recurse == All 0 tests passed (5 tests were not run) == make[2]: Leaving directory `/home/install/gnu/src/coreutils-6.3/tests/chgrp' make[1]: Leaving directory `/home/install/gnu/src/coreutils-6.3/tests/chgrp' Making check in chmod make[1]: Entering directory `/home/install/gnu/src/coreutils-6.3/tests/chmod' make check-TESTS make[2]: Entering directory `/home/install/gnu/src/coreutils-6.3/tests/chmod' PASS: inaccessible PASS: c-option PASS: equal-x PASS: equals PASS: no-x PASS: octal PASS: setgid PASS: umask-x PASS: usage == All 9 tests passed == make[2]: Leaving directory `/home/install/gnu/src/coreutils-6.3/tests/chmod' make[1]: Leaving directory `/home/install/gnu/src/coreutils-6.3/tests/chmod' Making check in chown make[1]: Entering directory `/home/install/gnu/src/coreutils-6.3/tests/chown' make check-TESTS make[2]: Entering directory `/home/install/gnu/src/coreutils-6.3/tests/chown' *** NOTICE: ./basic: This test is being skipped, since it works only when run as root. *** SKIP: basic PASS: deref PASS: separator == All 2 tests passed (1 tests were not run) == make[2]: Leaving directory `/home/install/gnu/src/coreutils-6.3/tests/chown' make[1]: Leaving directory `/home/install/gnu/src/coreutils-6.3/tests/chown' Making check in cp make[1]: Entering directory `/home/install/gnu/src/coreutils-6.3/tests/cp' make check-TESTS make[2]: Entering directory `/home/install/gnu/src/coreutils-6.3/tests/cp' PASS: src-base-dot ./sparse: 343414 Memory fault ./sparse: 343422 Memory fault
[bug #17908] 'configure' fails because it is unable to determine how to read the mount table.
URL: http://savannah.gnu.org/bugs/?17908 Summary: 'configure' fails because it is unable to determine how to read the mount table. Project: GNU Core Utilities Submitted by: woehlkmp Submitted on: Wednesday 10/04/2006 at 00:43 Category: None Severity: 3 - Normal Item Group: None Status: None Privacy: Public Assigned to: None Open/Closed: Open ___ Details: This happens on at least NSK(OSS) and Interix, and there is a FIXME about it. Instead of failing, 'configure' should disable targets (e.g. 'df') that need to read the mount table, perhaps with a big warning message. Tested with coreutils-6.3 ___ Reply to this item at: http://savannah.gnu.org/bugs/?17908 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: make check failure on Itanium Linux
mwoehlke wrote: This is a little odd... 'make' exits non-zero when doing 'make check' (help-version) on Itanium Linux, but the tests all seem to pass. Ack, nope, scratch that, there were real failures in there too... grep found them (my eyes did not :-(). ia64_linux:FAIL: dir2dir ia64_linux:FAIL: no-target-dir Will try to take a look later... -- Matthew I don't question your existence -- God (seen on a church billboard) ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Darwin - GOOD news
The 'rm' problem is gone on Darwin (x86 and PowerPC; didn't remember it affecting x86 but it popped up once as I was building 6.3, when 'rm' was still picking up the one from 5.97). Thanks for the patches! Still the same 'make check' failures, but only on NFS; at least one of which was determined to be a buggy kernel/NFS driver. Not sure if I'll get to ktrace'ing the others or not. Other than the above, NSK(OSS) which I am still working on, and the aforementioned fubar'd Tru64, my only failures (on 12 platforms) are: ia64_linux:FAIL: dir2dir ia64_linux:FAIL: no-target-dir iris_irix:FAIL: date -- Matthew I don't question your existence -- God (seen on a church billboard) ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [bug #17900] rm -f should ignore ENOTDIR
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Paul Eggert on 10/3/2006 12:45 AM: Eric Blake [EMAIL PROTECTED] writes: Shouldn't this also include ELOOP? With ELOOP, we don't know whether the file exists. It could merely be a symlink chain that's too long. So it's safer for rm to print a diagnostic. Actually, on platforms where SYMLOOP_MAX is undefined (doesn't Hurd fall into this category?), then the only way to get ELOOP is via a true loop, and not a long symlink chain. Maybe it is worth conditionally filtering on ELOOP based on the value of SYMLOOP_MAX? - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFIw/T84KuGfSFAYARAtmwAKCjupTqQYRzk0mQSEf3JlcurrlVUgCgz/v9 jVgL25N4tnq3scbScUHkhHQ= =Cbmr -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
