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
> >>> hierarch
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% o
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 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
> > >$
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".
> 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
--
Proble
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
> > >$
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 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 mo
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 r
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
> > >> hierarch
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 presumab
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 unlik
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)
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 us
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
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.
Downgradin
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 li
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 a
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 http://sourceware.or
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 happen
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 the
On 04/28/2011 09:06 AM, Dan Grayson wrote:
> Eric Blake 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 yo
Eric Blake 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 cygwin1.dll
Dan Grayson 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 t
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 to
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: http://cygwin.com
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
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
--
Christopher Faylor 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 file to 1%. Sadly, killing oth
Thanks for the correction. That's what tar looks at.
Corinna Vinschen 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/
Documentation:
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 p
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 li
(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 l
On Apr 25 14:59, Lester Ingber wrote:
> Corinna Vinschen 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
> > > h
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 wrote:
> Corinna Vinschen cygwin.com>
Corinna Vinschen 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 can
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 b
38 matches
Mail list logo
