creating a new archive after nuke requires a fsck

[gperciva]

It would be nice if we could do

tarsnap --nuke
tarsnap -c -f whatever ~/whatever

without having a tarsnap --fsck in between those commands. (on a slightly related note, it would be nice if --nuke and --fsck finished quicker if there was no data in tarsnap; right now fsck takes 10 seconds. Although if fsck is no longer required, that part is moot (or at least mooter)).

[cperciva]

Leaving breadcrumbs for myself when I come back to this issue later: The reason we need a fsck is because tarsnap -c needs to know what bits are on the server already. If we have only the write keys, we can't issue a NETPACKET_DIRECTORY request, so we can't list what's on the server (and without the read keys, we can't figure out how many times each block is used).

But if we add a new NETPACKET_WRITE_ISEMPTY request to the client-server protocol, the tarsnap client would be able to detect that there is no data at all, and then initialize the chunks directory based on that.

[defuse]

This led to some mildly-frustrating usability problems for me.

I'm using Tarsnap on two computers. The less-likely-to-be-hacked of the two has the entire key for the "machine" and the other -- the one that's actually being backed up -- has a write-only key for the "machine." I accidentally backed up too much data and figured it'd be easiest to lower my monthly bill by --nukeing everything and starting fresh.

So I ran --nuke from the entire-key computer, and when I tried to run a backup from the write-key computer, it told me I needed to run --fsck. When I tried to run --fsck on the write-key computer, it told me it needed the read key. I don't want the read key to ever touch the write-key computer. I tried running --fsck on the entire-key computer but it didn't help.

For a second I thought I was going to have to go through the whole key-generation process again (which would be problematic since I have the key backed up in hard-to-reach places), but I resolved it by copying the entire-key computer's cache directory to the write-key computer.

Tarsnap would be better if this edge case was easier to deal with/recover from.

[gperciva]

Hi @defuse,

Yes, it would be nice if we supported this case.

On a slightly related note, we updated our docs about running Tarsnap on multiple machines a few days ago, primarily to add the "copy cachedir around" idea. I suspect that you might already know all this info, but just in case, it might be worth giving it a quick skim: http://www.tarsnap.com/multiple-machines.html