Show More
@@ -1823,29 +1823,12 class workingctx(committablectx): | |||
|
1823 | 1823 | s = self[f].lstat() |
|
1824 | 1824 | mode = s.st_mode |
|
1825 | 1825 | size = s.st_size |
|
1826 | file_mtime = timestamp.mtime_of(s) | |
|
1827 |
|
|
|
1828 | ||
|
1829 | file_second = file_mtime[0] | |
|
1830 | boundary_second = mtime_boundary[0] | |
|
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 | ): | |
|
1826 | file_mtime = timestamp.reliable_mtime_of(s, mtime_boundary) | |
|
1827 | if file_mtime is not None: | |
|
1828 | cache_info = (mode, size, file_mtime) | |
|
1829 | fixup.append((f, cache_info)) | |
|
1830 | else: | |
|
1846 | 1831 | clean.append(f) |
|
1847 | else: | |
|
1848 | fixup.append((f, cache_info)) | |
|
1849 | 1832 | except (IOError, OSError): |
|
1850 | 1833 | # A file become inaccessible in between? Mark it as deleted, |
|
1851 | 1834 | # matching dirstate behavior (issue5584). |
@@ -99,3 +99,28 def mtime_of(stat_result): | |||
|
99 | 99 | subsec_nanos = nanos % billion |
|
100 | 100 | |
|
101 | 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