Implement SetFileInformationByHandle, as well as direct shim test for it #4547

CraftSpider · 2025-08-29T22:20:14Z

rustbot · 2025-08-29T22:20:17Z

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.

RalfJung

Thanks!

View changes since this review

tests/pass/shims/fs.rs

src/shims/windows/fs.rs

RalfJung · 2025-09-03T11:35:37Z

@rustbot author

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

rustbot · 2025-09-03T11:35:41Z

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

rustbot · 2025-12-12T19:08:03Z

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 · 2025-12-12T19:09:07Z

@rustbot ready

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

RalfJung

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

RalfJung · 2025-12-14T18:54:21Z

src/shims/windows/fs.rs

+        } 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.


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. ;)

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.

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?

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?

Yes, that sounds right. Its intended use is as a performance optimisation. It's similar to Vec::with_capacity in that you can reserve some space upfront then write into it later. It's not really observable outside of directly querying it. And of course write performance if your writes would have otherwise triggered the allocation to grow.

RalfJung · 2025-12-14T18:56:52Z

src/shims/windows/fs.rs

-                file_information,
-                this.windows_ty_layout("FILE_END_OF_FILE_INFO"),
-            )?;
+            let ptr = this


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.

RalfJung · 2025-12-14T18:59:09Z

src/shims/windows/fs.rs

+                    interp_ok(this.eval_windows("c", "FALSE"))
+                }
+            }
+        } else if class == this.eval_windows_u32("c", "FileAllocationInfo") {


This doesn't have a direct test.

RalfJung · 2025-12-14T21:14:34Z

src/shims/windows/fs.rs

+            // 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.


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.

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

This comment has been minimized.

Sign in to view

RalfJung reviewed Aug 31, 2025

View reviewed changes

tests/pass/shims/fs.rs Show resolved Hide resolved

tests/pass/shims/fs.rs Outdated Show resolved Hide resolved

src/shims/windows/fs.rs Outdated Show resolved Hide resolved

src/shims/windows/fs.rs Outdated Show resolved Hide resolved

src/shims/windows/fs.rs Outdated Show resolved Hide resolved

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

CraftSpider added 2 commits December 12, 2025 11:07

Implement SetFileInformationByHandle, as well as direct shim test for it

8c5c463

Respond to review comments

e9b084e

CraftSpider force-pushed the windows-set-len branch from 749eede to e9b084e Compare December 12, 2025 19:08

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

RalfJung requested changes Dec 14, 2025

View reviewed changes

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

RalfJung reviewed Dec 14, 2025

View reviewed changes

-            // 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.

Implement SetFileInformationByHandle, as well as direct shim test for it #4547

Are you sure you want to change the base?

Implement SetFileInformationByHandle, as well as direct shim test for it #4547

Conversation

CraftSpider commented Aug 29, 2025 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Aug 29, 2025

Uh oh!

This comment has been minimized.

RalfJung left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

RalfJung commented Sep 3, 2025

Uh oh!

rustbot commented Sep 3, 2025

Uh oh!

rustbot commented Dec 12, 2025

Uh oh!

CraftSpider commented Dec 12, 2025

Uh oh!

RalfJung left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

RalfJung Dec 14, 2025

Choose a reason for hiding this comment

Uh oh!

CraftSpider Dec 14, 2025

Choose a reason for hiding this comment

Uh oh!

RalfJung Dec 14, 2025

Choose a reason for hiding this comment

Uh oh!

CraftSpider Dec 15, 2025

Choose a reason for hiding this comment

Uh oh!

ChrisDenton Dec 16, 2025

Choose a reason for hiding this comment

Uh oh!

RalfJung Dec 14, 2025

Choose a reason for hiding this comment

Uh oh!

RalfJung Dec 14, 2025

Choose a reason for hiding this comment

Uh oh!

RalfJung Dec 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

CraftSpider commented Aug 29, 2025 •

edited by rustbot

Loading

RalfJung left a comment •

edited by rustbot

Loading

RalfJung left a comment •

edited by rustbot

Loading

RalfJung Dec 14, 2025 •

edited

Loading