On Sep 14 22:09, John Carey wrote:
On Sep 14 09:11, Corinna Vinschen wrote:
I applied the below patch to Cygwin CVS and it appears to work nicely.
The only potential race I can think of is, if another thread of the same
Cygwin process calls SetCurrentDirectory. I'm inclined to let this
On Sep 14 22:11, John Carey wrote:
On Sep 14 12:02, Corinna Vinschen wrote:
True. Implementing a full replacement for SetCurrentDirectory as in
your PoC is still an option. However, I can't do that anymore since
I'm tainted by reading your code. If you would contemplate to sign
a
On Sep 13 19:47, John Carey wrote:
On Sep 11 03:30, Corinna Vinschen:
Given that, wouldn't it be potentially possible to override the content
of curCwd? The problem is probably (just as in my old Cygwin code up to
1.7.5) to make sure that this is thread safe. Probably we would still
On Sep 14 10:12, Corinna Vinschen wrote:
On Sep 13 19:47, John Carey wrote:
Anyway, it looks to me as if overwriting the path in an existing
VistaCwd instance would confuse RtlGetCurrentDirectory_U() and
probably other Win32 API functions. (It may be that the same is
true for the handle
On Sep 14 18:11, Corinna Vinschen wrote:
On Sep 14 10:12, Corinna Vinschen wrote:
On Sep 13 19:47, John Carey wrote:
Anyway, it looks to me as if overwriting the path in an existing
VistaCwd instance would confuse RtlGetCurrentDirectory_U() and
probably other Win32 API functions. (It
On Sep 14 01:12, Corinna Vinschen wrote:
On Sep 13 19:47, John Carey wrote:
On Sep 11 03:30, Corinna Vinschen:
Anyway, it looks to me as if overwriting the path in an existing
VistaCwd instance would confuse RtlGetCurrentDirectory_U() and
probably other Win32 API functions. (It may be
On Sep 14 17:39, John Carey wrote:
On Sep 14 01:12, Corinna Vinschen wrote:
On Sep 13 19:47, John Carey wrote:
On Sep 11 03:30, Corinna Vinschen:
Anyway, it looks to me as if overwriting the path in an existing
VistaCwd instance would confuse RtlGetCurrentDirectory_U() and
probably
On Sep 14 20:59, Corinna Vinschen wrote:
On Sep 14 17:39, John Carey wrote:
On Sep 14 01:12, Corinna Vinschen wrote:
Hmm, I'm still wondering. In theory we don't have to replace the
directory name. We just have to InterlockedExchange the handle, since
we only need to replace the
On Sep 14 09:11, Corinna Vinschen wrote:
I applied the below patch to Cygwin CVS and it appears to work nicely.
The only potential race I can think of is, if another thread of the same
Cygwin process calls SetCurrentDirectory. I'm inclined to let this
situation slip through the cracks since
On Sep 14 12:02, Corinna Vinschen wrote:
True. Implementing a full replacement for SetCurrentDirectory as in
your PoC is still an option. However, I can't do that anymore since
I'm tainted by reading your code. If you would contemplate to sign
a copyright assignment(**), we could create a
On Sep 11 03:30, Corinna Vinschen:
On Sep 11 00:12, John Carey wrote:
The proof-of-concept code follows (and is also attached). It includes
an analysis of what is going on--to the extent that I know what is going
on, of course. Please let me know what you think.
First of all, I'm
On Sep 13 12:47, John Carey wrote:
On Sep 11 03:30, Corinna Vinschen:
Can't we find Cwd by scanning the .data segment of ntdll.h for the
address we inferred from the Params.CurrentDirectoryName.Buffer value?
Nice; that might work. But there would need to be some kind of rule
to pick a
On Sep 13, John Carey wrote:
It's not one of those, or even the subroutine that those share. I don't know
how they relate.
...
(incorrect quotation omitted)
My apologies for using the wrong quotation format. Sorry!
-- John
--
Problem reports: http://cygwin.com/problems.html
FAQ:
On Sep 11 00:12, John Carey wrote:
On Sep 04 02:26 Corinna Vinschen wrote:
The problem only starts with Vista. I have no objections to use
undocumented features, if they work. If there's any way to replace the
cwd handle with our own *and* keep the Win32 API happy, I'll take it.
I
Btw...
On Sep 11 00:12, John Carey wrote:
// The real SetCurrentDirectory () implementation calls
// a non-exported function that appears to expand relative
// paths to absolute paths and convert / to \. It might
// also do other things.
Isn't that just one of
On Sep 04 02:26 Corinna Vinschen wrote:
On Sep 3 16:18, John Carey wrote:
On Sep 03 12:37 Corinna Vinschen wrote:
On Sep 2 23:32, John Carey wrote:
In Aug 17 10:15, Corinna Vinschen wrote:
I just released 1.7.6-1.
...
What changed since Cygwin 1.7.5:
On Sep 3 16:18, John Carey wrote:
On Sep 03 12:37 Corinna Vinschen wrote:
On Sep 2 23:32, John Carey wrote:
In Aug 17 10:15, Corinna Vinschen wrote:
I just released 1.7.6-1.
...
What changed since Cygwin 1.7.5:
- Cygwin handles the
On Sep 3 17:36, Andy Koppe wrote:
On 3 September 2010 08:37, Corinna Vinschen wrote:
I still don't like the final workaround, which is, to set the Win32 CWD
to the Cygwin CWD. It would be nice if we could revert that change to
the pre-1.7.6 behaviour in a Vista-friendly way. If you ever
On Sep 2 23:32, John Carey wrote:
On Aug 12 01:11, Corinna Vinschen wrote:
On Aug 12 06:54, Andy Koppe wrote:
On 11 August 2010 20:55, John Carey wrote:
So is your idea that if SetCurrentDirectory() fails because
of path length or permissions, then Cygwin would just accept
the
On Sep 03 12:37 Corinna Vinschen wrote:
On Sep 2 23:32, John Carey wrote:
In Aug 17 10:15, Corinna Vinschen wrote:
I just released 1.7.6-1.
...
What changed since Cygwin 1.7.5:
- Cygwin handles the current working directory entirely on its own.
On 3 September 2010 08:37, Corinna Vinschen wrote:
I still don't like the final workaround, which is, to set the Win32 CWD
to the Cygwin CWD. It would be nice if we could revert that change to
the pre-1.7.6 behaviour in a Vista-friendly way. If you ever find out
how to make sure that the new
On Aug 12 01:11, Corinna Vinschen wrote:
On Aug 12 06:54, Andy Koppe wrote:
On 11 August 2010 20:55, John Carey wrote:
So is your idea that if SetCurrentDirectory() fails because
of path length or permissions, then Cygwin would just accept
the failure and keep an internal record the
On Aug 12 06:54, Andy Koppe wrote:
On 11 August 2010 20:55, John Carey wrote:
On Aug 11 01:49 Corinna Vinschen wrote:
there's no Win32-safe way to set a new
directory handle as cwd in Vista and later anymore. Since there's no
official API to set the cwd using a directory handle, there's
On Aug 10 21:53, John Carey wrote:
On Aug 10 13:44 +0200 Corinna Vinschen wrote:
chdir (/);
h = CreateFile (foobar, ...);
if (h == INVALID_HANDLE_VALUE) printf (%lu\n, GetLastError());
Thanks for the test case for the CreateFile() problem; I used it to
create the following test,
Greetings, Al Slater!
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/08/2010 09:57, Andrey Repin wrote:
Greetings, John Carey!
After a call to SetCurrentDirectory(), I have seen occasional ( 5%)
failures of CreatePipe() with code ERROR_INVALID_HANDLE. I have also seen
failure of
On 8/10/10 10:44 PM, Christopher Faylor wrote:
On Tue, Aug 10, 2010 at 09:53:46PM +, John Carey wrote:
Thanks for the test case for the CreateFile() problem; I used it to
create the following test, in which Windows 7 CreateFile() fails with
ERROR_INVALID_HANDLE even when using a stock
On Aug 11 04:05, Daniel Colascione wrote:
On 8/10/10 10:44 PM, Christopher Faylor wrote:
On Tue, Aug 10, 2010 at 09:53:46PM +, John Carey wrote:
Thanks for the test case for the CreateFile() problem; I used it to
create the following test, in which Windows 7 CreateFile() fails with
On Wed, Aug 11, 2010 at 04:05:32AM -0700, Daniel Colascione wrote:
On 8/10/10 10:44 PM, Christopher Faylor wrote:
On Tue, Aug 10, 2010 at 09:53:46PM +, John Carey wrote:
Thanks for the test case for the CreateFile() problem; I used it to
create the following test, in which Windows 7
On Aug 11 01:49 Corinna Vinschen wrote:
On Aug 10 21:53, John Carey wrote:
Now, where is Windows stuffing the extra copy of the directory handle?
In those reference-counted heap-allocated directory objects. Stepping
through the machine code under Windows 7 I see SetCurrentDirectory()
On 11 August 2010 20:55, John Carey wrote:
On Aug 11 01:49 Corinna Vinschen wrote:
there's no Win32-safe way to set a new
directory handle as cwd in Vista and later anymore. Since there's no
official API to set the cwd using a directory handle, there's no way to
set the Win32 cwd to a
Greetings, John Carey!
After a call to SetCurrentDirectory(), I have seen occasional ( 5%)
failures of CreatePipe() with code ERROR_INVALID_HANDLE. I have also seen
failure of Cygwin signal handling because the signal handling pipe has
mysteriously closed.
Seems like it was discussed a
On Aug 10 00:19, John Carey wrote:
After a call to SetCurrentDirectory(), I have seen occasional ( 5%)
failures of CreatePipe() with code ERROR_INVALID_HANDLE. I have also
seen failure of Cygwin signal handling because the signal handling
pipe has mysteriously closed.
Why on earth are you
Greetings to you as well! I did try to search, but was unsuccessful. Can you
tell me the subject of one of the messages?
Thanks,
John
Subject: Re: 1.7.5: Occasional failure of CreatePipe or signal handing due to
thread-unsafe code in cwdstuff::set
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/08/2010 09:57, Andrey Repin wrote:
Greetings, John Carey!
After a call to SetCurrentDirectory(), I have seen occasional ( 5%)
failures of CreatePipe() with code ERROR_INVALID_HANDLE. I have also seen
failure of Cygwin signal handling
On Aug 10 13:44 +0200 Corinna Vinschen wrote:
On Aug 10 00:19, John Carey wrote:
...
Presumably the issues mentioned in the source comment may
also occur, but what I have seen myself is a subsequent call to
SetCurrentDirectory() closing, not the current directory handle, but
the handle
On Tue, Aug 10, 2010 at 09:53:46PM +, John Carey wrote:
Thanks for the test case for the CreateFile() problem; I used it to
create the following test, in which Windows 7 CreateFile() fails with
ERROR_INVALID_HANDLE even when using a stock Cygwin 1.7.5 DLL:
As Corinna said: If you are mixing
After a call to SetCurrentDirectory(), I have seen occasional ( 5%) failures
of CreatePipe() with code ERROR_INVALID_HANDLE. I have also seen failure of
Cygwin signal handling because the signal handling pipe has mysteriously closed.
I believe that both symptoms are due to this code in
37 matches
Mail list logo