The Folder Move I Had to Do With Everything Shut Down

When I checked the storage meter on my computer, the C: drive had only 230 MB free out of 231 GB. That is less room than many phone photos take up. One obvious place to make space was a 1.7 GB folder holding conversation records and a browser testing profile. It was big enough to matter, and I had another drive with room to spare.

At first, the job looked like moving a box from a crowded closet to the garage. I wanted to put the folder on the G: drive while leaving a sign at the old spot, so the programs that expected to find it on C: would still find it. Windows calls that sign a junction. It is simply a hidden pointer that sends a program from the old folder address to the new one.

That would have been fine if nobody was using the folder. But they were. About eight active sessions were still adding to their own conversation records inside it. In everyday terms, I was trying to move a filing cabinet while several people still had drawers open and were putting papers in them.

The first plan was the tempting one. Copy everything to the new drive, remove the old folder, then put the pointer in its place. It did not work, and it should not have worked. Windows would not let the old folder be removed because files inside it were in use. The first attempt cost time at exactly the point when the nearly full drive was already demanding attention. More importantly, it exposed a worse problem than a refused command.

Changing the sign on a filing cabinet does not make someone with an open drawer suddenly start using a different cabinet. A program opens a file once, then keeps working with that same open file. If I had somehow forced the folder move while those sessions were active, the older sessions could have kept writing to the old place while newly opened files went to G:. The records would have been split between two locations. Nothing would necessarily pop up to say that had happened.

That quiet failure was the real risk. A visible error is annoying, but at least it tells you to stop. Two sets of records that both look normal can leave you believing everything was moved when part of the story is still being written somewhere else.

The useful rule turned out to be much simpler than the computer language around it: changing a folder address only helps programs that open the folder afterward. It does not change the place where an already open file is being written.

Once I understood that, this stopped being a clever computer trick and became a question of order. The folder had to be cold. In plain English, everything using it had to be closed first. I was not going to do a delicate move in the same busy window where the storage problem had appeared.

So I prepared a small set of instructions to run later, when every active session was closed. Before it touched anything, it checked three things. First, it stopped if the relevant program was still running. Second, it stopped if a folder already existed at the new destination, because that could mean an earlier move had been interrupted. Third, it stopped if the old folder was already a pointer, because that would mean the change had already happened.

Only after those checks did it copy the files and compare the number of files in each place. It did not immediately throw away the original. Instead, it renamed the old folder as a backup, put the pointer in place, and restored the backup if that step failed. The original copy would be removed by hand only after the new arrangement had been confirmed to work.

That backup matters for the same reason you keep the old key until you know the new key opens the door. It leaves a way back. The checks matter because they turn a hope, “I think I closed everything,” into a question the computer can answer before it makes a hard to reverse change.

I also dealt with why the C: drive had filled in the first place. Two places on the computer, a program download cache and the temporary files area, were still growing on C:. I redirected those to G: as a separate settings change. That did not have the same risk because it was not trying to relocate files that active sessions already had open. It was about keeping new clutter from returning to the same cramped closet.

The lesson is not that everyone needs to learn how folder pointers work. It is that a move can look simple while work is still happening inside it. On Monday, pick one shared folder, inbox, spreadsheet, or service that someone wants to reorganize. Before changing where it lives, ask one question: Who still has this open, and what is my safe way back if the new arrangement fails?

dxdev LESSON · paste into your AI coding agent
LESSON: Redirecting a folder's address only affects programs that open it afterward; anything with a file already open keeps writing to the old spot
SOURCE: dxdev.com/blog/2026-05-21_folder-move-i-had-to-do-with
WHAT HAPPENED: With only 230 MB free on a 231 GB drive, a 1.7 GB folder needed to move to a drive with room. The first plan (copy the files, delete the original, put a junction, a folder redirect, in its place) failed immediately because Windows refused to delete files that were still open in roughly eight active sessions. Worse, forcing the move anyway could have silently split writes between the old and new locations with no visible error, since a program that already has a file open keeps writing to that same open file regardless of what the folder's address now points to. The fix required the folder to be fully closed first, then a script that aborts if the owning process is still running, if the destination already exists (a sign of a partially completed prior move), or if the source is already a junction (a sign the move already happened), before copying, verifying matching file counts, renaming the original as a backup rather than deleting it, and auto-restoring from that backup if any step failed.
THE RULE: A folder or path redirect only affects consumers that open the path after the change; anything with a file already open keeps writing to the original location regardless, and that split can happen with no visible error to warn you.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
      1. Any folder or path relocation (junction, symlink, remount) performed while a process might still have files open inside it, without first confirming that process is stopped.
      2. Any move or migration script that deletes the source before the destination has been verified (for example, matching file counts), rather than keeping a renamed backup until confirmed.
      3. Any relocation script with no pre-flight check for an already-done or partially-done prior attempt (destination already exists, source is already a redirect) before proceeding.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.