From 44b047cf26dc4812b6fef4510aefd9194afdab7d Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Alexey=20ALERT=20Rubash=D1=91ff?= Date: Wed, 26 Aug 2026 15:26:04 +0300 Subject: [PATCH] docs: record the two shrink facts measured in #97 SizeMax includes the unallocated run behind the partition, and -UseMaximumSize takes the largest run on the whole disk. Neither is documented by Microsoft, both cost real time to find, and neither was anywhere a clone can see them. Co-Authored-By: Claude Opus 5 --- AGENTS.md | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/AGENTS.md b/AGENTS.md index 7c4fe80..1f488d8 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -69,6 +69,13 @@ Two consequences: Take the GUID from `Get-Volume`, never from `Get-Partition`: a partition on an MBR disk has no GUID of its own, while its volume does. Never identify a task by its display name, its trigger times, or a before-and-after listing of the folder. That folder keeps the tasks of volumes that no longer exist. +- **Two storage facts the documentation does not state, both measured.** `Get-PartitionSupportedSize` + reports `SizeMax` as the partition's size **plus the contiguous unallocated run right behind it**, so + a shrink target taken from it gives up less than was asked, or nothing. And + `New-Partition -UseMaximumSize` creates the largest partition on the **whole disk**, not one in the + space just freed, so a shrink can leave that space unused. Place such a partition with an explicit + `-Offset` and `-Size` — and align the offset up to a whole megabyte first: any other offset is + refused outright, and `Resize-Partition` aligns to the cluster, landing a few hundred bytes off. - **English in the repository**, in code, comments, documentation and commit messages. ## Line endings