Skip to content

Conversation

@CraftSpider
Copy link
Contributor

@CraftSpider CraftSpider commented Aug 29, 2025

Fixes #4483

@rustbot
Copy link
Collaborator

rustbot commented Aug 29, 2025

Thank you for contributing to Miri!
Please remember to not force-push to the PR branch except when you need to rebase due to a conflict or when the reviewer asks you for it.

@rustbot rustbot added the S-waiting-on-review Status: Waiting for a review to complete label Aug 29, 2025
@rustbot

This comment has been minimized.

Copy link
Member

@RalfJung RalfJung left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@RalfJung
Copy link
Member

RalfJung commented Sep 3, 2025

@rustbot author

There's also a conflict that prevents CI from running, so please rebase to resolve that.

@rustbot rustbot added S-waiting-on-author Status: Waiting for the PR author to address review comments and removed S-waiting-on-review Status: Waiting for a review to complete labels Sep 3, 2025
@rustbot
Copy link
Collaborator

rustbot commented Sep 3, 2025

Reminder, once the PR becomes ready for a review, use @rustbot ready.

@rustbot
Copy link
Collaborator

rustbot commented Dec 12, 2025

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

@CraftSpider
Copy link
Contributor Author

@rustbot ready

Still pending CI, but rebased and responded to review (finally)

@rustbot rustbot added S-waiting-on-review Status: Waiting for a review to complete and removed S-waiting-on-author Status: Waiting for the PR author to address review comments labels Dec 12, 2025
Copy link
Member

@RalfJung RalfJung left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! Unfortunately there's some new code which causes confusion, probably due to my complete lack of understanding of Windows APIs. ;)

View changes since this review

} else if class == this.eval_windows_u32("c", "FileAllocationInfo") {
// File allocation size is independent of file EOF position on Windows, except that
// EOF must be <= allocation size. So we only do something if the file is bigger than
// the requested allocation size.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So in other words, we don't grow, we only shrink? I don't understand what that has to do with "EOF position" vs "allocation size". I also don't know what those terms even mean. ;)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

EOF position is the file's length. Allocation size is generally a multiple of the underlying storage's sector size, and is effectively the file's pre-allocated capacity before writing will have to map more physical storage.

Rust std doesn't expose this cross-platform, and we don't support it in GetFileInformationByHandle, so the only observable side effect of setting it is truncating length to be less than capacity.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay. I have made a suggestion for updating the comment.

However, I am a bit concerned about just silently doing nothing for the other case, where the allocation size is grown beyond the EOF position. Can't that break stuff? Or is it okay to consider this more of a hint, in some sense?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is okay to consider as a hint.

  • Extra allocation beyond file size is automatically freed when the last HANDLE to a file is closed
  • Programs should be resilient to different cluster allocation sizes, since it's configurable.
  • A quick look through the first couple pages of a GitHub search shows mostly uses to set a file size to 0, and a couple uses to pre-allocate space solely for write efficiency.
  • I think we could emulate it with a side map tracking a HANDLE's allocation size, updated on writes beyond it, if we need to. This may be worth it if we want/need to support GetFileInformationByHandle for allocation size.

@ChrisDenton, I know you're familiar with Windows, so I'd appreciate your thoughts. Is this value guaranteed observable in other ways that I'm not finding it my search?

file_information,
this.windows_ty_layout("FILE_END_OF_FILE_INFO"),
)?;
let ptr = this
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is somewhat odd to call this a ptr when it is not a Pointer, unlike file_information which is a Pointer but not called ptr. ;)

Name suggestions: place, file_information.

@rustbot rustbot added S-waiting-on-author Status: Waiting for the PR author to address review comments and removed S-waiting-on-review Status: Waiting for a review to complete labels Dec 14, 2025
interp_ok(this.eval_windows("c", "FALSE"))
}
}
} else if class == this.eval_windows_u32("c", "FileAllocationInfo") {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't have a direct test.

Comment on lines +421 to +423
// File allocation size is independent of file EOF position on Windows, except that
// EOF must be <= allocation size. So we only do something if the file is bigger than
// the requested allocation size.
Copy link
Member

@RalfJung RalfJung Dec 14, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, is this correct?

Suggested change
// File allocation size is independent of file EOF position on Windows, except that
// EOF must be <= allocation size. So we only do something if the file is bigger than
// the requested allocation size.
// File allocation size is independent of file EOF position (i.e. the length of the file
// contents, which can be changed with set_len) on Windows,
// except that EOF must be <= allocation size. This means that
// *growing* the allocation size cannot be implemented or observed with std APIs.
// Shrinking the allocation size below EOF length however truncates the file,
// which is visible -- so that's the only case in which we do anything.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

S-waiting-on-author Status: Waiting for the PR author to address review comments

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Windows: File::create fails when file already exists (cannot call SetFileInformationByHandle)

3 participants