bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: bug#13347: stat/fstat inappropriately used in cp, install, rm, sort,


From: Burkhardt, Glenn UTAS
Subject: RE: bug#13347: stat/fstat inappropriately used in cp, install, rm, sort, chown for Windows 7 platforms
Date: Mon, 7 Jan 2013 14:09:35 +0000


> -----Original Message-----
> From: Eli Zaretskii [mailto:address@hidden
> Sent: Sunday, January 06, 2013 11:54 AM
> To: Eric Blake
> Cc: Burkhardt, Glenn UTAS; address@hidden; address@hidden
> Subject: Re: bug#13347: stat/fstat inappropriately used in cp, install, rm, 
> sort,
> chown for Windows 7 platforms
> 
> > 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?

The MinGW folks have their own problems, of course.  I made that note only 
because if one tries using the test code I supplied, the result from stat/fstat 
will be different than what MinGW's 'cp' command gets, since the 'cp' command 
uses a different stat/fstat implementation than one gets using creating a new 
program in a standard way.

I started exploring this problem by building 'cp.exe' using MinGW's build 
script.  When I discovered the stat/fstat problem, I tried duplicating it with 
a simple test program.  But the st_ino/st_dev values for my program were 
different that what 'cp.exe' got on the same files.

The comment is only relevant for testing in the MinGW environment.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]