X-Spam-Check-By: sourceware.org X-Envelope-From: X-Envelope-To: Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: 1.5.21-1: CIFS symlinks on network share break Cygwin Date: Tue, 24 Oct 2006 11:08:42 -0700 Message-ID: In-Reply-To: <20061024102745.GV8323@calimero.vinschen.de> From: "Jonathan Lanier" To: X-Spam-Score: -11.44 () ALL_TRUSTED,USER_IN_WHITELIST X-BorderEnvelope-To: X-IsSubscribed: yes Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id k9OIAlSW001768 > 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: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/