Menu
▾
▴
[MinGW-notify] [ mingw-Bugs-3590842 ] stat/fstat inappropriately used in cp.exe, install.exe
|
From: SF/projects/mingw n. l. <min...@li...> - 2013-01-07 14:27:03
|
Bugs item #3590842, was opened at 2012-11-28 16:05 Message generated for change (Comment added) made by gbburkhardt You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3590842&group_id=2435 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: non-mingw Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Glenn Burkhardt (gbburkhardt) Assigned to: Nobody/Anonymous (nobody) Summary: stat/fstat inappropriately used in cp.exe, install.exe Initial Comment: MINGW32_NT-6.1 BOS0DT-1QLS1R1 1.0.17(0.48/3/2) 2011-04-24 23:39 i686 Msys gcc version 4.7.0 (GCC) Windows 7 Enterprise SP1 I noticed this when trying to use the "cp" command in a Clearcase locally hosted dynamic view. When trying to copy a view private file, the 'cp' command would fail with a message like skipping file `jj', as it was replaced while being copied The problem is that the 'cp' command uses 'stat' on the source file initially, and then, when it's ready to copy, uses 'fstat' on it again, after the file has been opened for reading (about line 237 in copy.c from coreutils-5.97). This works on a file that's on a local hard drive, but not on a Clearcase locally hosted dynamic view. The 'install' command has the same problem. This test really shouldn't be done on a Windows platform. Microsoft's documentation describes different values for stat.st_dev returned by the 'stat()' and 'fstat()' functions. There's also a note that the stat.st_ino value is meaningless for NTFS filesystems. But then it gets interesting. The 'cp' command is built with a different version of 'stat' and 'fstat' than one normally gets with a MinGW build environment. The coreutils need the Msys build environment, and the 'stat/fstat' functions are pulled from libmsys-1.0.dll.a. A build in regular MinGW environment with the current compiler gets the functions from libmoldname.a. So were the coreutils built with gcc-4.7.0, and no libmsys-1.0.dll.a, the copy command would fail for files on the local hard drive, since stat.st_dev is different for stat() and fstat(). I've attached a small test program to show the stat()/fstat() output, and a patch for system.h in coreutils that allows a working version of 'cp.exe' and 'install.exe' to be built. ---------------------------------------------------------------------- >Comment By: Glenn Burkhardt (gbburkhardt) Date: 2013-01-07 06:27 Message: I'm not sure why you think the Coreutils maintainers should be contacted. The problem is with the MinGW implementation of 'stat' and 'fstat'. A secondary problem is that the tools are linked with a different implementation of 'stat'/'fstat' than normal application use. This affects a number of programs, include 'rm', 'chown', 'sort', and 'find'. ---------------------------------------------------------------------- Comment By: Glenn Burkhardt (gbburkhardt) Date: 2013-01-07 06:13 Message: I logged a bug report with the Coreutils maintainers: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13347 ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2012-11-29 08:22 Message: You'll need to supply your patch to the coreutils maintainers. Report back here with the results of you submission, either applied or not. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3590842&group_id=2435 |