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