Re: [bug-gnulib] Re: coreutils-6.2: various runtime problems on Darwin-8.7.0 HFS+ (including attachment this time)
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. What version of Darwin are you using? Darwin 7.9.0 = MacOS X 10.3.9. I wrote: In the run test, you can use /bin/rm, since /bin/rm has the same bug as the one you are fixing for GNU rm. which is wrong. /bin/rm shares another bug with GNU rm. But the one we are currently discussing is only in GNU rm; /bin/rm is not affected. Bruno ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
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 wrote: In the run test, you can use /bin/rm, since /bin/rm has the same bug as the one you are fixing for GNU rm. which is wrong. That's ok. I already have a good test that checks readdir directly. /bin/rm shares another bug with GNU rm. But the one we are currently discussing is only in GNU rm; /bin/rm is not affected. You mean you've found *another* problem with GNU rm? Is so, please provide details. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [bug-gnulib] Re: coreutils-6.2: various runtime problems on Darwin-8.7.0 HFS+ (including attachment this time)
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 failed in
others:
$ tar xf /Volumes/ExtData/bin.x86-linux/cross/cross-hppa.tar.gz
$ ll cross/hppa-linux/share/i18n/charmaps | wc -l
195
$ rm -r cross
rm: Entfernen von Verzeichnis „cross/hppa-linux/share/i18n/charmaps“ nicht
möglich: Directory not empty
$ ll cross/hppa-linux/share/i18n/charmaps | wc -l
17
$ rm -r cross
Actually the number of files that can be removed before stumbling on the
bug depends on the length of the filenames. Here it a command that
generates a table. First column: l, the length of an additional suffix tacked
on every filename. Second column: n, the number of files that can be removed
without hitting the bug.
$ for l in `seq 0 200`; do
suffix=`printf %${l}s | tr ' ' 'S'`;
tar xf /Volumes/ExtData/bin.x86-linux/cross/cross-hppa.tar.gz;
if test $l != 0; then
(cd cross/hppa-linux/share/i18n/charmaps;
for f in *; do mv $f $f$suffix; done
);
fi;
before=`ls -l cross/hppa-linux/share/i18n/charmaps | wc -l`;
rm -rf cross 2/dev/null;
after=`ls -l cross/hppa-linux/share/i18n/charmaps | wc -l`;
removed=`expr $before - $after`;
while ! rm -rf cross 2/dev/null ; do : ; done;
printf '%3d %3d\n' $l $removed;
done
l n
--- ---
0 178
1 174
2 170
3 156
4 152
5 150
6 148
7 138
8 135
9 134
10 131
11 122
12 120
13 119
14 117
15 109
16 108
17 107
18 105
19 99
20 97
21 96
22 95
23 90
24 88
25 87
26 86
27 82
28 115
29 80
30 79
31 76
32 75
33 74
34 73
35 70
36 69
37 69
38 67
39 66
40 65
41 64
42 63
43 61
44 60
45 60
46 59
47 58
48 57
49 57
50 56
51 55
52 54
53 54
54 53
55 52
56 51
57 51
58 50
59 49
60 49
61 48
62 48
63 47
64 46
65 46
66 46
67 45
68 44
69 44
70 43
71 43
72 85
73 42
74 42
75 41
76 41
77 40
78 40
79 39
80 39
81 39
82 38
83 38
84 38
85 37
86 37
87 36
88 36
89 36
90 36
91 35
92 35
93 35
94 35
95 34
96 34
97 34
98 68
99 33
100 33
101 33
102 32
103 32
104 32
105 32
106 31
107 31
108 31
109 31
110 30
111 30
112 30
113 30
114 30
115 29
116 29
117 29
118 29
119 28
120 28
121 28
122 28
123 28
124 27
125 27
126 27
127 27
128 27
129 27
130 26
131 26
132 26
133 26
134 26
135 25
136 25
137 25
138 25
139 25
140 25
141 25
142 24
143 24
144 24
145 24
146 24
147 24
148 23
149 23
150 23
151 23
152 23
153 23
154 23
155 22
156 22
157 22
158 22
159 22
160 22
161 22
162 22
163 22
164 21
165 21
166 21
167 21
168 21
169 21
170 21
171 21
172 21
173 20
174 20
175 20
176 20
177 20
178 20
179 20
180 20
181 20
182 20
183 19
184 19
185 19
186 19
187 19
188 19
189 19
190 19
191 19
192 19
193 19
194 19
195 18
196 18
197 18
198 18
199 18
200 18
The initial directory contents is:
3 files of length 5
4 files of length 6
3 files of length 7
6 files of length 8
64 files of length 9
10 files of length 10
8 files of length 11
21 files of length 12
18 files of length 13
13 files of length 14
9 files of length 15
12 files of length 16
6 files of length 17
1 files of length 18
6 files of length 19
5 files of length 20
1 file of length 21
2 files of length 22
1 file of length 23
1 file of length 26
---
N=194 files total, sum of lengths S = 2315
It does not require higher mathematics to see that n can essentially be
expressed through the formula
n = 78 / (S + l * 194 + 10 * 194)
or
n = 4020 / (S/N + l + 10)
Recalling that S/N + l is the average length of a filename in the set, one
can nearly guess that the readdir bug occurs usually after a single block
of directory entries has been filled, where a block is a little less than
4096 bytes and a directory entry consists of the filename, 2 bytes of
alignment and 8 bytes of data.
Thus, instead of testing whether the number of directory entries since the
last rewind() exceeds a fixed number, a better test is probably whether
(total length of file names since last rewind()
+ 10 * number of directory entries since last rewind())
a fixed number such as 3000
Bruno
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
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 failed in others: ... Thus, instead of testing whether the number of directory entries since the last rewind() exceeds a fixed number, a better test is probably whether (total length of file names since last rewind() + 10 * number of directory entries since last rewind()) a fixed number such as 3000 Thanks for the quick test and analysis! Considering all of that, I may just keep the code simple and make rm always do an extra rewind on Darwin. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [bug-gnulib] Re: coreutils-6.2: various runtime problems on Darwin-8.7.0 HFS+ (including attachment this time)
Jim, Is there any type of file system where readdir works? I tried only HFS+ mounts (on two different volumes). What version of Darwin are you using? Darwin 7.9.0 = MacOS X 10.3.9. I see no failure with Darwin-8.7.0, so I might add a run-test (like coreutils' old readdir.m4), if it's likely to be independent of file system type. I will test and report for other file systems. In the run test, you can use /bin/rm, since /bin/rm has the same bug as the one you are fixing for GNU rm. Bruno ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
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 several others). :-) btw, thanks for the mails... I just built coreutils on Darwin also, and had a good number of 'make check' failures. 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 several times in succession works, though. Now, *that* is interesting. Would you please see if you can reproduce that using an rm binary built from coreutils-6.2? I couldn't, when using an hfs partition on Darwin 8.7.0. The core of rm was seriously revamped between coreutils-5.97 and 6.0. I plan to, as soon as I get a chance. FYI this was on an NFS mount so there might be some weird interaction with the NFS driver... although I've built coreutils 5.97 on almost a dozen platforms and Darwin (both x86 and PowerPC as I recall) is the only OS that's given me problems. I was unable to reproduce that. Tried both NFS and hfs. If you can, please give details asap. I expect to release coreutils-6.3 very soon. It'd be particularly useful to know how many files it removes at each iteration. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: coreutils-6.2: various runtime problems on Darwin-8.7.0 HFS+ (including attachment this time)
mwoehlke [EMAIL PROTECTED] wrote:
...
Did you try with 5.97? I haven't tried 6.2 yet (will try to do that
No, since rm in that release is so different, and since
I don't plan to make a 5.98 release.
soon)... Um, actually, I am probably not going to try until someone can
tell me how the *($ to test the exit code of 'make check' after I've
piped it through 'tee' :-) - tips would be most welcome!
Easiest test is on coreutils itself...
$ uname -srvmpio
Darwin 7.9.0 Darwin Kernel Version 7.9.0: Wed Mar 30 20:11:17 PST 2005;
root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC Power Macintosh powerpc
RackMac3,1 Darwin
$ rm --version
rm (GNU coreutils) 5.97
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software. You may redistribute copies of it under the terms 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 directory
$ tar xzf coreutils-5.97.tar.gz
$ find coreutils-5.97/ | wc -l
2788
$ rm -rf coreutils-5.97
rm: cannot remove directory `coreutils-5.97/m4': Directory not empty
rm: cannot remove directory `coreutils-5.97/lib': Di0rectory not empty
$ find coreutils-5.97/ | wc -l
173
$ rm -rf coreutils-5.97
$ find coreutils-5.97/ | wc -l
find: coreutils-5.97/: No such file or directory
0
$
Thanks. That's probably all I needed.
From those numbers and the number of files in lib and m4, I deduce
that your system's readdir is mistakenly returning NULL when there
are around 190 entries in a directory.
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 rm fails.
Once you find that number, say 190, change the enum in your
copy of coreutils' src/remove.c that looks like this:
/* This is the maximum number of consecutive readdir/unlink calls that
can be made (with no intervening rewinddir or closedir/opendir)
before triggering a bug that makes readdir return NULL even though
some directory entries have not been processed. The bug afflicts
SunOS's readdir when applied to ufs file systems and Darwin 6.5's
(and OSX v.10.3.8's) HFS+. This maximum is conservative in that
demonstrating the problem seems to require a directory containing
at least 254 deletable entries (which doesn't count . and ..), so
we could conceivably increase the maximum value to 254. */
enum
{
CONSECUTIVE_READDIR_UNLINK_THRESHOLD = 200
};
to use the number that is one smaller than the one you found:
CONSECUTIVE_READDIR_UNLINK_THRESHOLD = 189
Then recompile, and rm -r should work.
Please let us know.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
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 verbose) for the entire suite for Darwin PowerPC (the same machine I did the last test on). Ok, I have the 'check' output; it is 6 files (one master, five individual failed tests with VERBOSE=yes) and 43k. .tar.bz2'd it is 6k. Which form is preferred? Best is to make it available via the web and just post the URL. Failing that, send it to the list, and Cc me, in case the list software removes your attachment. Also 'pinky' and 'help-version' failed; I couldn't figure out how to run these by themselves and figured these two probably weren't as important as the rm, cp, mv, and chmod failures (and the fifth was du). Yes, running the help-version test all by itself is a little tricky: cd tests VERBOSE=yes make check TESTS=help-version SUBDIRS= ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: coreutils-6.2: various runtime problems on Darwin-8.7.0 HFS+ (including attachment this time)
Jim Meyering wrote: mwoehlke [EMAIL PROTECTED] wrote: # using THRESHOLD = 150 $ tar xzf coreutils-6.3.tar.gz $ until /path-to-rm -rf coreutils-6.3 ; do : ; done # using THRESHOLD = 200 (default) $ tar xzf coreutils-6.3.tar.gz $ until /path-to-rm -rf coreutils-6.3 ; do : ; done /path-to-rm: cannot remove directory `coreutils-6.3/m4': Directory not empty /path-to-rm: cannot remove directory `coreutils-6.3/lib': Directory not empty ...so that is definitely the problem. Trying a few more values, I see: 150 - works 200 - broken 175 - works 190 - broken (but only in m4, not lib) 185 - works 188 - broken (same as 190) 187 - works Honestly, I would probably go with 160-ish to be safe. :-) Thanks. I'll use 180. The lower we go, the more of a performance penalty we impose for directories with very many entries. Already, in implementing remove.c that way, I've compromised (however slightly) how GNU rm works in general, for the sake of working reliably even on such broken file systems. Have you considered making this conditional to broken Darwin versions? :-) Anyway, just caught the check-in too, thanks. -- Matthew Download. Untar. Configure. Make. Install. Lather. Rinse. Repeat. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
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 impossible to know what new systems will end up being used. And it's not Darwin-specific. Hmm.. but the only other system listed in comments is SunOS, which is essentially dead, these days. Though I seem to recall there being at least one other. But maybe I should do that, after all, along with adding a make check test to detect any new disfunctional systems. But not right now :) And maybe never. First, I'll profile to see if it's even worth considering. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
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, complained only a tiny bit about the hu language (smth about 2 or more suffixes for this language? I didn't save the output), but otherwise a good run. (Some months ago I did get autoconf-2.60 installed into both /usr and /usr/local [never know which is going to be used ;) ].) [snip] In case of dups, I checked to see the newer m4's are in /usr/local/share/aclocal, others are in /usr/share/aclocal, and I always do this in the build environment: export ACLOCAL_FLAGS='-I /usr/local/share/aclocal -I /usr/share/aclocal' That sounds risky. I wouldn't. You might easily end up using an incompatible .m4 file. That can lead to subtle and hard-to-diagnose failures. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
here's my latest make check log on Darwin (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)))
(Unison won't let me attach a file to a message, nor will it let an upload come with a message, too lazy to switch to Thoth right now ;) so I'll do this via e-mail) I cvs update'd within the last half-hour. Builds seem to go fine. I ran make -k check with all the RUN*TESTS enabled I could dig-up. Attached should be a file named 'cucvs_makecheck.log.bz2' which is the tee'd capture from the check. I think these failures are 100% explainable on Darwin. Also, the filesystem bugs causing the long ls and other problems seem successfully bypassed now. So I feel we're very close for release. I'll do a make install and use it for real for a while. :) Thank you. cucvs_makecheck.log.bz2 Description: BZip2 compressed data ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
coreutils-6.2: various runtime problems on Darwin-8.7.0 HFS+
Hi, 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.7.0 (Tiger 10.4.7 and the latest XCode-2.4). I actually have installed coreutils-5.97 to compare with. 5.97 seems to work fine, but 6.2 seems to have many things wrong. Most notably the new 'ls' in 6.2 is acting very very strange. We get double listings in 'long' mode of every file, with exactly the first set saying No such file or directory, including the dot-dirs. The second set lists each file/dir as expected. I am attaching a sample to show you what I mean here. Please find the archive named 'coreutils-6.2-bugs.tar.bz2'. It should expand to create these files: -rw-r--r-- 1 root wheel 1957313 Sep 25 00:43 config.log -rw-r--r-- 1 root wheel 31244 Sep 25 00:43 config_consolelog.txt -rw-r--r-- 1 root admin 29725 Sep 25 00:51 ls_whoops_consolelog.txt -rw-r--r-- 1 root wheel 67706 Sep 25 00:45 make_consolelog.txt -rw-r--r-- 1 root wheel 55908 Sep 25 00:49 makecheck_consolelog.txt The 'ls_whoops_consolelog.txt' will show you what I mean about the ls bug in 6.2. While I'm at it, I ran 'make check' and tee'd its output into 'makecheck_consolelog.txt'. A number of tests failed. The 'config_consolelog.txt' is a tee'd capture of the './configure' run. I also include the original 'config.log' as written. Please note there seems to be a few more bugs here, too, such as some header file locations are printed with leading triple-slashes (no problem on Darwin here, just a thing to note). The 'make_consolelog.txt' is a tee'd capture of the 'make all'. This gen was made with unset env xxFLAGS totally, so defaults should've been plugged in. I believe I tried the 6.1 a while back and had to scrap it, too, with too many problems. Since these are unstable, I will stay with 5.97 until/unless you-all have something you'd like me to try. I'm obviously quite worried about releasing this code to Darwin users, so I thought I better do a bit of hollarin' here. ;) Oh the filesystem is all HFS+ with 'large' disks (200GB to 300GB). The boot-vol is case-sensitive, while the build-vol is not (for compatibility with older Macs). Again 5.97 built and installed fine with this same set-up. Let me know if I can help further. Thank you. Concerned about your privacy? Instantly send FREE secure email, no account required http://www.hushmail.com/send?l=480 Get the best prices on SSL certificates from Hushmail https://www.hushssl.com?l=485 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
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.7.0 (Tiger 10.4.7 and the
latest XCode-2.4). I actually have installed coreutils-5.97 to
compare with.
5.97 seems to work fine, but 6.2 seems to have many things wrong.
Most notably the new 'ls' in 6.2 is acting very very strange.
We get double listings in 'long' mode of every file, with
exactly the first set saying No such file or directory,
including the dot-dirs. The second set lists each file/dir as
expected.
I am attaching a sample to show you what I mean here. Please
find the archive named 'coreutils-6.2-bugs.tar.bz2'. It should
expand to create these files:
-rw-r--r-- 1 root wheel 1957313 Sep 25 00:43 config.log
-rw-r--r-- 1 root wheel 31244 Sep 25 00:43 config_consolelog.txt
-rw-r--r-- 1 root admin 29725 Sep 25 00:51
ls_whoops_consolelog.txt
-rw-r--r-- 1 root wheel 67706 Sep 25 00:45 make_consolelog.txt
-rw-r--r-- 1 root wheel 55908 Sep 25 00:49
makecheck_consolelog.txt
Thank you for the complete bug report!
I'm obviously quite worried about releasing this code to Darwin
users, so I thought I better do a bit of hollarin' here. ;)
You're right to be cautious.
The problems involving ls, cp, and install are all due
to the fact that Darwin's acl_get_file function (used
in coreutils' lib/acl.c) is not behaving as advertised:
it's returning NULL and setting errno to ENOENT for a file
that *does* exist. However, the man page says it does that only
for files that do not exist. When a function like that reports
a failure, coreutils programs report it and exit nonzero, and
that's why you're seeing so many diagnostics and test failures.
Using the very latest version from coreutils and gnulib,
when I turn off ACL support altogether (comment out the USE_ACL
definition in lib/config.h), all of the tests pass except tests/dd/misc.
That failure appears to be due to another Darwin-specific bug:
The open flag, O_NOFOLLOW is defined, yet open doesn't honor the
semantics we've come to expect for that flag. That makes the test
of dd's new iflag=nofollow option fail.
The only mitigating factor is that O_NOFOLLOW is not yet documented in
their open man page: the definition may have slipped into their
system headers before library support was completed.
Unfortunately, O_NOFOLLOW (when present) is an important key to avoiding
certain types of race conditions. Defining the symbol yet letting
open ignore it is *bad*. Here's a small program to demonstrate the bug.
Run the command in the comment. If it prints bug, then your system's
open function is buggy.
$ cat o_nofollow.c
/* rm -f s f; cc o_nofollow.c { touch f; ln -s f s; ./a.out || echo bug; } */
# define _GNU_SOURCE 1
#include sys/types.h
#include sys/stat.h
#include fcntl.h
int
main ()
{
int fd = open (s, O_RDONLY|O_NOFOLLOW);
return 0 fd;
}
However, the good news is that this led me to discover a bug in gnulib's
test for just this type of brokenness. Its fcntl_h module tests for a
nonfunctional O_NOFOLLOW, but the test had a typo. I've just checked
in a fix for that.
So now, all tests now pass, using the very latest, and with the hack
to disable ACL support. I suppose we'll need an added run-test
to detect the acl_get_file brokenness.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: coreutils-6.2: various runtime problems on Darwin-8.7.0 HFS+ (including attachment this time)
[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 'make check' failures. 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 several times in succession works, though. -- Matthew KDE: Desktop Excellence ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
