util: Address various issues in AllocateFileRange #33228
Conversation
Several bugs exist: - F_PREALLOCATE is undone at close (which we do immediately) - HFS implementation appears buggy (and we have unknown issues on macOS with exFAT - possibly related?) - F_PEOFPOSMODE assumes offset is EOF exactly
While this data should never be live, in practice it can be right now, so better play it safe
|
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. Code Coverage & BenchmarksFor details see: https://corecheck.dev/bitcoin/bitcoin/pulls/33228. ReviewsSee the guideline for information on the review process. ConflictsReviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first. |
| // Version using posix_fallocate | ||
| off_t nEndPos = (off_t)offset + length; | ||
| if (0 == posix_fallocate(fileno(file), 0, nEndPos)) return; | ||
| if (0 == posix_fallocate(fileno(file), offset, length)) return; |
There was a problem hiding this comment.
Is this really a bugfix? Might this not be intentional to allocate as large a chunk of the file as possible, even in the case where a non-contiguous offset is passed in?
| unsigned int now = 65536; | ||
| if (length < now) | ||
| now = length; | ||
| const size_t rlen = fread(buf, 1, now, file); |
There was a problem hiding this comment.
Why not seek to the end of the file instead of reading?
Fixes several bugs in AllocateFileRange.
Not a real fix for #33128, but a workaround for the issue.
Potentially might fix #28552 too, but I don't have a way to reproduce that. (After digging into Apple's XNU code, it looks too buggy to try to use
F_PREALLOCATEat all IMO; for reference: XNU kernel code and HFS driver code - notice the truncation risk from comparing to block-allocated size rather than file size and reachable code paths the comments assume to be dead code)