Although the equivalent code in the VFSForGit Mac kext does not appear to do this, if we change the mtime of an empty (sparse) file when we populate it with actual contents (i.e., when we "hydrate" it because a user process has performed an open(2) call), this may confuse programs which have already performed a stat(2) to capture the file's modification time.
In particular, if the Vim editor is used to open a projected, empty file, and then the user tries to save changes to the file, Vim will report "this file has been changed" because the mtime is different than when Vim first performed its stat(2) prior to opening the file (which triggered our population of the file's contents, which then changed the mtime). So by attempting to preserve the original mtime of the empty file, we can generally avoid such confusion on the part of user processes.
Although the equivalent code in the VFSForGit Mac kext does not appear to do this, if we change the mtime of an empty (sparse) file when we populate it with actual contents (i.e., when we "hydrate" it because a user process has performed an
open(2)call), this may confuse programs which have already performed astat(2)to capture the file's modification time.In particular, if the Vim editor is used to open a projected, empty file, and then the user tries to save changes to the file, Vim will report "this file has been changed" because the mtime is different than when Vim first performed its
stat(2)prior to opening the file (which triggered our population of the file's contents, which then changed the mtime). So by attempting to preserve the original mtime of the empty file, we can generally avoid such confusion on the part of user processes.