Mail Archives: cygwin/2006/10/25/05:05:56
On Oct 24 11:08, Jonathan Lanier wrote:
> One completely wild guess would be that there is some attribute
> associated with the process that might expose the native symlinks,
> possibly for improved compatibility with SFU/Posix and CIFS;
Cygwin processes are ordinary Win32 processes, just linked against
cygwin1.dll. When calling GetFileAttibutes, it's the same function from
kernel32 as a non-Cygwin process calls.
> However, as I said, I double-checked the PE headers and
> the application type is definitely not marked as Posix.
Of course not. Cygwin is a POSIX emulation in the win32 namespace, it's
not a POSIX subsystem.
> maybe internally Cygwin is forking a
> process that is inheriting some undesired Posix attribute?
I'm not aware that such a flag would exist. Your example takes forking
out of the picture anyway since that doesn't happen when starting your
testcase from a cmd.exe prompt.
If at all, it has something to do with opening files. Still, the effect
is not reproducible with Samba shares. Samba has the capability to
support CIFS clients with CIFS UNIX extensions. This capability is
switched on by default. Nevertheless, Cygwin application on a Windows
client don't see anything of this. They see the same as any native
Windows application. Cygwin does not implement it's own SMB/CIFS file
access, it just uses Win32 resp. NT system calls. That's why I think
that the CIFS server is getting something wrong here. Before debugging
Cygwin to death, it would be interesting to learn the cause on the side
of the CIFS server. I assume there's something like logfiles or some
sort of support for this CIFS server?
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -