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

["Jonathan Lanier" <jonathan_lanier at naughtydog dot com>]

(PCYMTNQREAIYR, TOFU, grokked; apologies - haven't been on this list for
about 9 years...)

>> 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.

That's certainly useful information - I wasn't sure if that was the
case.

>>  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.

Again, that's useful information; I wasn't sure if Cygwin internally
performed some kind of startup action before executing the main
application that might involve spawning a new process with different
attributes.

> If at all, it has something to do with opening files.

Don't think so; GetFileAttributes doesn't involve opening a file.  In
fact, if you open the file and check the stats of the handle, I think it
actually returns the correct information, since the symlink has been
traversed at that point.

> Still, the effect is not reproducible with Samba shares.

Agreed, but that doesn't mean there isn't a problem.  :)

> Nevertheless, Cygwin application on a Windows client don't
> see anything of this.  They see the same as any native
> Windows application.

If you ran my test app against a CIFS server you'd see that this is
clearly not the case.  I even included TTY output showing the
discrepancy between a Cygwin and a non-Cygwin app; same machine, same
network, same server, same file, same symlink.  That's really the whole
crux of the problem I'm having.

> Cygwin does not implement it's own SMB/CIFS file access, it just uses
Win32 resp. NT system
> calls.

I'm fully aware of that; in fact that's why in my test app I
deliberately called the GetFileAttributes API function directly, just to
see what response I would get from the kernel.  Again, I'm getting a
different response when calling the XP kernel directly from a Cygwin app
than I do from a non-Cygwin app.  Yes, this is weird; yes, it defies
expectation.  Nevertheless, I can only demonstrate that the problem
exists, and hope that the root of the problem can be discovered by
analysis.

> That's why I think that the CIFS server is getting something wrong
here.

The CIFS server doesn't know if the app running is a Cygwin app or not.
How could it possibly modify its response based on information it has no
access to?  A more likely explanation would be that CIFS is capable of
reporting either set of information (the symlink or its target), and the
XP SMB client is deciding which one to query based on some condition
that we are currently unaware of.  I could be completely wrong, but
again, I can't imagine how CIFS could possibly know what flavor of app
I'm running.

> 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?

Since no I/O error has occurred, it's not likely; logging all normal I/O
requests on a server like this would probably be quite a burden.  I
would expect it would only log exceptional events.  I can ask my IT
director, but I honestly wouldn't expect much from this.

To be perfectly clear on this, I'm not accusing Cygwin of having a bug
(though I am not yet ruling it out).  I honestly think some evil magic
is happening inside the XP kernel that is having a negative effect on
the operation of Cygwin, and I am willing to help track it down, and I
would like whatever support the Cygwin community is willing to give me
in doing so.  I think it can only benefit Cygwin if its compatibility is
improved; correct operation with CIFS would be a very important feature
requirement, IMHO, and it would certainly help me, since I need this.
:)  Even though the networking layer is technically outside the scope of
Cygwin's domain, if the Windows kernel is implementing evil magic that
negatively affects Cygwin, then Cygwin must contain Mojo to counter the
evil magic.  I know that this would not be the first case, as a quick
scan of Cygwin's source code indicates the presence of much Mojo
already.  :)

When I next get some free time, I will attempt to revert to the older
version of Cygwin that works and progress forward through the
cygwin1.dll history until I can determine when it breaks.  I probably
will not be able to get to that until the weekend.  If anyone could
direct me to an ftp or http archive of the older Cygwin distributions,
it would be much appreciated.  Thanks!

- Jonathan Lanier

--
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/