Windows: Use FILE_ALLOCATION_INFO for truncation

[ChrisDenton]

We use FILE_END_OF_FILE_INFO here only because WINE does not support FILE_ALLOCATION_INFO. Instead of going with the one with broadest support, let's just use that as fallback only.

[Amanieu]

What is the benefit of using FILE_ALLOCATION_INFO? Does FILE_END_OF_FILE_INFO not actually reduce the allocated size on disk?

[ChrisDenton]

Tbh, I've been unable to find a difference in the case of 0. In either case the reported allocation beyond EOF is freed when the handle is closed (and not before).

My main reason for doing this is because it's what Windows generally uses to truncate a file which makes me think there's some reason I don't know. Maybe there is a filesystem driver that does something differently.

[ChrisDenton]

Ah, setting FILE_END_OF_FILE_INFO should imply also setting the allocation size. But that's not a must.

If InputBuffer.EndOfFile is less than (BlockAlign(Open.Stream.Size, Open.File.Volume.ClusterSize) -Open.File.Volume.ClusterSize), the object store SHOULD set Open.Stream.AllocationSize to BlockAlign (InputBuffer.EndOfFile, Open.File.Volume.ClusterSize).

And a difference between the two is for setting the allocation:

If the object store supports Open.File.Volume.ClusterRefcount, for each EXTENTS that is removed from Open.Stream.ExtentList as a result of truncation, for each cluster that is being referred to by the EXTENTS being removed, its entry in Open.File.Volume.ClusterRefcount MUST be decremented. If the corresponding cluster's reference count goes to zero, then that cluster MUST also be freed.

[Amanieu]

Since this is what Windows does anyways there's no harm in us doing the same.

[Amanieu]

@bors r+

[bors]

📌 Commit ca56dc8 has been approved by Amanieu

It is now in the queue for this repository.

[bors]

⌛ Testing commit ca56dc8 with merge a92c3cf...

[bors]

☀️ Test successful - checks-actions
Approved by: Amanieu
Pushing a92c3cf to master...

[rust-timer]

Finished benchmarking commit (a92c3cf): comparison URL.

Overall result: ✅ improvements - no action needed

@rustbot label: -perf-regression

Instruction count

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-1.0%	[-1.0%, -1.0%]	1
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results (primary 3.4%, secondary -4.8%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	3.4%	[3.4%, 3.4%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-4.8%	[-4.8%, -4.8%]	1
All ❌✅ (primary)	3.4%	[3.4%, 3.4%]	1

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 763.56s -> 765.282s (0.23%)
Artifact size: 330.63 MiB -> 330.64 MiB (0.00%)

[beetrees]

Suggested change

	c::FileEndOfFileInfo,
	c::FileAllocationInfo,

Doesn't this need to be changed to FileAllocationInfo?

[ChrisDenton]

Oh, huh. I fixed that locally but somehow forgot to push. Fortunately their associated values are the same size (and if they weren't then it'd return an error).