-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 col
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 suc
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: can
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 yo
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
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 19:07:31 +0100, Jim Meyering wrote:
> 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. The _second_ unlink
> attempt fails with ENOENT, be
Vincent Lefevre <[EMAIL PROTECTED]> wrote:
> On 2007-03-05 19:07:31 +0100, Jim Meyering wrote:
>> 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. The
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 qu
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 g
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
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
>unlin
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
15 matches
Mail list logo