- Home
- Skills
- DevOps & Cloud
- Disk Relocation: copy, verify the bytes, delete, link back
Disk Relocation: copy, verify the bytes, delete, link back
Clean a full C: drive without breaking it: four-layer attribution, a plan you review item by item, and a copy-verify-delete-link chain with a byte gate before the source goes.
$5
Works with the AI Agents you already use
Disk Relocation: copy, verify the bytes, delete, link back
Example session with this skill installed
Last month I moved two ProgramData folders to D: by hand - copy, delete, mklink. Now one app says all its settings are gone and Windows Update fails. I want the rest moved properly, and I want to know what the hand-made links broke.
- Read your context and instructions
- Compiled the disk relocation
Verdict: the data is not gone - one of the links points at the wrong directory. Two hand-made links were checked; one resolves, one does not, and the failing one is the app that "lost its settings".
Step 1 - attribution, read-only
| Folder | Layer | Size | Action |
|---|---|---|---|
C:\ProgramData\Vendor\Cache | L3_RENEWABLE | 26.4 GB | delete first, it grows back |
C:\ProgramData\Vendor\Library | L4_MOVABLE | 11.8 GB | move, through the gate |
C:\ProgramData\Vendor\Settings | L4_MOVABLE | 0.3 GB | already relocated by hand |
C:\Users\you\AppData\Local\Vendor | L4_MOVABLE | 6.2 GB | only if cleaning was not enough |
C:\Windows\Installer | L1_FLOOR | 4.1 GB | do not touch |
The plan is a file, not an action. Cleaning the renewable layer returns 26.4 GB on its own, which is why the generated script ships with $DoClean = $true and $DoMove = $false: getting a clean wrong costs a cache re-download, getting a move wrong costs the data.
Step 2 - what the hand-made link actually did
verify.py compares against the byte count and file count recorded in the manifest
at the moment of the move, not against a fresh count of both sides. Counting both sides afterwards would agree with itself: if the copy dropped half the data, both sides are the half that got copied.
| # | Check | Result |
|---|---|---|
| 1 | destination exists | D:\Vendor\Settings present |
| 2 | byte count matches | 297 MB of 302 MB recorded - short |
| 3 | file count matches | 41 of 44 |
| 4 | source is now a link | yes, a reparse point |
| 5 | link points at the target | no - it points at D:\Vendor\Settings_old |
| 6 | readable through the link | fails: the resolved path holds no config.json |
Check 4 passing is what makes this confusing. The original path is not empty, so from the outside nothing looks deleted; the software is simply reading a directory that stopped being updated a month ago. That is what "all my settings are gone" looks like from the user's side, and it is why the two checks worth paying attention to are 4 and 6.
Step 3 - fix, in this order
- Do not run the generated script as-is. Clear the renewable layer first, re-audit, and see whether 26.4 GB was the whole answer - it usually is, and then nothing has to move.
- Move the remaining
L4_MOVABLEfolders through the chain: target must not already exist;robocopy /E /COPY:DAT /DCOPY:DAT /R:1 /W:1 /XJ(/XJis not optional - robocopy follows junctions and copies an already-relocated folder straight back); destination bytes >= 99.5% of source
and destination file count >= source count; only then delete the source; then recreate the original path as a Junction.
3. Re-point the broken link through the same chain rather than with mklink by hand, then run verify.py --manifest plan.json. Six checks, and check 5 fails loudly when the target is wrong, which is the one thing a hand-typed link never tells you.
Nothing here is reversible: Remove-Item does not use the Recycle Bin. That is why moving is off by default, and why step 1 is cleaning.
Connects securely to your tools. The creator never sees your data.
About this skill
The instinctive response to a full system drive is to find the biggest folder and move it. That response is wrong often enough to have a name: move first, clean later = move twice. On a 53G disk, Windows and Program Files permanently hold 14G and only a little over 30G was ever movable - and the largest block inside that 30G was cache that could simply be deleted, not data that needed moving.
So this skill works in the order that cannot be reversed: attribute -> do the arithmetic -> clean the renewable layer -> move, with a gate at every step.
Three scripts, three questions:
scripts/triage.py- which of four layers does each folder belong to, and what is this drive's physical ceiling? Anything unrecognised goes toUNKNOWNand is not touched.scripts/plan.py- a plan you can review item by item, plus a PowerShell script. The plan is a file, not an action: reviewing it is the one step that cannot be automated, because it is the only place a wrong classification is still cheap to catch.scripts/verify.py- six checks whose standard is the number taken at the moment of acting, not an after-the-fact "looks right".
The move itself is a proof chain, and each step stops the run if it fails: target must not already exist; copy with robocopy /E /COPY:DAT /DCOPY:DAT /R:1 /W:1 /XJ (/XJ matters - robocopy follows junctions by default and will copy an already-relocated folder straight back); require destination bytes >= 99.5% of source and destination file count >= source count; only then delete the source; then recreate the original path as a Junction (falling back to SymbolicLink when a junction is refused). Because the path does not change, no application configuration changes, and nothing has to be reinstalled.
Two things are stated plainly rather than buried, because they are the two things that cost people data:
Remove-Itemdoes not use the Recycle Bin. A deletion is permanent. That is exactly why the generated script clears only theL3_RENEWABLElayer by default - the layer that grows back on next use.- The generated script moves nothing until a human flips a switch. Cleaning is on by default, moving is off by default. Getting a clean wrong costs a cache re-download; getting a move wrong costs the data, and there is no rehearsal.
Includes two reference documents (the four-layer model with the reasoning for each boundary, and the safe-move protocol with the acceptance criterion and abort point for each step), a 71-line PowerShell skeleton for people who want to run the steps by hand, and a failure library keyed by the exact error text.
What it does not do: it does not touch L1_FLOOR or UNKNOWN; it does no partition work and no disk expansion (when the target is impossible the advice is add or replace a disk); and it makes no promise that a deletion can be recovered, because it cannot.
Does not support partition resizing. Custom folder paths require manual selection via --pick. Deletions via the generated script bypass the Recycle Bin and are permanent.
How to use
- 1
Connect your agent to the Agensi MCP
Copy the prompt and paste it into Claude, ChatGPT, Cursor or any agent that supports MCP. It sets up the connection for you. Manual setup
- 2
Sign in to Agensi
Your agent shows a sign-in link. Sign in and click Allow.
- 3
Ask for what you need
Your agent loads this skill and uses it on your task. It always asks before any payment.
Reviews
No reviews yet
Be one of the first to try it. Every listed skill goes through the trust checks below.
Security scanned
Checked by our 8-point scan before listing
Fresh listing
Recently published to Agensi
Money-back guarantee
Doesn't do what its page promises? You get your money back.
Trust & safety
Security scan
Security scan passed 6 days ago
Requires
Permissions
Read Files - triage reads directory metadata, and plan.py reads the triage JSON the operator generated. No file contents are read to classify anything. Write Files - three write sites in scripts/plan.py (plan.md, the generated .ps1, the manifest JSON) and two in scripts/verify.py (its report and the step log), each at a path the operator passes on the command line. Terminal - ticked for usage. The operator runs python scripts/plan.py and python scripts/verify.py in their own shell, and then runs the generated PowerShell script themselves. No Python script in the package executes a command: Remove-Item, robocopy and mklink appear only as text written into that generated script, never as a call made by plan.py. Browser - ticked because the shared renewable-cache list carries path text such as AppData\Local\ms-playwright, where Playwright keeps its browser binaries. Nothing here opens a page or drives a browser; no browser library is imported and the string is only compared against folder names during the read-only walk. Network Access - off. No network module is imported and no outbound connection is opened by any of the three scripts; all behaviour is local file I/O on the drives involved. Environment Variables - off. The Python scripts read no environment variable; the only $env: reference in the package is text inside the script they generate.