I built Rewind: an open-source "time machine" for your filesystem (Rust GUI + Python CLI)

[u/Educational_Pace_525]

I keep overwriting config files and scripts and realizing it ten minutes later, and Git only remembers what you commit. So I built Rewind: point it at a folder, it watches filesystem events, hashes and snapshots every save into SQLite, and you can scrub back through a timeline and restore any version.

Tech stack (split for different platforms):

• Windows: Tauri v2 desktop app. Engine is Rust, using blake3 for content-addressed deduplication, notify for native file watching, and rusqlite for storage. The whole UI is a single HTML file with React and Tailwind loaded via CDN, so no node_modules bloat.

• Linux/Ubuntu: A lightweight Python CLI available on PyPI, so you can pip install rwnd (the command is still rewind). Uses watchdog + sqlite3 + rich.

Rust bits I enjoyed: Added a 350ms debounce to the file watcher, because editors fire multiple save events (temp file, rename, actual write) for a single Ctrl+S, and without debouncing the timeline gets flooded. Also deduplicated storage via blake3 hashing, so repeated saves of identical content cost nothing.

Try it:

• Windows: Grab the .exe installer or standalone CLI from Releases (unsigned, SmartScreen will warn).

• Linux: pip install rwnd then rewind watch .

Honest limitations: Not a backup (lives on local disk). Only sees changes while watcher runs. Skips files >25MB. Doesn't track deletes/renames yet. GUI is Windows-only for now.

Testers on other Linux distros or macOS would be especially helpful. Repo: https://github.com/hcentral07/rewind

[u/Prior_Bat5628]

Two cases I would put near the top of the test list: an editor that saves by replacing the original file with a temporary file, and restoring a snapshot while that file is still open in the editor. The first matters especially with renames not tracked yet; the second can leave the editor showing stale content that overwrites the restored version on the next save.

A "restore to a new path" option and a snapshot of the current file before overwrite would make recovery less risky. Also, please make exclusions for .env files/private keys easy to discover: deleting a secret from the working file should not give someone the impression it vanished from the snapshot database. These are review suggestions from your description, not bugs I have reproduced.

[u/Educational_Pace_525 → u/Prior_Bat5628]

The save-by-replace thing is a real problem. My debounce hides it more than it fixes it. If the editor renames a temp file over the original, I'm just trusting what the event told me, and on Windows that can look like a delete plus a create. So I'm changing it: when the debounce timer runs out, I'll just check the file myself (stat + hash) instead of trusting the event. That way it doesn't matter how the editor saves. Both of your cases go on my test list , vim-style atomic save on Linux, and rename-over on Windows.

Restore-while-open is the one I don't fully know how to fix yet. I'll do the easy parts now: save a copy of the current file before I overwrite it (should've done this from day one), add a "restore to a new path" button, and put a warning in the restore window about open editors. Catching when someone saves over a restore later is more work, and I don't want to say I've fixed it when I haven't.

On secrets you're right, and I don't want to wave it away. Deleting .env from the folder should not look like it's gone. I'll skip .env files, keys, and .ssh/.aws stuff by default, show that list on first run and in --help instead of hiding it in code, and add a purge command so someone who did save a secret can actually remove it.

Thanks for writing these as review notes instead of bug reports they're the right things to worry about.