Re: [PATCH] Add a new lstat and fstat implementation based on Win32 API

On 04/09/07, Rutger Nijlunsing [off-list ref] wrote:

On Tue, Sep 04, 2007 at 01:57:38PM +0100, Johannes Schindelin wrote:

quoted

Hi,

On Tue, 4 Sep 2007, Johannes Schindelin wrote:

quoted

On Tue, 4 Sep 2007, Johannes Sixt wrote:

quoted

Johannes Schindelin schrieb:

quoted

On Tue, 4 Sep 2007, Johannes Sixt wrote:

quoted

Therefore, I've pushed out a fixup patch at the top of mingw.git's
devel branch that converts mtime to local time

On Linux, we compare to UTC to begin with, right?  We should do that
here, too...  So if time(NULL) does not return UTC on MinGW, we have
to wrap that function, too.

According to MSDN, time(NULL) returns "the number of seconds elapsed
since [epoch] according to the system clock". Please don't ask me what
"the system clock" is.

I think I know.  From my QEmu adventures I know that DOS/Windows expects
the system clock to be set to local time, in contrast to _all_ other
operating systems.

Now I am utterly confused.  MSDN says

      FILETIME

      Contains a 64-bit value representing the number of 100-nanosecond
      intervals since January 1, 1601 (UTC).

Hmm.

[Warning: war stories ahead...]

If you really, really want to know more:

http://search.cpan.org/~shay/Win32-UTCFileTime-1.45/lib/Win32/UTCFileTime.pm

Hmm, this may explain something that I have been observing on
Windows+cygwin. When I run `git diff`, I sometimes get it reporting
that all (from what I can tell) files have changed, like a `find .
-type f -exec touch {} \;` command was run.

I was going to report this on a new thread, but this looks like a more
relevant place to do so.

My Windows machine is currently in Daylight Savings Time mode, and
from my observations, I have only seen this repeat first thing the
next day. I am not sure why, but every 24hrs, it looks as if the file
time reported by and checked from git is different to that reported by
stat.

I have not had time yet to play around with the mingw port and this
new stat implementation to see if it addresses this issue.

- Reece