X-Spam-Check-By:	sourceware.org
Message-ID:	<BAY107-F192706D8E3C3F6DF46B8E0BA450@phx.gbl>
X-Sender:	ppchacker AT hotmail DOT com
From:	"PPC Hacker" <ppchacker AT hotmail DOT com>
To:	cygwin AT cygwin DOT com
Subject:	1.5.18-1 + coreutils 5.3.0 + DFS/widelinks => bug?
Date:	Fri, 09 Dec 2005 05:19:55 -0800
Mime-Version:	1.0
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
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

Hi --

I've hit a problem with cygwin 1.5.18-1 and "cp" from coreutils 5.3.0.

mark-dsktp:software% cp -a /tools/Cygwin/1.5.3-1/cygwin/tools/bin 
/home/mark/foobar
cp: skipping file `/tools/Cygwin/1.5.3-1/cygwin/tools/bin/p4.exe', as it was 
replaced while being copied
cp: skipping file `/tools/Cygwin/1.5.3-1/cygwin/tools/bin/find.exe', as it 
was replaced while being copied
cp: skipping file `/tools/Cygwin/1.5.3-1/cygwin/tools/bin/which.exe', as it 
was replaced while being copied

Looking at the source for coreutils, it does a stat() (or lstat(), not sure) 
on the source filename.  Later, after an open() on the source file, it does 
an fstat() on the filehandle.  If the dev or ino differ, it produces this 
message and aborts the copy.

Note that the "cp" fails only for *.exe files; all other files succeed.

/tools is cygwin-mounted from l:\tools\windows and "l:" is Windows-mounted 
from //fileserver1/drivemap which is a NetApp filer.

Digging further, and quickly realizing that no one else seems to have hit 
this problem, I traced it down to the "DFS" feature of the NetApp filer.  
DFS, aka "widelinks", is the Windows/CIFS equivalent of "automount".  If I 
replace the cygwin-mount for /tools to a real CIFS mount (the equivalent 
resolved automount), or, equivalently, if I use a UNC name to the real CIFS 
mount, everything works as expected.

I have only perused the cygwin source, but "dev" appears to be the result of 
the Windows API GetVolumeInformation().  So the natural explanation would be 
that GetVolumeInformation() gets confused by the automount and returns 
different values based on what segment of the pathname is used.

What I can't explain, and am hoping for some pointers on how to dig further, 
is why everything works as expected, except for files with an .exe 
extension.

Is there a second "internal cygwin" stat being done for these files (perhaps 
something to do with the "x" execute permission bit), which then ends up 
with a different "dev"?  Or, without as much guessing, is there anything 
special about stat() on .exe files in cygwin?

Is there anything special on the file server side with respect to .exe 
files?

At this point I have a work-around ("don't use DFS mounts").  But I'm still 
curious to dig one level deeper to understand why, and to understand if 
there might be a fixable bug which is causing this behavior.

Thanks for any help / information.

-- Rick

_________________________________________________________________
Don’t just search. Find. Check out the new MSN Search! 
http://search.msn.click-url.com/go/onm00200636ave/direct/01/


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

- Raw text -