GNU bug report logs -
#13347
stat/fstat inappropriately used in cp, install, rm, sort, chown for Windows 7 platforms
Previous Next
Full log
Message #8 received at 13347 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
[adding gnulib]
On 01/03/2013 10:10 AM, Burkhardt, Glenn UTAS wrote:
> 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
> coreutils-5.97
>
> I noticed this when trying to use the "cp" command in a Clearcase locally hosted dynamic view.
Clearcase is notoriously buggy when it comes to POSIX compliance, and
I'm not surprised you are running into problems because of those bugs.
Since you paid for Clearcase (and coreutils is free), you might want to
consider reporting this issue upstream to the clearcase folks; then
again, since clearcase is closed source, I wouldn't hold out any hope
for them to fix their bugs.
> 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().
If that's the case, then perhaps the right thing to do is to modify
gnulib to replace fstat() on mingw so that it is always massaged to
provide the same st_dev as stat() (on mingw, gnulib is already doing
other things to track the original file name alongside every open fd, to
work around other bugs in POSIX compliance, so it wouldn't actually cost
that much extra).
>
> 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
Unfortunately, your patch cannot be accepted upstream as-is, as it would
violate POSIX semantics on systems that actually obey POSIX. But it
might be something that could be made conditional on whether things are
being targeted to mingw.
> http://sourceforge.net/tracker/?func=detail&aid=3590842&group_id=2435&atid=102435
>
> *** system.h.orig Mon Nov 26 16:54:58 2012
> --- system.h Wed Nov 28 18:15:04 2012
> ***************
> *** 535,542 ****
> #include "unlocked-io.h"
>
> #define SAME_INODE(Stat_buf_1, Stat_buf_2) \
> ! ((Stat_buf_1).st_ino == (Stat_buf_2).st_ino \
> ! && (Stat_buf_1).st_dev == (Stat_buf_2).st_dev)
>
> #define DOT_OR_DOTDOT(Basename) \
> (Basename[0] == '.' && (Basename[1] == '\0' \
> --- 535,541 ----
> #include "unlocked-io.h"
>
> #define SAME_INODE(Stat_buf_1, Stat_buf_2) \
> ! ((Stat_buf_1).st_ino == (Stat_buf_2).st_ino)
>
> #define DOT_OR_DOTDOT(Basename) \
> (Basename[0] == '.' && (Basename[1] == '\0' \
>
Also, while this patch is unlikely to go in as-is to upstream coreutils,
you may want to pursue getting it included into mingw and msys builds as
downstream distros affected by the need for the workaround.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[signature.asc (application/pgp-signature, attachment)]
This bug report was last modified 12 years and 165 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.