Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#1680 stat/fstat inappropriately used in cp.exe, install.exe

OTHER
closed
nobody
non-mingw (19)
Support
invalid
Unknown
False
2013-02-11
2012-11-29
Glenn Burkhardt
No

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.

Discussion

  •  
    Attachments
  •  
    Attachments
  • Earnie Boyd
    Earnie Boyd
    2012-11-29

    • labels: 3981041 --> non-mingw
    • status: open --> pending
     
  • Earnie Boyd
    Earnie Boyd
    2012-11-29

    You'll need to supply your patch to the coreutils maintainers. Report back here with the results of you submission, either applied or not.

     
    • status: pending --> open
     
  • 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'.

     
  • Earnie Boyd
    Earnie Boyd
    2013-01-07

    I've looked at the conversation in the bug report.

    The native runtime from MSVCRT.DLL is something we cannot control. The stat/fstat functions are supplied by Microsoft and cannot be changed. If you're building coreutils in a native environment requiring MSVCRT.DLL then you'll need to resolve the issues brought up by that or apply some patches you might find in other projects. Note that libmoldname.a is a mapping of things like _stat to a name without the underscore. It was created in light of the names normally used by POSIX anc can be eliminated by defining _NO_OLDNAMES but then you'll need to make sure you use the underscore in the function name.

    This is not an issue we can help you with.

     
  • The only reason I've been building Coreutils is because the release versions have flaws, due to their expectation that a fully usable implementation of stat/fstat is available. If by design MinGW uses the native MS versions without modification, then it would seem appropriate to modify utilities that rely on stat/fstat to accommodate platform idiosyncrasies. I agree also that it would be best if the Coreutil maintainers would incorporate the platform specific support. But MinGW builds do patch the standard utility code, and this might be another case that needs to be handled.

     
  • Earnie Boyd
    Earnie Boyd
    2013-02-11

    • status: open --> closed
    • milestone: --> OTHER
    • type: --> Support
    • resolution: --> invalid
    • category: --> Unknown
    • patch_attached: --> False
     
  • Earnie Boyd
    Earnie Boyd
    2013-02-11

    The delivered cp is bound to the MSYS runtime. The issue being presented is one of using MSVCRT runtime instead of MSYS. We cannot control how the OS vendor creates its functions. If you can prove an issue with MSYS runtime then we have an issue. As is this issue is closed since there is little we can do with it.