According to Jim Meyering on 9/7/2009 11:41 AM: Good point. I've reread the text, and although it mentions stdbuf, it does not imply that stdbuf is the only way to get this behavior. So I'm okay with
According to Pádraig Brady on 9/7/2009 6:32 PM: Yep; and only Solaris had the problem, because that is the only platform with broken fstatat (the other platforms either lack it or it works entirely)
Here's another snapshot, prior to coreutils-7.6. We've inherited quite a few changes from gnulib, including one to fix the Solaris build failure. coreutils snapshot: http://meyering.net/cu/coreutils-
Passed Skipped Failed \-- Fedora core 5 x86 | 348 42 0 Fedora 11 x86 | 343 47 0 Solaris 10 x86 | 328 61 1 Solaris 9 x86 | 314 61 15 Note the solaris systems were on nfs new solaris 10 failure in cp/i
rerunning on local file systems: Passed Skipped Failed \-- Fedora core 5 x86 | 348 42 0 Fedora 11 x86 | 343 47 0 Solaris 10 x86 | 328 62 0 Solaris 9 x86 | 327 62 1 solaris 9 failure was: mv/part-syml
By the way, thank you for the testing. I have not investigated (no solaris 9 for me, and even if I had access, ...) but that test is moving a regular file to a "remote symlink", which means a symlink
I'm not too worried about this TBH, and was just posting for completeness. I was running test from /tmp (swap) and the $other_partition was /var/tmp which was mounted on / I think. It could be just s
This includes the new, fts-using version of rm: coreutils snapshot: http://meyering.net/cu/coreutils-ss.tar.gz (9.6 MB) http://meyering.net/cu/coreutils-ss.tar.xz (4.0 MB) http://meyering.net/cu/core
Here's a snapshot of the latest: coreutils snapshot: http://meyering.net/cu/coreutils-ss.tar.gz 9.7 MB http://meyering.net/cu/coreutils-ss.tar.xz 4.1 MB http://meyering.net/cu/coreutils-ss.tar.gz.sig
There have been *many* changes in gnulib since the previous snapshot, and the changes in coreutils are non-negligible, so please give this a try. I'd like to make the beta release on Monday. I'll pro
According to Jim Meyering on 10/3/2009 2:30 AM: I'm still wondering if we want one more patch: now that we document that readlink -f link/ succeeds, with the claim that 'mkdir link/' will also succee
Yes, adding a test would be good. Such a test would be expected to fail on Linux. It's tempting to say "let's make mkdir(1) work around it", but I would like to avoid adding any more uses of canonica
According to Jim Meyering on 10/4/2009 2:10 AM: and you even suggested that: http://lists.gnu.org/archive/html/bug-coreutils/2009-09/msg00365.html At this point, it's enough of a corner case that I'm
According to Eric Blake on 10/4/2009 8:29 AM: For the record, I tried the quick hack below to change things in just coreutils for 'mkdir -p' (without even touching plain 'mkdir' for Linux), all witho
Thanks for the testing! This is a new test, but FC5 is soooo old, that I'm not sure it's worth worrying about. Can you look into why that failed? I have just reconfirmed that the build succeeds for m
March 2006? Hrm 7.6 builds fine here. But with the latest snapshot the linker here looks like it needs $LIB_EACCESS for all binaries. I notice that euidaccess() is newly referenced by faccessat.c Cou