On Jul 4 12:46, Corinna Vinschen wrote:
On Jul 4 11:15, Wolf Geldmacher wrote:
As an aside:
I also used to have some trouble with rm -rf of a directory
hierarchy failing more or less reproducibly (like: 80% of the
time) because files were presumably still in use. Repeating
On Jul 4 16:20, Corinna Vinschen wrote:
On Jul 4 08:21, Ryan Johnson wrote:
However, I was wrong about not seeing the problem since. Choosing a
random source dir to blow away:
$ rm -rf Python-2.6.6
rm: cannot remove `Python-2.6.6/Lib/lib2to3/tests': Directory not empty
$ rm -rf
On 05/07/2011 8:10 AM, Corinna Vinschen wrote:
On Jul 4 12:46, Corinna Vinschen wrote:
On Jul 4 11:15, Wolf Geldmacher wrote:
As an aside:
I also used to have some trouble with rm -rf of a directory
hierarchy failing more or less reproducibly (like: 80% of the
time)
On Tue, 2011-07-05 at 14:10 +0200, Corinna Vinschen wrote:
On Jul 4 12:46, Corinna Vinschen wrote:
On Jul 4 11:15, Wolf Geldmacher wrote:
As an aside:
I also used to have some trouble with rm -rf of a directory
hierarchy failing more or less reproducibly (like: 80% of the
On Tue, 2011-07-05 at 08:21 -0400, Ryan Johnson wrote:
On 05/07/2011 8:10 AM, Corinna Vinschen wrote:
On Jul 4 12:46, Corinna Vinschen wrote:
On Jul 4 11:15, Wolf Geldmacher wrote:
As an aside:
I also used to have some trouble with rm -rf of a directory
hierarchy failing more or
As an aside:
I also used to have some trouble with rm -rf of a directory
hierarchy failing more or less reproducibly (like: 80% of the
time) because files were presumably still in use. Repeating
the command several times would succeed, though.
Downgrading
On Jul 4 11:15, Wolf Geldmacher wrote:
As an aside:
I also used to have some trouble with rm -rf of a directory
hierarchy failing more or less reproducibly (like: 80% of the
time) because files were presumably still in use. Repeating
the command several times would
On 04/07/2011 6:46 AM, Corinna Vinschen wrote:
On Jul 4 11:15, Wolf Geldmacher wrote:
As an aside:
I also used to have some trouble with rm -rf of a directory
hierarchy failing more or less reproducibly (like: 80% of the
time) because files were presumably still in use.
On Jul 4 06:56, Ryan Johnson wrote:
On 04/07/2011 6:46 AM, Corinna Vinschen wrote:
On Jul 4 11:15, Wolf Geldmacher wrote:
As an aside:
I also used to have some trouble with rm -rf of a directory
hierarchy failing more or less reproducibly (like: 80% of the
time) because files
On Jul 4 13:33, Corinna Vinschen wrote:
On Jul 4 06:56, Ryan Johnson wrote:
I have also seen the rm -rf problem occasionally on my w7-64
machine, and I don't think anything from BLODA is installed.
Also with 1.7.8? Given the minor number of FS-related changes, it's
so very unlikely
On Mon, 2011-07-04 at 12:46 +0200, Corinna Vinschen wrote:
On Jul 4 11:15, Wolf Geldmacher wrote:
As an aside:
I also used to have some trouble with rm -rf of a directory
hierarchy failing more or less reproducibly (like: 80% of the
time) because files were presumably still
On Mon, 2011-07-04 at 13:33 +0200, Corinna Vinschen wrote:
On Jul 4 06:56, Ryan Johnson wrote:
On 04/07/2011 6:46 AM, Corinna Vinschen wrote:
On Jul 4 11:15, Wolf Geldmacher wrote:
As an aside:
I also used to have some trouble with rm -rf of a directory
hierarchy failing more or
On 04/07/2011 7:33 AM, Corinna Vinschen wrote:
On Jul 4 06:56, Ryan Johnson wrote:
On 04/07/2011 6:46 AM, Corinna Vinschen wrote:
On Jul 4 11:15, Wolf Geldmacher wrote:
As an aside:
I also used to have some trouble with rm -rf of a directory
hierarchy failing more or less
On Jul 4 08:21, Ryan Johnson wrote:
However, I was wrong about not seeing the problem since. Choosing a
random source dir to blow away:
$ rm -rf Python-2.6.6
rm: cannot remove `Python-2.6.6/Lib/lib2to3/tests': Directory not empty
$ rm -rf Python-2.6.6
$
This seems to happen more than
On 04/07/2011 8:21 AM, Ryan Johnson wrote:
On 04/07/2011 7:33 AM, Corinna Vinschen wrote:
On Jul 4 06:56, Ryan Johnson wrote:
On 04/07/2011 6:46 AM, Corinna Vinschen wrote:
On Jul 4 11:15, Wolf Geldmacher wrote:
As an aside:
I also used to have some trouble with rm -rf of a directory
On Jul 4 16:20, Corinna Vinschen wrote:
On Jul 4 08:21, Ryan Johnson wrote:
However, I was wrong about not seeing the problem since. Choosing a
random source dir to blow away:
$ rm -rf Python-2.6.6
rm: cannot remove `Python-2.6.6/Lib/lib2to3/tests': Directory not empty
$ rm -rf
Any idea of how to debug this? We need some instantaneous version of
lsof or something...
Not what you asked for, but useful for debugging stuff like this: FileMon and
ProcessMonitor from Sysinternals.com (now a MS site). Just in case you haven't
run across them before...
..mark
--
Problem
Dear all,
just joining after being hit by an obviously known issue:
Running tar (in my case to extract openssl-0.9.8r.tar.gz) results in
symbolic links being randomly substituted by zero length mode 0 files as
described in http://sourceware.org/ml/cygwin/2011-04/msg00299.html.
For me this
On Jun 30 14:43, Wolf Geldmacher wrote:
Dear all,
just joining after being hit by an obviously known issue:
Running tar (in my case to extract openssl-0.9.8r.tar.gz) results in
symbolic links being randomly substituted by zero length mode 0 files as
described in
On 6/30/2011 9:37 AM, Corinna Vinschen wrote:
On Jun 30 14:43, Wolf Geldmacher wrote:
Dear all,
just joining after being hit by an obviously known issue:
Running tar (in my case to extract openssl-0.9.8r.tar.gz) results in
symbolic links being randomly substituted by zero length mode 0 files
On Jun 30 11:05, Ken Brown wrote:
On 6/30/2011 9:37 AM, Corinna Vinschen wrote:
On Jun 30 14:43, Wolf Geldmacher wrote:
Dear all,
just joining after being hit by an obviously known issue:
Running tar (in my case to extract openssl-0.9.8r.tar.gz) results in
symbolic links being randomly
On 4/27/2011 11:54 AM, Eric Blake wrote:
On 04/27/2011 09:50 AM, Dan Grayson wrote:
Here is a patch to tar that fixes the problem by using mtime instead of ctime.
Yes, it's not a problem with cygwin or tar, but I see no way for users to
figure out, under Windows, which processes are changing
Eric Blake eblake at redhat.com writes:
...
No, because they don't use ctime the way that cygwin1.dll uses ctime.
They probably have other hacks in their port of tar to work around lack
of POSIX features that cygwin1.dll is emulating.
Do you mean that the implementation of ctime in
On 04/28/2011 09:06 AM, Dan Grayson wrote:
Eric Blake eblake at redhat.com writes:
...
No, because they don't use ctime the way that cygwin1.dll uses ctime.
They probably have other hacks in their port of tar to work around lack
of POSIX features that cygwin1.dll is emulating.
Do you
Here is a patch to tar that fixes the problem by using mtime instead of ctime.
Yes, it's not a problem with cygwin or tar, but I see no way for users to
figure out, under Windows, which processes are changing the status of their
files.
diff -ur tar-1.25-copy/src/extract.c tar-1.25/src/extract.c
On 04/27/2011 09:50 AM, Dan Grayson wrote:
Here is a patch to tar that fixes the problem by using mtime instead of ctime.
Yes, it's not a problem with cygwin or tar, but I see no way for users to
figure out, under Windows, which processes are changing the status of their
files.
Thanks for the
On Wed, Apr 27, 2011 at 11:54 AM, Eric Blake wrote:
I think the patch should remain cygwin-only, and not go upstream.
What about native Windows builds of GNU tar such as GnuWin32? Wouldn't
they benefit from a (suitably conditionalized) patch too?
DSB
--
Problem reports:
On 04/27/2011 10:10 AM, David Boyce wrote:
On Wed, Apr 27, 2011 at 11:54 AM, Eric Blake wrote:
I think the patch should remain cygwin-only, and not go upstream.
What about native Windows builds of GNU tar such as GnuWin32? Wouldn't
they benefit from a (suitably conditionalized) patch too?
Dan Grayson dan at math.uiuc.edu writes:
Here is a patch to tar that fixes the problem by using mtime instead of ctime.
Yes, it's not a problem with cygwin or tar, but I see no way for users to
figure out, under Windows, which processes are changing the status of their
files.
diff -ur
On Apr 25 14:59, Lester Ingber wrote:
Corinna Vinschen corinna-cygwin at cygwin.com writes:
On Apr 24 17:14, Dima Pasechnik wrote:
Dear all,
reposting, as the message did not get through to the mailing list
yesterday:
The issue I have is exactly as described in
(Re-posting yet again, didn't get through yesterday or today (?), this time
from a different account.)
Corinna,
Debugging with gdb shows that tar is prepared for the possibility that
symbolic links don't work and that hard links will have to be used instead.
So, when it encounters a symbolic
On Tue, Apr 26, 2011 at 03:08:52PM +, Dan Grayson wrote:
(Re-posting yet again, didn't get through yesterday or today (?), this time
from a different account.)
Corinna,
Debugging with gdb shows that tar is prepared for the possibility that
symbolic links don't work and that hard links will
On Apr 26 11:22, Christopher Faylor wrote:
On Tue, Apr 26, 2011 at 03:08:52PM +, Dan Grayson wrote:
(Re-posting yet again, didn't get through yesterday or today (?), this time
from a different account.)
Corinna,
Debugging with gdb shows that tar is prepared for the possibility that
Thanks for the correction. That's what tar looks at.
Corinna Vinschen corinna-cygwin at cygwin.com writes:
Btw., POSIX st_ctime is not creation time but change time.
Corinna
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Christopher Faylor cgf-use-the-mailinglist-please at cygwin.com writes:
Cygwin doesn't change the creation time gratuitously. Sounds like BLODA
to me.
http://cygwin.com/acronyms/#BLODA
cgf
Good call! I killed Vid.exe from Logitech and reduced the probability of
failure from 25% per
Corinna Vinschen corinna-cygwin at cygwin.com writes:
On Apr 24 17:14, Dima Pasechnik wrote:
Dear all,
reposting, as the message did not get through to the mailing list yesterday:
The issue I have is exactly as described in
http://sourceware.org/ml/cygwin/2011-04/msg00299.html
I
Dear all,
that's roughly what I also sent to the list in reply to Corinna's message,
but it didn't get through (spamfilter? blacklist? - no idea).
I tried sending 4 times, and all these messages went to a black hole...
On 25 April 2011 22:59, Lester Ingber ing...@alumni.caltech.edu wrote:
On Apr 24 17:14, Dima Pasechnik wrote:
Dear all,
reposting, as the message did not get through to the mailing list yesterday:
The issue I have is exactly as described in
http://sourceware.org/ml/cygwin/2011-04/msg00299.html
I can reproduce this on a very similar Windows 7 host.
(To be
38 matches
Mail list logo
