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.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Single file: Guard against partial cleanup of extracted files #32649
Single file: Guard against partial cleanup of extracted files #32649
Changes from all commits
39aa461
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This loop will run for at most 500 times, waiting at most 50s before trying. This is also called by commit_file(), so this can take up to 50s per file in the bundle. It looks to me that this is a bit too much...
There might be other files in the bundle that need renaming, so maybe instead of retrying them here, add it to a queue to try later?
Maybe keep track of the total amount of time taken to rename these things?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@lpereira I agree that the worst case looks bad -- but it is extremely unlikely.
The long wait time can only happen if the rename succeeds close to the 500th iteration for each file. That is, when there is a real failure with EACCESS - the extraction aborts after the first file (after 50s).
The case when recovery is triggered is rare, and is not a path to be optimized. If the AV blocks for a long time after writing each file, then the recovery will need to wait for it. Still, it is not expected to take the full minute after each file is written.
While the wait time could be used to write other files that need to be recovered, the time gained is rather negligible, since the time to write these files is a few milliseconds, compared to the minute spent waiting for the AV.
I actually tried out writing the change you suggested. Please take a look at this diff. But I'm not sure it is work to take in that complexity in a servicing fix, given that this case is unlikely, and that such a case is hard to test. If you still think we need to take the change, I can add it on to the PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since this is a servicing fix and this case is rare, we can keep the current behaviour from this PR. However, keep the code from this diff somewhere, should we need it for the next servicing release (it looks pretty clean and makes the worst case scenario more manageable).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @lpereira.
Do you have any further comments/concerns on this PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I experimented using
readdir()
/FindFirstFile()/FindNextFile()
APIs in place offile_exists()
checks on each file.That is, create a dictionary of files in the the extraction location (and its subdirectories), and check that it has all entries in the manifest.
However, there wasn't a significant difference in startup time due to the change -- especially since the startup impact is already small. Given this and the fact that .net 5 will focus on moving away from extraction, I kept the file_exists checks to keep the logic simple.