Just to point out (as probably I'll solve it myself later):
$ tail make_check_outerr
make[1]: Entering directory `/opt/build/i686-pc-cygwin/winsup/cygwin'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/opt/build/i686-pc-cygwin/winsup/cygwin'
make[1]: Entering directory `/opt
On Thu, Jul 16, 2009 at 04:07:23AM +0200, Reini Urban wrote:
>2009/7/15 Steven Hartland:
>> This may or may not help:
>>
>> According to VC++ debugger it always dies with:
>> Unhandled exception at 0x610d089d in perl.exe: 0xC005: Access violation
>> reading location 0x0004.
>>
>> According
2009/7/16 Reini Urban:
> 2009/7/15 Steven Hartland:
>> This may or may not help:
>>
>> According to VC++ debugger it always dies with:
>> Unhandled exception at 0x610d089d in perl.exe: 0xC005: Access violation
>> reading location 0x0004.
>>
>> According to gdb 0x610d089d = thread.cc:113
>
>
2009/7/15 Steven Hartland:
> This may or may not help:
>
> According to VC++ debugger it always dies with:
> Unhandled exception at 0x610d089d in perl.exe: 0xC005: Access violation
> reading location 0x0004.
>
> According to gdb 0x610d089d = thread.cc:113
Thanks!
This looks like almost ce
--- Jacob Jacobson wrote:
> Perhaps this went unnoticed. Reposting it. I am still having
> problems building cygwin dll. Has anyone seen this error?
>
>> > Getting close here. Apparently gets to the linking phase. Please help
>> > with error below.
>> >
>> > [build$:618] (../src/configure --prefix=
Corinna Vinschen cygwin.com> writes:
> Eric, can you please change syscalls.cc, line 532 from
>
> NtSetAttributesFile (fh, pc.file_attributes () & ~FILE_ATTRIBUTE_READONLY);
>
> to
>
> {
> status = NtSetAttributesFile (fh, pc.file_attributes () &
~FILE_ATTRIBUTE_READONLY);
> if (!
Steven Hartland wrote:
>
> - Original Message - From: "Dave Korn"
>> (gdb) b 113 if ((*object) == 0)
>> No symbol "object" in current context.
>> (gdb)
>>
>> Ah, that's bad. It might work on a DLL compiled with -O0 -g, but
>> here we
>> have a problem that the function gets inlined every
- Original Message -
From: "Christopher Faylor"
Any I missing something or has this functionality just been
overlooked?
Overlooked == not implemented.
;-)
Something that's planned?
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/
- Original Message -
From: "Dave Korn"
(gdb) b 113 if ((*object) == 0)
No symbol "object" in current context.
(gdb)
Ah, that's bad. It might work on a DLL compiled with -O0 -g, but here we
have a problem that the function gets inlined everywhere it's called. So
instead I set an unc
Jurriaan Kalkman wrote:
>
> any messages in the ssh logs on the servers? Any difference if you run
> sshd with debug on on the servers?
>
This probably isn't what you mean, but -- I looked in /var/log/. sshd.log
is length 0 and hasn't been touched in several weeks. The only file with a
curre
On Jul 15 21:42, Dave Korn wrote:
> Corinna Vinschen wrote:
> > On Jul 15 20:32, Dave Korn wrote:
> >> Yes. That's why I said "examine the SEH chain", not "look at the call
> >> stack". I reckoned that doing so might provide any insight into why the
> >> myfault was not invoked. For instance,
On Jul 15 16:54, Christopher Faylor wrote:
> On Wed, Jul 15, 2009 at 10:51:29PM +0200, Corinna Vinschen wrote:
> >On Jul 15 20:23, Eric Blake wrote:
> >> Charles Wilson cwilson.fastmail.fm> writes:
> >>
> >> >
> >> > Eric Blake wrote:
> >> > > Also, volinfo is such a helpful debug utility; shoul
On Wed, Jul 15, 2009 at 10:51:29PM +0200, Corinna Vinschen wrote:
>On Jul 15 20:23, Eric Blake wrote:
>> Charles Wilson cwilson.fastmail.fm> writes:
>>
>> >
>> > Eric Blake wrote:
>> > > Also, volinfo is such a helpful debug utility; should we go ahead and
>> > > add
>> it to
>> > > the utils
On Jul 15 20:23, Eric Blake wrote:
> Charles Wilson cwilson.fastmail.fm> writes:
>
> >
> > Eric Blake wrote:
> > > Also, volinfo is such a helpful debug utility; should we go ahead and add
> it to
> > > the utils directory, and compile it alongside other tools like cygcheck
> > > as
> part
On Jul 15 19:42, Eric Blake wrote:
> New thread (gmane gave me grief at finding the old one, and anyways, I'm
> adding
> a couple new topics to the mix).
>
> $ attrib foo
>M:\foo
> $ attrib +r +s foo
> $ attrib foo
> R M:\foo
> $ rm foo
> rm: remove write-protected regular e
On Wed, Jul 15, 2009 at 09:33:20PM +0100, Steven Hartland wrote:
>Having read:
>http://cygwin.com/1.7/cygwin-ug-net/using.html#mount-table
>
>I'm still at a loss how to activate newly added mount points
>from fstab?
>
>The standard Unix paradigm would be mount -a or mount
>but none of these work.
On Wed, Jul 15, 2009 at 02:46:57PM -0400, Charles Wilson wrote:
>Jim Reisert AD1C wrote:
>> I have been running Cygwin 1.7 for a while.
>>
>> There is one annoying problem, when ZIP/UNZIP were installed, I have
>> an unzip.exe executable, but no zip.exe executable. This doesn't
>> matter in *sh s
Having read:
http://cygwin.com/1.7/cygwin-ug-net/using.html#mount-table
I'm still at a loss how to activate newly added mount points
from fstab?
The standard Unix paradigm would be mount -a or mount
but none of these work. The only way I've found is to restart
the cygwin prompt which is obvious
Corinna Vinschen wrote:
> On Jul 15 20:32, Dave Korn wrote:
>> Yes. That's why I said "examine the SEH chain", not "look at the call
>> stack". I reckoned that doing so might provide any insight into why the
>> myfault was not invoked. For instance, you might see something hooked into
>> the S
Eric Blake byu.net> writes:
> Oh - that's why I didn't find it - csih renamed it to getVolInfo, and it is
> not part of the default PATH.
Hmm. Maybe we should teach 'cygcheck -p' to do case-insensitive searches for
the regex; this would have turned up csih for 'cygcheck -c volinfo', instead of
Charles Wilson cwilson.fastmail.fm> writes:
>
> Eric Blake wrote:
> > Also, volinfo is such a helpful debug utility; should we go ahead and add
it to
> > the utils directory, and compile it alongside other tools like cygcheck as
part
> > of the base package?
>
> It's already in the csih pac
Eric Blake wrote:
> Also, volinfo is such a helpful debug utility; should we go ahead and add it
> to
> the utils directory, and compile it alongside other tools like cygcheck as
> part
> of the base package?
It's already in the csih package, under /usr/lib/csih/ but if you want
to "promote" i
From: Chap Harrison
Date: Wed, Jul 15, 2009 at 08:16:05AM -0700
>
> Hi,
>
> I've installed and configured OpenSSH on two Windows 2003 Server / Cygwin
> machines ("chaplab1" and "chaplab2"). I've tried, with PuTTY and plink.exe
> on a Windows 2003 machine on the same LAN, to connect chaplab2, an
On Jul 15 20:32, Dave Korn wrote:
> Yes. That's why I said "examine the SEH chain", not "look at the call
> stack". I reckoned that doing so might provide any insight into why the
> myfault was not invoked. For instance, you might see something hooked into
> the SEH chain ahead of Cygwin's han
New thread (gmane gave me grief at finding the old one, and anyways, I'm adding
a couple new topics to the mix).
$ attrib foo
M:\foo
$ attrib +r +s foo
$ attrib foo
R M:\foo
$ rm foo
rm: remove write-protected regular empty file `foo'? y
rm: cannot remove `foo': Permission den
Christopher Faylor wrote:
> On Wed, Jul 15, 2009 at 05:58:25PM +0100, Dave Korn wrote:
>> Christopher Faylor wrote:
>>> On Wed, Jul 15, 2009 at 05:03:43PM +0100, Dave Korn wrote:
Corinna Vinschen wrote:
> What happens is that this statement
>
> if ((*object)->magic != magic)
- Original Message -
From: "Christopher Faylor"
The point is that this is generating the equivalent of a SEGV without
ever hitting Cygwin's "SEH" code. Setting a breakpoint on the line
would likely just show you the call stack but would not provide any
insight into why the myfault was no
On Wed, Jul 15, 2009 at 05:58:25PM +0100, Dave Korn wrote:
>Christopher Faylor wrote:
>> On Wed, Jul 15, 2009 at 05:03:43PM +0100, Dave Korn wrote:
>>> Corinna Vinschen wrote:
>>>
What happens is that this statement
if ((*object)->magic != magic)
in the function thread.cc
Jim Reisert AD1C wrote:
> I have been running Cygwin 1.7 for a while.
>
> There is one annoying problem, when ZIP/UNZIP were installed, I have
> an unzip.exe executable, but no zip.exe executable. This doesn't
> matter in *sh shells, but does matter when I'm using Cygwin in a "DOS"
> window:
>
>
snip<
I just discovered some additional information that may help get to the
bottom of this. Not sure what made me think of this, but I decided to try
an older version of rsync. If I run rsync 3.0.4-1 or 3.0.5-1, I
experience the problem. However, when I run 2.6.9-2, the only other
version of
I have been running Cygwin 1.7 for a while.
There is one annoying problem, when ZIP/UNZIP were installed, I have
an unzip.exe executable, but no zip.exe executable. This doesn't
matter in *sh shells, but does matter when I'm using Cygwin in a "DOS"
window:
c:\>which unzip
unzip is an exter
On Jul 15 11:08, Marc Girod wrote:
> OK again. Now you are already much deeper than I ever
> was in the causes.
> The MVFS doesn't support DOS attributes?
> I have no clue about that.
> How may I check this? Interesting...
Try this on the MVFS FS:
$ touch foo
$ attrib foo
AX:\foo
$ attrib
On Jul 15 17:38, Eric Blake wrote:
> Corinna Vinschen cygwin.com> writes:
>
> > I created a patch which uses WNetOpenEnum for the existence check, but
> > it needs extremly long to timeout the existence check in such a case.
> [...]
> So, no obvious speed regression on good paths, a whopping 25%
Eric Blake wrote:
>
>> (set (make-local-variable 'purify_flag) t
>
> Setting purify-flag wasn't working for me (emacs gave a message
> about an assertion failure).
>
Huh? Nothing like that here.
In fact, it works...
Wait:
- I still have the 'CYGWIN=winsymlinks' setting --although unse
On Jul 15 09:49, Eric Blake wrote:
> Rather, it seems that the REAL problem is that cygwin1.dll cannot
> recognize attempts to create symlinks on the clearcase MVFS file system.
>
> $ df -T .
> FilesystemType 1K-blocks Used Available Use% Mounted on
> M:/u_fabt_eblake
>unkno
Corinna Vinschen cygwin.com> writes:
> I created a patch which uses WNetOpenEnum for the existence check, but
> it needs extremly long to timeout the existence check in such a case.
There's already a long timeout on unknown names; that's inescapable when
dealing with // issues. Without the pat
On Jul 15 12:23, Christopher Faylor wrote:
> On Wed, Jul 15, 2009 at 05:21:39PM +0200, Corinna Vinschen wrote:
> > SNIP
> >#include
> >#include
> >#include
> >
> >pthread_attr_t attr;
> >
> >void *thr (void *arg)
> >{
> > printf ("I'm a thread\n");
> > return NULL;
> >}
> >
> >int mai
> (set (make-local-variable 'purify_flag) t
Setting purify-flag wasn't working for me (emacs gave a message
about an assertion failure). And my attempt to write an advice
didn't seem to work any better (unless I didn't do it correctly):
(defadvice lock-buffer (around clearcase-no-lock
Christopher Faylor wrote:
> On Wed, Jul 15, 2009 at 05:03:43PM +0100, Dave Korn wrote:
>> Corinna Vinschen wrote:
>>
>>> What happens is that this statement
>>>
>>> if ((*object)->magic != magic)
>>>
>>> in the function thread.cc:verifyable_object_isvalid throws an exception
>>> because *object i
On Wed, Jul 15, 2009 at 05:21:39PM +0200, Corinna Vinschen wrote:
>On Jul 15 01:41, Steven Hartland wrote:
>>
>> - Original Message - From: "Christopher Faylor"
>>
>
>http://cygwin.com/acronyms/#PCYMTNQREAIYR
>
>>> On Wed, Jul 15, 2009 at 12:36:56AM +0100, Steven Hartland wrote:
This
On Wed, Jul 15, 2009 at 05:03:43PM +0100, Dave Korn wrote:
>Corinna Vinschen wrote:
>
>> What happens is that this statement
>>
>> if ((*object)->magic != magic)
>>
>> in the function thread.cc:verifyable_object_isvalid throws an exception
>> because *object is NULL. This should be covered by
Chap Harrison wrote:
>
> defaria wrote:
>> Why are you trying to deal with a very manual, step by step, point and
>> click method of thinking and doing? The basic task here is to get data
>> from an Excel worksheet (which is not a good input method to start with)
>> to a text file. There are pr
Corinna Vinschen wrote:
> What happens is that this statement
>
> if ((*object)->magic != magic)
>
> in the function thread.cc:verifyable_object_isvalid throws an exception
> because *object is NULL. This should be covered by the myfault handler
> in this function but for some reason it isn't
defaria wrote:
>
> Why are you trying to deal with a very manual, step by step, point and
> click method of thinking and doing? The basic task here is to get data
> from an Excel worksheet (which is not a good input method to start with)
> to a text file. There are programmatic ways to do thi
On Jul 15 01:41, Steven Hartland wrote:
>
> - Original Message - From: "Christopher Faylor"
>
http://cygwin.com/acronyms/#PCYMTNQREAIYR
>> On Wed, Jul 15, 2009 at 12:36:56AM +0100, Steven Hartland wrote:
>>> This may or may not help:
>>>
>>> According to VC++ debugger it always dies wit
Hi,
I've installed and configured OpenSSH on two Windows 2003 Server / Cygwin
machines ("chaplab1" and "chaplab2"). I've tried, with PuTTY and plink.exe
on a Windows 2003 machine on the same LAN, to connect chaplab2, and get
"failed to authenticate". But I *can* PuTTY to chaplab1/Cygwin, and fr
On Jul 15 13:58, Eric Blake wrote:
> Corinna Vinschen cygwin.com> writes:
> > The fact that accessing //home does not create an
> > exception points to a successful SMB name resolution.
> [...]
> It still seems like chdir() should do some
> sort of stat() test rather than just a successful SM
Eric Blake wrote:
> Corinna Vinschen cygwin.com> writes:
>
>>> $ ls -dF //eblake //home //bin
>>> ls: cannot access //bin: No such file or directory
>>> //eblake/ //home/
>>>
>>>
>>> I guess that means, since //bin failed but //home succeeded, that there is
>>> a machine on the domain at my work
Corinna Vinschen cygwin.com> writes:
> > $ ls -dF //eblake //home //bin
> > ls: cannot access //bin: No such file or directory
> > //eblake/ //home/
> >
> >
> > I guess that means, since //bin failed but //home succeeded, that there is
> > a machine on the domain at my work which is named home
On Jul 15 06:46, Eric Blake wrote:
> > If you're able to cd to //home, then there must be some crucial
> > difference in your environment. You should debug this, at least with
> > strace, so we can find out under what circumstances this occurs.
>
> (time passes...)
> [...]
>56 6950464 [main]
Just two fixes for now:
Marc Girod wrote:
>
> This function is intened as a find-file-hook."
> ...
> (set (make-local-variable 'purify_flag) t
>
intended
purify-flag
Marc
--
View this message in context:
http://www.nabble.com/.-*-lock-files-under-X%2C-for-files-I-edittp2365579
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Ashok Vadekar on 7/15/2009 5:23 AM:
> Could it be that a mount point called /home, or //home (if possible), makes a
> difference?
Maybe you're on to something - at work I have:
$ mount -m
C:/cygwin-2/bin /usr/bin ntfs binary 0 0
C:/cyg
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Corinna Vinschen on 7/15/2009 2:46 AM:
>> $ cd //home
>> $ # huh? no error reported?
>
> Sorry Eric, but I can't reproduce this. I tried it on XP and 2K8R2
> with identical result.
Weird - it's failing for me on my home network as well,
On Jul 15 07:23, Ashok Vadekar wrote:
http://cygwin.com/acronyms/#TOFU
> - Original Message -
> From: [...]
http://cygwin.com/acronyms/#PCYMTNQREAIYR
> Could it be that a mount point called /home, or //home (if possible), makes a
> difference?
Not as far as I can see. Creating a //ho
> And look how long it's been since Corinna earned a star - doesn't she
> deserve one for her tireless efforts in long file name and wide character
> implementation?
Big +1 from me on that one!
Chris
--
Chris Sutcliffe
http://emergedesktop.org
--
Problem reports: http://cygwin.com/proble
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Christopher Faylor on 7/14/2009 9:38 AM:
>> While we're at it, I'd like to add a gold star for Dave Korn, for his
>> persistence to fix the Cygwin problems which turned up by working on
>> the new gcc 4 libstdc++ and libgfortran problems.
Could it be that a mount point called /home, or //home (if possible), makes a
difference?
- Original Message -
From: cygwin-ow...@cygwin.com
To: cygwin@cygwin.com
Sent: Wed Jul 15 04:46:35 2009
Subject: Re: [1.7] bug in chdir
On Jul 14 21:47, Eric Blake wrote:
> $ ls //home
> ls: read
Marc Girod wrote:
>
> I'll report my results...
>
Here is what I did, to make it practical:
(defun clearcase-no-lock()
"Under ClearCase, in Cygwin, do not create lock symlinks.
Either format (old: Windows shortcuts; new: real symlinks with utf name) are
bad for different reasons.
The only wa
Marc Girod wrote:
>
> Thanks. I'll try that.
>
That was: 'CYGWIN=winsymlinks tty'
The result is not fully satisfying.
E.g.:
lrwxrwxrwx 1 emagiro EEI-ATusers45 Jul 14 11:57 .#common.mk ->
emag...@ev0016d4a35054.eemea.ericsson.se.4708
in a dired buffer, and which I cannot remove:
makesy
On Jul 14 21:47, Eric Blake wrote:
> $ ls //home
> ls: reading directory //home: No such file or directory
> $ # makes sense; I don't have a remote machine named home
> $ cd //home
> $ # huh? no error reported?
> $ /bin/pwd # avoid shortcuts in bash builtin; /bin/pwd uses getcwd
> //home
Sorry Eri
On Jul 15 09:34, Matthias Andree wrote:
> Am 14.07.2009, 17:47 Uhr, schrieb Christopher Faylor
> :
>
>> Btw, some versions of cmd.exe don't work well with executables which lack
>> extensions. I just ran into this problem recently. I don't remember
>> exactly where, probably it was with NT 4.
>
>
Corinna Vinschen wrote:
> I changed the internal fhandler_base::fstat_by_handle method not to
> use the FileAllInformation info class at all, since we don't need the
> filename anyway in stat.
>
> Thanks for the report,
Thanks for the fix. Confirmed that it fixes the test case on my system.
--
C
Am 14.07.2009, 17:47 Uhr, schrieb Christopher Faylor
:
Btw, some versions of cmd.exe don't work well with executables which lack
extensions. I just ran into this problem recently. I don't remember
exactly where, probably it was with NT 4.
Perhaps Cygwin 1.7 should do away with NT compatibili
63 matches
Mail list logo
