This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

1.5.18-1 + coreutils 5.3.0 + DFS/widelinks => bug?

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!

-- Unsubscribe info: Problem reports: Documentation: FAQ:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]