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