This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: 1.5.21-1: CIFS symlinks on network share break Cygwin

> I can't help to think this is a bug in the CIFS server, rather than a
bug in Cygwin.

That is a tempting conclusion to reach; unfortunately I don't think it's
the right one, nor do I think this bug has to blamed on just one or the
other.  Notice that I ran these tests 3 times, each compiled in a
different way.  Note that the GetFileAttributes function, which I assume
is imported directly from KERNEL32.DLL, is returning different values on
the same machine with the same network connection depending on whether
or not the application is running under Cygwin.  I used "gcc
filetest.cpp" and "gcc -mno-cygwin filetest.cpp" and got different
results.  If the Cygwin runtime isn't performing any tricks to hook the
kernel functions, then I only assume some magic must be happening inside
Windows XP itself that changes the behavior of the basic KERNEL32 file
system API functions.  Somehow, Windows XP has decided that Cygwin apps
should see different results when looking at symlinks on a CIFS share;
something must be responsible for this.

I also don't think the CIFS server can be blamed, if only because the
standard non-Cygwin Win32 applications calling the exact same KERNEL32
functions report the correct information.  Also, because (I know the FAQ
says not to say this, but I think it's useful information in this case)
we have a much older version of Cygwin (cygcheck reports v1.5.14) that
works flawlessly with CIFS and does not suffer the same problems.  So,
at the very least, it appears that something changed in Cygwin that is
now exposing the undesired behavior.  This is not meant to imply it's a
bug in Cygwin per se - more likely, since it's the KERNEL32 API that is
returning unexpected results, something has changed in Cygwin that is
triggering incorrect behavior in the WinXP kernel itself.

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; not too
hard to believe, since Microsoft has clearly expressed an interest in
improving Unix compatibiliy in future Windows OSes to more favorably
compete, and they're clearly adding symlink support to Vista, which is
expected to work seamlessly with CIFS.  So, maybe the SMB client behaves
differently even under WinXP when connecting to CIFS for more advanced
SFU support.  However, as I said, I double-checked the PE headers and
the application type is definitely not marked as Posix.  I'm not sure if
there's any other code to check; maybe internally Cygwin is forking a
process that is inheriting some undesired Posix attribute?

I'm happy to run any kind of test or diagnostic on my machine to help
narrow down the problem; unfortunately, since I am in a production
environment, I'm very limited in what I can do with the CIFS server.

- Jonathan Lanier

Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]