The Day My PowerShell Script Wiped My Drive

Okay, so picture this: I’m fresh out of IT school, bright-eyed, bushy-tailed, and absolutely convinced I’m the next command-line wizard. My first "real" task involved cleaning up some old, forgotten folders on a development server. Easy peasy, right? I’d seen senior devs whip out PowerShell scripts like they were magic wands, so I thought, "Why not automate this?" Famous last words.

TL;DR: I wrote a PowerShell script to delete old folders, but a simple typo in the path (D:\dev_projects\ instead of D:\dev\projects\) led to me accidentally deleting a critical directory on a shared drive. Panic ensued. Recovery involved version control, backups, and a healthy dose of humility.

The "It'll Just Take a Minute" Script

My goal was simple: find any folder older than 30 days in D:\dev\projects\ and delete it. I figured this would be my shining moment, a demonstration of my newfound scripting prowess. I remembered seeing Get-ChildItem and Remove-Item in some online tutorials. So, I cobbled together something that looked vaguely like this:

$targetFolder = "D:\dev\projects\" # Or so I thought...
$cutoffDate = (Get-Date).AddDays(-30)
Get-ChildItem -Path $targetFolder -Directory | Where-Object {$_.LastWriteTime -lt $cutoffDate} | Remove-Item -Recurse -Force

"Perfect!" I thought. It looked clean, it was concise, and it was going to save us so much manual cleanup time. I’d even tested it on a small, dummy folder I’d created. It worked flawlessly. "Time to unleash the beast," I muttered to myself, feeling like a scripting god. I ran the script.

And then the silence.

Normally, a script like this would give some output, maybe a list of deleted files. But this one just… finished. Instantly. Too instantly. A cold dread started to creep up my spine. I navigated to D:\dev\projects\ using File Explorer. It was… empty. Not just the old folders, but everything. The README.md files, the src folders, the bin directories – all gone.

My heart did a frantic drum solo against my ribs. This wasn't a dev server's personal playground; this was a shared development drive. Other people were working on this! My mind raced. What had I done?

The Full-Blown "Oh Crap" Moment

I frantically checked the script again. D:\dev\projects\. My eyes scanned the path. Wait a second… was it dev\projects or dev_projects? A quick check of the actual folder structure on the server revealed the horrifying truth: the critical shared development folder was named D:\dev_projects\, not D:\dev\projects\. My script, in its magnificent ignorance, had happily chugged along and deleted the entire contents of a directory that was only one character different.

The Remove-Item -Recurse -Force command, in its unfeeling, logical way, had blindly obliterated everything within D:\dev\projects\ because it thought that was its target. There was no "Are you sure?" prompt. No "Oops, that doesn't look right!" message. Just… deletion.

My immediate thought was: "Backup. Please tell me there's a backup." I scrambled to find the server administrator, my voice a shaky whisper. "Uh, hi. So, I think I might have accidentally deleted… a lot of stuff on the dev drive." The look on his face was a mix of weary resignation and pure, unadulterated panic.

The recovery process was a blur of activity. We immediately looked at the server's backup logs. Thankfully, the server was backed up nightly. The good news? We could restore. The bad news? The last backup was from the previous night. Anything that had been added or modified since then was gone. This meant a few hours of work for several developers were now… un-saved.

We spent the next few hours meticulously restoring folders and files from the backup. It was painstaking. We had to cross-reference with version control (thank goodness for Git!) to see what was actually missing and needed re-applying. The silence in the office was thick with tension, punctuated only by the clicking of keyboards and the occasional sigh.

Preventing the Next Script-pocalypse

This whole ordeal was a brutal, albeit effective, lesson. It wasn't just about PowerShell syntax; it was about responsible scripting, understanding the environment, and having safety nets. Here's what I implemented (and what you should too):

Dry Runs are Your Best Friend: Before running any script that modifies or deletes files, especially in a production or shared environment, do a "dry run." This means using the -WhatIf parameter. It shows you what the command would do without actually doing it.

    # Example with -WhatIf
    Get-ChildItem -Path $targetFolder -Directory | Where-Object {$_.LastWriteTime -lt $cutoffDate} | Remove-Item -Recurse -Force -WhatIf
    

    What if: Performing the operation "Remove File" on target "D:\dev\projects\old_module_v1" (System.IO.DirectoryInfo).
    What if: Performing the operation "Remove File" on target "D:\dev\projects\temp_build_files" (System.IO.DirectoryInfo).
    

Double-Check Your Paths: This seems obvious, but when you're typing fast or copying and pasting, mistakes happen. Always, always verify the exact path. Use Get-Location if you're unsure where you are. Use Tab completion in PowerShell to help ensure accuracy.

* Logging is Crucial: Even for simple scripts, add logging. Log what the script is doing, what it finds, and what actions it takes. This helps immensely with debugging and recovery.

```powershell $logFile = "C:\Scripts\CleanupLog.txt" Add-Content -Path $logFile -Value "$(Get-Date): Script started."

# ... your script logic ...

$itemToDelete = Get-ChildItem -Path $targetFolder -Directory | Where-Object {$_.LastWriteTime -lt $cutoffDate} if ($itemToDelete) { foreach ($item in $itemToDelete) { Add-Content -Path $logFile -Value "$(Get-Date): Deleting folder: $($item.FullName)" Remove-Item