https://github.com/bakfile/bak

I created this project some years ago as a trivial Python applet, then abandoned it in a broken state, like you do, when life took over.

Over the intervening years, I’ve sat down a few times to rewrite it as native software. Life having set me free, I’ve now done it. Here’s what I told you fine folks the first time, redux:

---

bak replaces the cp foo.cfg foo.cfg.bak paradigm.

As terminal residents, many of us are in that habit. Before you modify a big, scary file, or a file that could have consequences if you mess it up, you make that .bak, and then you make your changes.

But maybe you forget about these files, and clutter your system with them. Maybe you find it clunky, all that diffing, all that rming and mving to restore a file. Maybe, like me, you take additional .bakups while you’re still working on the file, to save what you’ve done so far in a working state, in case you mess up the rest of the job. Now you’ve got foo.cfg.bak.4 and a headache.

bak keeps these files in a central, XDG-compliant directory, along with a little database relating the .bakfiles to their originals. It provides four basic commands, as well as some helpful extras. The basic commands are:

bak foo.cfg to create a .bakfile. You can do this as many times as you like. The interface will disambiguate when the time comes.

bak up foo.cfg to overwrite a .bakfile, rather than creating extras

bak down foo.cfg to restore a file (when you’ve screwed up)

bak off foo.cfg to delete .bakfiles (when you’ve succeeded in your mission)

These aren’t just meant to be clever. They’re very easy to remember after using them once or twice.

bak also offers the following:

bak list

bak diff foo.cfg (uses diff by default, configurable)

bak open [--in exec] foo.cfg to open or display a .bakfile in an external program (default cat; used to be $PAGER, but some users were annoyed about then needing to exit their PAGER)

bak where foo.cfg (outputs the absolute path of a .bakfile, if you need it for something like piping)

bak works very well for small files, but it simply wraps another copy utility - cp by default - unless you comment out a config line, in which case it uses an internal copy routine. Other than whatever errors your copy utility might throw, it does nothing to verify success, nothing to ensure that the .bakfile is not corrupted, and nothing to mitigate the speed of a copy operation. It performs no compression. You’re just making copies, exactly the same as if you did cp foo foo.bak - but sanely.

This way, you never have to worry about forgetting a .bakfile, you’ll always have an easy way to check your progress, and distinguishing between multiples is, at least, easier than it was without bak.

I haven’t packaged bak yet, but intend to do so in the coming weeks. For now, you can download an executable from the repository’s releases, or you can build it from source.

Initial work has also been done to allow bak to work on Windows, but, apart from compiling successfully and asking a layperson to run it, this is untested. It uses fd for diffing, start to open files, and copy for its copy operations. A Windows binary is also available from the ^ releases page.

The project doesn’t currently build on ARM. This is fixable, but I haven’t decided yet what I want to do about its dependency on sqlite3 (currently bundled to facilitate Windows.) If somebody wants a build for Intel Macs, I could probably furnish that, but I haven’t yet.

This is alphaware, nearing beta, once I nail down the platform situation. However, it’s fully usable, and I am using it regularly. A few, relatively minor features from the original are not yet implemented (tracking issues at the repo.)

Note: In the unlikely event that there’s anyone still using an old version of bak-python, please be warned that I have not written a migration routine. Due to certain deficiencies I hadn’t previously noticed in core Python modules, it turned out to be a lot of work, and I don’t think there are actually any users left who would benefit. However, if you’re out there, you should know that your existing bak.db is incompatible with the rewrite, and your existing .bakfiles will not be read into the new database. If a user exists for whom this is a problem, let me know, here or at the repository, and I’ll see what I can do about it.