The Day My Python Script Wiped My Files

Ugh, the sheer panic. I remember it like it was yesterday. I was a fresh-faced junior dev, brimming with confidence (read: overconfidence) and eager to impress. My first "real" Python project was chugging along nicely. I was working on a simple script to automate some file organization, you know, the usual stuff. I thought, "Hey, why not make this script really powerful? Let's add a rm -rf command in there, just to make sure it really cleans up!" Famous last words, right? I ran the script, and instead of tidying up a specific folder, my rogue Python command, fueled by a typo and a prayer, decided to do a full-system rm -rf on my project directory. Suddenly, my screen was a blur of disappearing files. My blood ran cold. My project, weeks of work, gone. Poof! My first "oops" moment, and it was a big one.

TL;DR: My first Python script, intended for file cleanup, accidentally deleted my entire project directory due to a typo in an rm -rf command. This taught me the brutal importance of backups, careful command execution, and the concept of least privilege.

The Script That Went Rogue: A Typo's Tale

So, picture this: I'm sitting there, IDE glowing, feeling like a coding wizard. I'd built this neat little Python script. Its job was supposed to be simple: navigate to a specific ~/projects/old_stuff directory and delete any .bak files older than 30 days. Sounds harmless enough, right? I was trying to make it super efficient, so I decided to leverage the power of the command line through Python's os.system() function.

Here’s a simplified, and safer, version of what I intended to do:

import os
import glob
import datetime
PROJECT_DIR = os.path.expanduser("~/projects/my_awesome_project")
OLD_STUFF_DIR = os.path.join(PROJECT_DIR, "old_stuff")
DAYS_TO_KEEP = 30
def clean_old_files():
    if not os.path.exists(OLD_STUFF_DIR):
        print(f"Directory {OLD_STUFF_DIR} does not exist. Skipping cleanup.")
        return
    now = datetime.datetime.now()
    for bak_file in glob.glob(os.path.join(OLD_STUFF_DIR, ".bak")):
        file_mod_time = datetime.datetime.fromtimestamp(os.path.getmtime(bak_file))
        if (now - file_mod_time).days > DAYS_TO_KEEP:
            print(f"Deleting old backup file: {bak_file}")
            # This is the line that should have been safe, if I hadn't messed up
            # os.system(f"rm '{bak_file}'")

But oh, did I mess up. In my eagerness, I got sloppy with the paths. I was trying to combine a few commands, and I ended up with something like this in my head (and then, terrifyingly, in my script):

os.system("rm -rf ~/projects/my_awesome_project/")

The key mistake? The ~ (tilde) in os.system() doesn't always expand to the home directory as you might expect within that context. More importantly, the wildcard was meant to target files within my_awesome_project, but due to a combination of incorrect path expansion and a general lack of understanding of shell expansion nuances within os.system(), it acted like a much broader directive.

The moment I hit Enter, the terminal output started scrolling… and scrolling… and scrolling. Gone were my source files, my configuration files, my precious README.md. The error messages weren't immediate; the "error" was the absence of my files. When I finally realized what was happening and tried to stop it (Ctrl+C), it was too late. The shell was already too far down the deletion path. My terminal looked like this:

deleting my_awesome_project/src/main.py
deleting my_awesome_project/config/settings.yaml
deleting my_awesome_project/docs/index.html
... (many, many more lines)

My heart sank. This wasn't just a bug; this was data destruction on a grand scale, all thanks to my own hand.

The Cold, Hard Reality: No Backups, No Second Chances

My immediate reaction was disbelief, followed by a frantic, hopeful search for a "recycle bin" for my terminal. Spoiler alert: there isn't one. I scoured my file system, desperately hoping some hidden backup or temporary file existed. Nothing.

This is where the non-coding aspects hit me like a ton of bricks:

Disaster Recovery Planning (or lack thereof): I had zero disaster recovery plan. Not for my code, not for my personal files. I figured "it won't happen to me." Boy, was I wrong. Risk Management: I completely ignored the inherent risks of powerful commands like rm -rf. I treated it like a toy, not a weapon. Data Integrity: My assumption that my data was safe and sound was fundamentally flawed. Data integrity requires active maintenance and protection. Auditing and Logging: If I had any kind of logging set up, I might have been able to trace exactly what the script was trying to do before it went nuclear. But I didn't. Security (Least Privilege): The script was running with my user's full permissions. If it had been designed to run with more restricted privileges, it might have been limited in its destructive capacity.

I tried using extundelete and other file recovery tools, but the rm -rf command is pretty thorough. It’s designed to be irreversible. I managed to recover maybe 10% of my files, mostly fragmented pieces that were useless on their own. The project was effectively dead.

The Long Road to Recovery and Rebuilding

The next few days were a blur of shame and frantic rebuilding.

Manual Re-creation: I had to manually rewrite most of the code from memory and from scattered snippets I might have emailed to myself or saved in a separate, safe location (lesson learned!).

Implementing a Version Control System (VCS): This was the biggest takeaway. I immediately set up Git for everything. Every single line of code, every configuration file, went under Git. This meant I could track changes, revert mistakes, and collaborate. My project structure now looked like this:

``` my_awesome_project/ ├── .git/