-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Please keep replies on the list, so that you will get a faster response,
and so that others with a similar problem can search the list archives for
your solution.
According to Axel Colunga on 3/3/2007 3:56 PM:
for example if i have a file with 5
Hi,
I sometimes get the following error:
courge:~/software \rm -r zsh-4.3.2
rm: cannot remove `zsh-4.3.2/Src/Modules/zutil..o': No such file or directory
rm: cannot remove `zsh-4.3.2/Src/Modules/zutil.export': No such file or
directory
rm: cannot remove `zsh-4.3.2/Src/Modules/zutil.so': No
Vincent Lefevre [EMAIL PROTECTED] wrote:
I sometimes get the following error:
courge:~/software \rm -r zsh-4.3.2
rm: cannot remove `zsh-4.3.2/Src/Modules/zutil..o': No such file or directory
rm: cannot remove `zsh-4.3.2/Src/Modules/zutil.export': No such file or
directory
rm: cannot
On 2007-03-05 16:45:46 +0100, Jim Meyering wrote:
Thanks for the report.
What version of coreutils are you using?
rm (GNU coreutils) 5.97
This is the version from Debian/testing.
From the output, I'll bet it is not new.
Can you reproduce the problem using the latest snapshot?
Vincent Lefevre [EMAIL PROTECTED] wrote:
On 2007-03-05 16:45:46 +0100, Jim Meyering wrote:
Thanks for the report.
What version of coreutils are you using?
rm (GNU coreutils) 5.97
This is the version from Debian/testing.
From the output, I'll bet it is not new.
Can you reproduce the
On 2007-03-05 17:36:08 +0100, Jim Meyering wrote:
Vincent Lefevre [EMAIL PROTECTED] wrote:
On 2007-03-05 16:45:46 +0100, Jim Meyering wrote:
Can you reproduce the problem using the latest snapshot?
http://meyering.net/cu/coreutils-6.8+.tar.gz
Tried, and this is even worse: I got the
Vincent Lefevre [EMAIL PROTECTED] wrote:
I've attached the log. Here are the contents of the archive:
Your log shows that rm succeeds in removing each file (all unlink syscalls
succeed), yet the directory is not empty, so it rewinds it and goes
through again -- and all names are still there.
On 2007-03-05 21:59:37 +0100, Jim Meyering wrote:
Vincent Lefevre [EMAIL PROTECTED] wrote:
But IMHO, rm should remember that is has already done an unlink and
there shouldn't be a diagnostic in this case.
Unfortunately it's not that easy.
If I were to make such a change, it is quite
On 3/5/07, Jim Meyering [EMAIL PROTECTED] wrote:
Vincent Lefevre [EMAIL PROTECTED] wrote:
I've attached the log. Here are the contents of the archive:
Your log shows that rm succeeds in removing each file (all unlink syscalls
succeed), yet the directory is not empty, so it rewinds it and goes
Jim Meyering [EMAIL PROTECTED] writes:
If I were to make such a change, it is quite likely
that it would cause a real unlink failure not to be
reported, and *that* would be serious.
Doesn't this wart come from the hack to work around a readdir bug in
MacOS? It sounds a bit like the tail
Peter O'Gorman [EMAIL PROTECTED] writes:
What if the package does not use AC_CONFIG_HEADERS? This patch will
fail. What about AC_CHECK_SIZEOF which will report incorrect results
if -arch i386 -arch x86_64 are specified for example?
Those problems existed in the previous Autoconf version too,
On 2007-03-05 16:02:54 -0800, Paul Eggert wrote:
Read the directory, removing files as we go.
getdents64(4, /* 15 entries */, 8192) = 472
lstat(/proc/self/fd/4/config.h.in, {st_mode=S_IFREG|0644, st_size=27828,
...}) = 0
access(test/config.h.in, W_OK)= 0
Vincent Lefevre [EMAIL PROTECTED] writes:
The problem here is the NFS *client*, isn't it? And I'm not sure this
is really a bug of the NFS client, knowing the fact that NFS works
asynchronously.
No, you're right, I don't see a bug in the GNU/Linux NFS client here.
The original workaround has
13 matches
Mail list logo
