[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Tarsnap GUI v0.8 released

Greetings from the pit,

I hope all your data from 2015 is safe and sound and that you're looking at 2016
with less worry of that kind than in previous years. And what better way to
celebrate that feat than with a new mint of Tarsnap GUI. Version 0.8 is fresh
out of the forge:

This release continues on the track already paved by the previous release in
terms of performance, code robustness and adherence to modern C++ practices
and UI consistency, adds a bunch of new features like simulation mode, skip
files flagged nodump in the file system and a persistent Journal, as well as
numerous other improvements, fixes and adjustments throughout the whole
spectrum. This release makes Tarsnap GUI leaner, faster and more robust

Full change log brought forward by this release:

Let's dive into some juicy details next:

1. The OS X Homebrew recipe has been updated and is now the preferred method of
installation for this platform. In addition the Formula has been submitted to
the upstream repo, although chances of it being accepted are small given the
no GUI general rule, although this particular app has some utility even
without having to use the UI daily:


Accepted or not, installing the latest version on OS X remains as simple as:

$brew install -v https://raw.githubusercontent.com/Tarsnap/tarsnap-gui/master/util/tarsnap-gui.rb && brew linkapps tarsnap-gui

2. This release features a Simulation mode. In addition to the description in
the CHANGELOG, I'd like to mention that general overall tarsnap stats are not
being updated while in this mode. Thus if you create several archives while in
Simulation mode, you can't expect their stats to cumulate and have a metric for
days of usage under Simulate. While this would have been cool to have, this
can't be done without actually uploading deduplicated chunks to the server or
talking with the server at all. At the moment, the biggest utility for
Simulate remains for evaluating single archives. Maybe this will turn out into
something more useful down the road.

3. As mentioned in the previous release, the code underwent a major refactoring
and cleanup, which is mostly done. The code is leaner, faster and more robust
as a result of that. Part of this was accomplished by adopting some C++11/14
and some Qt 5 goodness and part with the help good tooling. If you experience
trouble when building or at runtime, don't hesitate to report, though in my
testing nothing has changed but for the good.

4. The other pleasant surprises in this release are the persistent Journal and
storing archive contents as compressed blobs. Keeping a log of backup actions
and being able to review it at any time is a must for any backup practice. The
Journal serves that purpose now and is populated while in headless mode too.
On the latter, as you probably know already, archive contents are fetched and
cached when inspecting an archive. Up until now that the app stored plain text
listing in the local Sqlite DB cache. For big archives with many hundreds of
thousands of files (not that uncommon at all) handling and storing all that
text is going to be a performance and resource drag. Starting with this version,
the archive contents are stored as compressed zlib blobs and only decompressed
when needed for display. This has a significant positive impact on the app's
performance and resource usage.

5. There is no caveat when upgrading from v0.7. Everything should go smooth as

This release is the best offering to date and thus I strongly encourage
everyone to upgrade and follow back with feedback be it either positive or
negative. As always, I'm welcome to new ideas or CLI options coverage requests.