Mail Archives: cygwin/2010/08/11/07:26:46
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 +0000, 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 Windows calls with cygwin calls you
> > are far into unsupported territory. Cygwin isn't designed to let you
> > seamlessly intermix things like pthreads/signals and the Windows API
> > functions.
>
> Then it seems the website needs to be updated. One of the major selling
> points of Cygwin, as it were, is the ability to interact with the
> Windows API world as well as the POSIX one: "Because processes run under
> the standard Win32 subsystem, they can access both the UNIX
> compatibility calls provided by Cygwin as well as any of the Win32 API
> calls. This gives the programmer complete flexibility in designing the
> structure of their program in terms of the APIs used. For example, they
> could write a Win32-specific GUI using Win32 API calls on top of a UNIX
> back-end that uses Cygwin."
>
> I can understand requiring that users not deliberately create
> inconsistencies between Cygwin data structures and those of Windows (and
> I can understand throwing people who do that to the wolves), but
> CreateFile is a fundamental system facility that should always work,
> even in a Cygwin process.
There's a problem, and the current problem is a typical representation
for this, so let's stick to this example.
In Cygwin it is possible to chdir to a directory to which you can't cd
using the SetCurrentDirectory call. If you're an administrator, you
have BACKUP_NAME privileges. So you can access files in directories
which don't give you this permission usually, just like a root user on
Linux.
Unfortunately the SetCurrentDirectory call doesn't support this. It
only takes a Win32 pathname which is subsequently opened without providing
the FILE_FLAG_BACKUP_SEMANTICS flag. So, while you can *open* files in
such a dir using the FILE_FLAG_BACKUP_SEMANTICS flag, you can't set your
CWD to it when using the Win32 API.
Another exmaple: Windows supports path of up to 32768 bytes. However,
the Win32 CWD can have a maximum length of 259 chars. Even when using
the UNICODE API!
None of these restriction exist for Cygwin applications *iff* they use
the POSIX API.
So, what if a Cygwin application chdir'ed into such a directory
successfully? If I change back Cygwin to use SetCurrentDirectory
to keep the Win32 API in sync, the call will fail in the first example,
while the second example is never supported in the Win32 API.
In effect, the POSIX API CWD is now a different one than the Win32 API
CWD.
So, what does sticking to Win32 compatibility mean?
Does that mean we have still the right to make the POSIX API as good as
possible, thus risking that CreateFile with a relative filename fails or
accesses another file than the POSIX open call?
Or does that mean we have to revert all these changes since we don't
have the right to provide better or more functionality in the POSIX API
if it potentially breaks the Win32 API?
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
- Raw text -