# Git for Windows: mingw.c's strange usage of creation time as ctime?

3 messages from 2017-10-04 to 2017-10-04. Participants: Marc Strapetz, Jonathan Nieder.
Thread: https://gitlist.dev/t/46897

## Marc Strapetz, 2017-10-03 22:29

Subject: Git for Windows: mingw.c's strange usage of creation time as ctime?
Message-ID: <08983090-07d2-cfe4-dd90-ab4887b83893@syntevo.com>
URL: https://gitlist.dev/e/08983090-07d2-cfe4-dd90-ab4887b83893%40syntevo.com

```
compat/mingw.c assigns the Windows file creation time [1] to Git's ctime 
fields at line 591 and at line 705:

buf->st_ctime = filetime_to_time_t(&(fdata.ftCreationTime));

ftCreationTime > ftLastWriteTime is actually possible after copying a 
file, so it makes sense to include this timestamp somehow in the Index, 
but I think it would be better to use the maximum of ftLastWriteTime and 
ftCreationTime here which is less confusing and closer to Unix's ctime:

buf->st_ctime = max(buf->st_mtime,
                     filetime_to_time_t(&(fdata.ftCreationTime));

-Marc

[1] 
https://msdn.microsoft.com/en-us/library/windows/desktop/aa365739(v=vs.85).aspx


```

## Jonathan Nieder, 2017-10-04 02:23

Subject: Re: Git for Windows: mingw.c's strange usage of creation time as ctime?
Message-ID: <20171004022352.GJ19555@aiede.mtv.corp.google.com>
URL: https://gitlist.dev/e/20171004022352.GJ19555%40aiede.mtv.corp.google.com
In-Reply-To: <08983090-07d2-cfe4-dd90-ab4887b83893@syntevo.com>

```
+git-for-windows
Hi Marc,

Marc Strapetz wrote:

> compat/mingw.c assigns the Windows file creation time [1] to Git's
> ctime fields at line 591 and at line 705:
>
> buf->st_ctime = filetime_to_time_t(&(fdata.ftCreationTime));
>
> ftCreationTime > ftLastWriteTime is actually possible after copying
> a file, so it makes sense to include this timestamp somehow in the
> Index, but I think it would be better to use the maximum of
> ftLastWriteTime and ftCreationTime here which is less confusing and
> closer to Unix's ctime:
>
> buf->st_ctime = max(buf->st_mtime,
>                     filetime_to_time_t(&(fdata.ftCreationTime));

Can you say more about the practical effect?  Is this causing a bug in
practice, is it a bug waiting to happen, or is it making the code
difficult to understand without any ill effect expected at run time?
(Any of those three is a valuable kind of feedback to offer --- I'm
just trying to figure out which one you mean.)

By the way, do you have core.trustctime set to true or false?

Thanks,
Jonathan

> -Marc
>
> [1] https://msdn.microsoft.com/en-us/library/windows/desktop/aa365739(v=vs.85).aspx

```

## Marc Strapetz, 2017-10-04 07:57

Subject: Re: Git for Windows: mingw.c's strange usage of creation time as ctime?
Message-ID: <6e1afdc2-2edb-8060-87b0-7d2ced201e02@syntevo.com>
URL: https://gitlist.dev/e/6e1afdc2-2edb-8060-87b0-7d2ced201e02%40syntevo.com
In-Reply-To: <20171004022352.GJ19555@aiede.mtv.corp.google.com>

```
Hello Jonathan,

On 04.10.2017 04:23, Jonathan Nieder wrote:
> +git-for-windows
> Hi Marc,
> 
> Marc Strapetz wrote:
> 
>> compat/mingw.c assigns the Windows file creation time [1] to Git's
>> ctime fields at line 591 and at line 705:
>>
>> buf->st_ctime = filetime_to_time_t(&(fdata.ftCreationTime));
>>
>> ftCreationTime > ftLastWriteTime is actually possible after copying
>> a file, so it makes sense to include this timestamp somehow in the
>> Index, but I think it would be better to use the maximum of
>> ftLastWriteTime and ftCreationTime here which is less confusing and
>> closer to Unix's ctime:
>>
>> buf->st_ctime = max(buf->st_mtime,
>>                      filetime_to_time_t(&(fdata.ftCreationTime));
> 
> Can you say more about the practical effect?  Is this causing a bug in
> practice, is it a bug waiting to happen, or is it making the code
> difficult to understand without any ill effect expected at run time?

It's mainly about understanding: as a Windows guy it is quite tempting 
to read "ctime" as "creationTime" and getting this confirmed in code 
above. (I guess) based on this understanding I wrote wrong Java code 8 
years ago for all platforms. My bad of course that I was not digging 
into Unix sources here.

In practice, .git/index timestamps will become more similar to Linux, 
getting rid of "strange" old ctime values.

Drawback will be that after such a code update every Index entry will 
appear as outdated and the initial "git status" will have to compare all 
file contents. If this is not acceptable, a comment for the two 
offending lines would make sense.

> By the way, do you have core.trustctime set to true or false?

It seems to be set to true by default on Windows and usually I'm not 
changing it.

-Marc




```