Don't check directory atime in lstat_stat_variation10.phpt test #5553
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a funny one. I discovered that
lstat_stat_variation10.phpt
was failing every now and again when the PHP test suite was run on my dev PC. The output from the failing test showed that the atime (access time) of the directory created in the test was changing between these lines:Could
is_dir()
be accessing the directory and changing the atime? strace showed thatis_dir
was only issuing a singlestat()
syscall. Couldstat()
change the atime? No, no, that would just be perverse. Nobody would be stupid enough to implement the kernel in that way.Checked the kernel source, found that the function called when atime needs to be updated appears to be
touch_atime()
. Broke out the BCC kernel tracing tools and ran this one while running the flaky test case in a loop:Inspecting the results showed that something called "git_thread" was occcasionally updating
the atime on the directory in question!! What on earth...???
The PID shown by trace revealed that this was a background thread for Sublime Text 3.
Sublime now has git integration and shows when there are untracked or modified files. It
seems that it uses a background thread to regularly scan the project directory and look
for new and modified files. This was causing the atime to change.
Even though other developers may not be running ST3, there are any number of reasons why
a background process might recurse through various directories and could cause the atime
to change unexpectedly. Therefore, update the test case so it doesn't fail in such cases.