fix spurious sparse test fail on win32, fixes #7616#9462
Merged
ThomasWaldmann merged 1 commit intoborgbackup:masterfrom Mar 11, 2026
Merged
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #9462 +/- ##
==========================================
- Coverage 83.34% 83.31% -0.04%
==========================================
Files 87 87
Lines 15423 15429 +6
Branches 2310 2311 +1
==========================================
Hits 12854 12854
- Misses 1818 1821 +3
- Partials 751 754 +3 ☔ View full report in Codecov by Sentry. |
db68889 to
66e2cf1
Compare
Python's `os.truncate()` on Windows relies on `SetEndOfFile()`, which does not initialize the extended disk space with zeroes. This means that trailing sparse holes simply leave uninitialized garbage data at the end of the file. During sparse file extraction, when the very last chunk is a sparse hole, the VDL (Valid Data Length) is not properly advanced by `os.truncate()`. As a result, reading from the end of the file fetches random disk garbage instead of zeroes, causing spurious test failures at boundaries (like 2MB or 8MB) depending on what was in the uninitialized disk sectors. Fix this by tracking trailing holes and manually writing a single `b"\0"` byte at the end of the file before truncating on Windows. Writing explicit data forces NTFS to officially advance the VDL and securely zero-fill the preceding hole space. Re-enable `test_sparse_file` on Windows.
66e2cf1 to
6d85812
Compare
|
Backport failed for Please cherry-pick the changes locally and resolve any conflicts. git fetch origin 1.4-maint
git worktree add -d .worktree/backport-9462-to-1.4-maint origin/1.4-maint
cd .worktree/backport-9462-to-1.4-maint
git switch --create backport-9462-to-1.4-maint
git cherry-pick -x 6d85812e1214c6a93323ee9a7862f5d849ab5cd6 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Python's
os.truncate()on Windows relies onSetEndOfFile(), which does not initialize the extended disk space with zeroes. This means that trailing sparse holes simply leave uninitialized garbage data at the end of the file.During sparse file extraction, when the very last chunk is a sparse hole, the VDL (Valid Data Length) is not properly advanced by
os.truncate(). As a result, reading from the end of the file fetches random disk garbage instead of zeroes, causing spurious test failures at boundaries (like 2MB or 8MB) depending on what was in the uninitialized disk sectors.Fix this by tracking trailing holes and manually writing a single
b"\0"byte at the end of the file before truncating on Windows. Writing explicit data forces NTFS to officially advance the VDL and securely zero-fill the preceding hole space.Re-enable
test_sparse_fileon Windows.