Skip to content
Utah Community Learning

Backups, or how I deleted 399 files in one run

About 15 minutes

Backups, or How I Deleted 399 Files in One Run

Okay so here's the thing. I already told you about my first script in the intro, but let's actually sit with it for a minute because it's the whole reason this lesson exists.

I wrote a script to rename my photo files by date. Four hundred files from a shoot, all with garbage camera-generated names like DSC004821.jpg, and I wanted them named nicely so I could actually find things later. I wrote the loop, felt very proud of myself, and ran it.

It renamed file one. Then it renamed file two to the exact same name as file one, which overwrote file one. Then file three overwrote that. This went on for all 400 files. I ended up with one (1) photo and 399 deleted originals. No trash folder, no undo, gone.

I did not have backups. That's the whole story. That's the lesson.

Why this happens to literally everyone

Your code is going to have bugs. We've talked about this already, you're going to read error messages, you're going to have days where you're just figuring out why the computer hates you today. That's normal and it's fine.

What's not fine is when a bug doesn't throw an error at all. It just quietly does the wrong thing to your files, and Python does not ask "are you sure?" before it overwrites or deletes something. It just does what you told it, even when what you told it was dumb. Especially when what you told it was dumb, honestly.

So the fix isn't "write perfect code." Nobody does that, and I'm forty-something years old and I still don't. The fix is: never run anything on your only copy of something you care about.

The stupid-small-steps version of backups

You already know I'm big on breaking a problem down instead of trying to do the whole thing at once. Backups work the same way. Here's what I actually do, at home, no fancy tools:

  1. Copy the files somewhere else before you touch them with code. Not move. Copy. Drag them to a different folder, an external drive, wherever. Takes thirty seconds. My rule: if I didn't make a second copy, I don't run the script yet.
  1. Test on a tiny sample first. Don't point your rename script at all 400 files. Point it at three test files you don't care about losing. Watch what happens. This is the same idea as renaming one file before you try to rename four hundred, because it's the same lesson wearing a different hat.
  1. Print before you commit. If your script is going to rename or delete something, have it print what it's about to do first, instead of actually doing it. Something like print(f"would rename {old_name} to {new_name}"). Run that version. Read the output. If it looks right, then let it actually do the thing. Yes, this is another print statement. I use them for everything. Jared can keep judging me.
  1. Know where your "undo" is, or accept there isn't one. Some file systems have a recycle bin that catches deleted stuff. A lot of scripted deletes skip right past that and just remove things permanently. If you don't know which one you're dealing with, assume the scary one.

None of this requires paid software, by the way. A second folder and thirty extra seconds is a backup. People try to sell beginners fancy backup tools and cloud sync subscriptions before they've even lost anything yet. You don't need it. You need a copy folder and the patience to test small first.

The part that makes this worth it

I had a woman in an earlier session of this class, first time ever writing code, get her first little program running. Nothing fancy, just something that printed out a few lines based on a for loop, similar to what you built a couple lessons back. It worked on the first try for her, which almost never happens to anybody.

She gasped. Out loud. Loudest reaction I have ever gotten out of a room over what was, from the outside, a text file.

That's the whole reason I keep doing this. Not the renaming scripts, not the grocery trackers, that specific moment where the thing you were scared of just works and you can't believe you're the one who made it happen. Backups are how you protect that feeling from getting wrecked by one dumb bug on a day you didn't expect it. My 399 deleted photos taught me that the hard way so hopefully you don't have to.

Before next time

Find a folder on your computer with files you'd be sad to lose, even a folder of vacation photos, and just practice making a second copy of it somewhere else. That's it. That's the whole assignment, and it's the one habit I actually wish I'd learned before I learned to code.

Backups, or how I deleted 399 files in one run · Introduction to Coding with Python · Utah Community Learning