creating a new archive after nuke requires a fsck about tarsnap HOT 3 OPEN

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

from tarsnap.

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.

from tarsnap.

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.

from tarsnap.