Re: bug#13347: stat/fstat inappropriately used in cp, install, rm, sort, chown for Windows 7 platforms

[Eli Zaretskii]

> Date: Thu, 03 Jan 2013 11:38:47 -0700
> From: Eric Blake <address@hidden>
> Cc: Bug-gnulib <address@hidden>, address@hidden
> 
> > 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().

Sorry for chiming in, but are you saying that the 'cp' binary
sometimes dynamically links to the MSYS runtime and sometimes to the
native Windows runtime?  That is a sure way to disaster, as these two
runtimes are incompatible.  (MSYS is a fork of an old version of
Cygwin.)  A given binary should only ever use one of these, depending
on whether it was built as a MinGW program or an MSYS program.

If that's not the issue here, then why MSYS is relevant to the
discussion at all?  What am I missing?

> 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).

Actually, TRT would be to have a replacement for 'stat' and 'fstat'
that return the Windows equivalent of the inode, which is accessible
by a file handle or a descriptor.  The problem is that this also
requires to replace the definition of 'struct stat', since the
resulting inodes are 64-bit numbers, while a typical 'struct stat'
declares the inode as 'short' (why waste storage on something that is
always zero?)