Use nanosecond-precision file times on Windows #53
Conversation
In our fstat() emulation, we convert the file metadata from Win32 data structures to an emulated POSIX structure. To structure the code better, let's factor that part out into its own function. Note: it would be tempting to try to unify this code with the part of do_lstat() that does the same thing, but they operate on different data structures: BY_HANDLE_FILE_INFORMATION vs WIN32_FILE_ATTRIBUTE_DATA. So unfortunately, they cannot be unified. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
fstat() is the only stat-related CRT function for which we don't have a full replacement yet (and thus the only reason to stick with MSVCRT's 'struct stat' definition). Fully implement fstat(), in preparation of implementing a POSIX 2013 compatible 'struct stat' with nanosecond-precision file times. This allows us also to implement some clever code to handle pipes and character devices in our own way. Signed-off-by: Karsten Blees <blees@dcon.de> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
We no longer use any of MSVCRT's stat-functions, so there's no need to stick to a CRT-compatible 'struct stat' either. Define and use our own POSIX-2013-compatible 'struct stat' with nanosecond- precision file times. Note: This can cause performance issues when using Git variants with different file time resolutions, as the timestamps are stored in the Git index: after updating the index with a Git variant that uses second-precision file times, a nanosecond-aware Git will think that pretty much every single file listed in the index is out of date. Signed-off-by: Karsten Blees <blees@dcon.de> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho
changed the title
|
/submit |
|
Submitted as pull.53.git.gitgitgadget@gmail.com |
|
Found multiple candidates in gitster/git: Using the first one. |
|
This branch is now known as |
|
This patch series was integrated into pu via git@84a5436. |
|
This patch series was integrated into next via git@4563a0d. |
|
Found multiple candidates in gitster/git: Using the first one. |
|
This branch is now known as |
|
This patch series was integrated into pu via git@49ea0d6. |
|
Found multiple candidates in gitster/git: Using the first one. |
|
This branch is now known as |
|
This patch series was integrated into pu via git@b9c3f06. |
|
This patch series was integrated into next via git@b9c3f06. |
|
This patch series was integrated into master via git@b9c3f06. |
|
Closed via b9c3f06. |
|
Found multiple candidates in gitster/git: Using the first one. |
|
This branch is now known as |
|
This patch series was integrated into pu via git@b9c3f06. |
|
This patch series was integrated into next via git@b9c3f06. |
|
This patch series was integrated into master via git@b9c3f06. |
|
Closed via b9c3f06. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This is yet another patch series in the slow wave of patches coming over from Git for Windows.
With this change, we now use preciser timestamps to determine e.g. whether the Git index is out of date. This change made it into Git for Windows already in version 2.6.0, i.e. for a little over three years.
Please note that this change originally caused a lot of trouble, as e.g. libgit2 was unaware of our plans and used second-precision file times. So if you used Git for Windows as well as a libgit2-based program to, say, update the Git index, there would be a back-and-forth between index updates with and without the fractional second parts, causing quite a bit of bad performance.
These issues have been ironed out long ago, though, so it is high time to contribute these patches to core Git.