Show More
@@ -1823,29 +1823,12 b' class workingctx(committablectx):' | |||||
1823 | s = self[f].lstat() |
|
1823 | s = self[f].lstat() | |
1824 | mode = s.st_mode |
|
1824 | mode = s.st_mode | |
1825 | size = s.st_size |
|
1825 | size = s.st_size | |
1826 | file_mtime = timestamp.mtime_of(s) |
|
1826 | file_mtime = timestamp.reliable_mtime_of(s, mtime_boundary) | |
1827 |
|
|
1827 | if file_mtime is not None: | |
1828 |
|
1828 | cache_info = (mode, size, file_mtime) | ||
1829 | file_second = file_mtime[0] |
|
1829 | fixup.append((f, cache_info)) | |
1830 | boundary_second = mtime_boundary[0] |
|
1830 | else: | |
1831 | # If the mtime of the ambiguous file is younger (or equal) |
|
|||
1832 | # to the starting point of the `status` walk, we cannot |
|
|||
1833 | # garantee that another, racy, write will not happen right |
|
|||
1834 | # after with the same mtime and we cannot cache the |
|
|||
1835 | # information. |
|
|||
1836 | # |
|
|||
1837 | # However is the mtime is far away in the future, this is |
|
|||
1838 | # likely some mismatch between the current clock and |
|
|||
1839 | # previous file system operation. So mtime more than one days |
|
|||
1840 | # in the future are considered fine. |
|
|||
1841 | if ( |
|
|||
1842 | boundary_second |
|
|||
1843 | <= file_second |
|
|||
1844 | < (3600 * 24 + boundary_second) |
|
|||
1845 | ): |
|
|||
1846 | clean.append(f) |
|
1831 | clean.append(f) | |
1847 | else: |
|
|||
1848 | fixup.append((f, cache_info)) |
|
|||
1849 | except (IOError, OSError): |
|
1832 | except (IOError, OSError): | |
1850 | # A file become inaccessible in between? Mark it as deleted, |
|
1833 | # A file become inaccessible in between? Mark it as deleted, | |
1851 | # matching dirstate behavior (issue5584). |
|
1834 | # matching dirstate behavior (issue5584). |
@@ -99,3 +99,28 b' def mtime_of(stat_result):' | |||||
99 | subsec_nanos = nanos % billion |
|
99 | subsec_nanos = nanos % billion | |
100 |
|
100 | |||
101 | return timestamp((secs, subsec_nanos)) |
|
101 | return timestamp((secs, subsec_nanos)) | |
|
102 | ||||
|
103 | ||||
|
104 | def reliable_mtime_of(stat_result, present_mtime): | |||
|
105 | """same as `mtime_of`, but return None if the date might be ambiguous | |||
|
106 | ||||
|
107 | A modification time is reliable if it is older than "present_time" (or | |||
|
108 | sufficiently in the futur). | |||
|
109 | ||||
|
110 | Otherwise a concurrent modification might happens with the same mtime. | |||
|
111 | """ | |||
|
112 | file_mtime = mtime_of(stat_result) | |||
|
113 | file_second = file_mtime[0] | |||
|
114 | boundary_second = present_mtime[0] | |||
|
115 | # If the mtime of the ambiguous file is younger (or equal) to the starting | |||
|
116 | # point of the `status` walk, we cannot garantee that another, racy, write | |||
|
117 | # will not happen right after with the same mtime and we cannot cache the | |||
|
118 | # information. | |||
|
119 | # | |||
|
120 | # However is the mtime is far away in the future, this is likely some | |||
|
121 | # mismatch between the current clock and previous file system operation. So | |||
|
122 | # mtime more than one days in the future are considered fine. | |||
|
123 | if boundary_second <= file_second < (3600 * 24 + boundary_second): | |||
|
124 | return None | |||
|
125 | else: | |||
|
126 | return file_mtime |
General Comments 0
You need to be logged in to leave comments.
Login now