This is an old problem, the last I heard on it was something along the lines of:
"Cygwin's functionality/compatibility/robustness improved in necessary
ways, but performance was required to suffer"
>From a hearsay perspective, it appears to be related to fork/exec
performance, and more specifically
On 1/14/09, Larry Hall wrote:
> greenup greenup wrote:
> > I notice someone else is having problems with their X lock files; that
> > was one of the things that got me started fiddling with rm. Today is
> > busy for me, so I'm not sure that I'll get to strace/etc,
I notice someone else is having problems with their X lock files; that
was one of the things that got me started fiddling with rm. Today is
busy for me, so I'm not sure that I'll get to strace/etc, but
hopefully tomorrow. I checked another box in my house, that seems to
be working fine with mostl
On Tue, Jan 13, 2009 at 5:34 PM, Larry Hall (Cygwin) wrote:
> greenup greenup wrote:
>>
>> broken again/still.
>>
>> On 1/13/09, Mark J. Reed wrote:
>
> Any luck on the BLODA front?
>
Afraid I don't know BLODA, but disabling the virus scanner for a few
broken again/still.
On 1/13/09, Mark J. Reed wrote:
> On Tue, Jan 13, 2009 at 2:52 PM, greenup wrote:
> > your perl test was a nice try; but it also did not remove the file,
> > which is revealing.
> I should have included a return code check:
>
> perl -e 'unlink("goo/foo") or die $!'
>
d...@w2
On 1/13/09, Dave Korn wrote:
> greenup greenup wrote:
> > On 1/13/09, Mark J. Reed wrote:
> >> On Tue, Jan 13, 2009 at 2:52 PM, greenup wrote:
> >> > your perl test was a nice try; but it also did not remove the file,
> >> > which is revealing.
On 1/13/09, Mark J. Reed wrote:
> On Tue, Jan 13, 2009 at 2:52 PM, greenup wrote:
> > your perl test was a nice try; but it also did not remove the file,
> > which is revealing.
> I should have included a return code check:
> perl -e 'unlink("goo/foo") or die $!'
the return code check worked!!
"not a universal problem" is good and bad... good that this is
widespread, bad that it's harder to debug on just my system.
I renamed the other rm, (after checking to see if it worked... it
does, but even though it can cope with forward slashes, it hates
/cygdrive/d/..."
I also tried backing dow
oops. forgot to scrub mail headers for email addrs. Sorry about
that. does the list archive scrub?
-greenup
On 1/13/09, greenup greenup wrote:
> On 1/13/09, Mark J. Reed wrote:
> > On Tue, Jan 13, 2009 at 12:16 PM, greenup wrote:
--
Unsubscribe info: http://cygwin.com/ml/#un
On 1/13/09, Mark J. Reed wrote:
> On Tue, Jan 13, 2009 at 12:16 PM, greenup wrote:
> > oh, I forgot to mention: right after doing the rm, the return code is
> > success, even though it failed to actually remove the file.
> rm with -f is silent about certain types of errors, usually of the
> "fi
oh, I forgot to mention: right after doing the rm, the return code is
success, even though it failed to actually remove the file.
d...@w2 ~
$ rm -f goo/foo
d...@w2 ~
$ echo $?
0
On 1/13/09, greenup greenup wrote:
>...
> d...@w2 ~
> $ mkdir goo
>
> d...@w2 ~
> $ touch go
I seem to have problems with rm.
specifically, even when using -f it won't remove files, if the
permissions are restricted to read-only. -f is supposed to be the "I
don't care, just do it" switch.
At one point moved my whole "c:\cygwin" hierarchy to a backup,
rebooted and reinstalled, to try and
I've done a fair bit of searching on the net (6+hours of googling), but
can't find a solution, or a complete "No, there's no way to work around
that" to this problem:
I have to log into a large number of systems, and on some sets (such as
"all devboxes") I like to keep my password the same, for
13 matches
Mail list logo
