(Python_backup tool) Adding Safety Nets to the File Browser — Conflict Detection and Recycle-Bin-Style Deletion

Overview

While improving the network folder browser UI used to pick a backup destination, we tackled two real-world problems at once: "what happens if a file with the same name already exists at the destination," and "is there a way to recover a file that got deleted by mistake."

Key Implementation Points

1. Showing files alongside folders in the browser

The browser used to list only folders. We changed it to also show files, sorted so folders always group before files. We also highlight, in a noticeable color, any destination file that shares a name with a file in the source list — so users can spot a potential conflict at the moment they're choosing a folder, not after the fact.

2. Letting users choose the conflict policy themselves

At the moment a folder selection is confirmed, we compare the source file name list against the destination's file names, compute the overlap, and if there's any overlap, show a three-way confirmation dialog.

Conflicting files found?
  → [Yes]  Overwrite
  → [No]   Append a timestamp to the name and save as a new file
  → [Cancel]  Keep the dialog open so the user can pick a different folder

The chosen policy is passed straight through to the backup execution thread and applied consistently to every file under that folder.

3. Reversible deletion

When we added the ability to delete files and folders from the browser, we deliberately did not implement permanent deletion. Clicking delete triggers a two-step confirmation, and instead of actually erasing the file, it gets moved to a dedicated temporary holding folder with a timestamp prefixed to its name to distinguish it from the original.

Delete requested → two-step confirmation
  → instead of permanently_delete(target)
     move(target → temp_holding_folder/timestamp_original_name)

We excluded the root folder itself and the temporary holding folder itself from being deletable, to prevent the entire backup structure from accidentally disappearing.

Retrospective

• Designing the UI around the assumption that "delete" is irreversible became the default approach for several later features as well. Since we switched to temporary holding instead of permanent deletion by default, we've had essentially no reports of accidental data loss.
• Shifting conflict detection from "tell the user after the copy fails" to "show it up front at the selection step" meaningfully improved how safe the tool feels to use.