X-Spam-Check-By: sourceware.org
Date: Tue, 24 Oct 2006 12:27:45 +0200
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: 1.5.21-1: CIFS symlinks on network share break Cygwin
Message-ID: <20061024102745.GV8323@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <E173C70E3D81F74188D2778B96C5CD0D69FF3C AT postal1-dog DOT naughtydog DOT com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <E173C70E3D81F74188D2778B96C5CD0D69FF3C@postal1-dog.naughtydog.com>
User-Agent: Mutt/1.4.2i
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

On Oct 22 22:56, Jonathan Lanier wrote:
> Brief summary, before I get into details:  Cygwin 1.5.21-1 on WinXP SP2
> was working perfectly, until a new CIFS server was installed on our LAN.
> [...]
>   The common factor to
> all failures: they are all symbolic links on the CIFS server.  Typical
> failure modes were as follows:
> [...]
> Y:\test>vcfiletest y:\dirsymlink
> Checking file "y:\dirsymlink"...
> GetFileAttributesEx(): attr=0x00000010, size=0
> stat(): mode=0x41ff, size=0
> 
> Y:\test>vcfiletest y:\filesymlink.exe
> Checking file "y:\filesymlink.exe"...
> GetFileAttributesEx(): attr=0x00000020, size=290816
> stat(): mode=0x81ff, size=290816
> 
> Y:\test>mingwfiletest y:\dirsymlink
> Checking file "y:\dirsymlink"...
> GetFileAttributesEx(): attr=0x00000010, size=0
> stat(): mode=0x41ff, size=0
> 
> Y:\test>mingwfiletest y:\filesymlink.exe
> Checking file "y:\filesymlink.exe"...
> GetFileAttributesEx(): attr=0x00000020, size=290816
> stat(): mode=0x81ff, size=290816
> 
> Y:\test>cygfiletest y:\dirsymlink
> Checking file "y:\dirsymlink"...
> GetFileAttributesEx(): attr=0x00000080, size=25
> stat(): mode=0x41ed, size=0
> 
> Y:\test>cygfiletest y:\filesymlink.exe
> Checking file "y:\filesymlink.exe"...
> GetFileAttributesEx(): attr=0x00000080, size=43
> stat(): mode=0x81ed, size=43
> 
> Interesting points to note: If the executable symlink is renamed to
> remove its extension, the file size reported returns to the orignal
> expected size.  [...]

I can't help to think this is a bug in the CIFS server, rather than a
bug in Cygwin.  Cygwin uses the GetFileAttributes function as every
other Win32 application and if the CIFS server returns 0x80 instead of
0x10 for a symlink to a directory, there's nothing Cygwin can do about
that.  Same goes for the weird file behaviour.  Cygwin uses normal Win32
and native NT system calls, nothing unusual.  Somehow the server doesn't
seem to recognize the machine as a Windows client when an access from
Cygwin occurs.

I tested this with a Samba server and these effects simply don't occur.
A symlink is resolved to the symlink target before the information is
returned to the Windows machine.  Cygwin sees a directory or a file when
accessing the symlink, and the file size is correct, too, regardless of
the suffix.


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/