dedupe+compression test dry-run without keyfile about tarsnap HOT 7 CLOSED

Answer from Colin:

It's not possible right now. The issue here is that there is a key used to determine how data is split into chunks, so even if nothing is being encrypted and uploaded, getting an accurate value will depend on having generated keys.

At some point, running that command should result in tarsnap printing a warning (e.g., "No keys loaded - using fake keys for tarsnap dry run") and generating temporary keys. To be specific, this should happen if tarsnap is being run in mode -c, the --dry-run option is specified, and no --keyfile option has been specified. (If a keyfile was provided but it doesn't have the right keys, we want to die loudly, because that's almost certainly PEBKAC.)

from tarsnap.

Also, why does --dry-run require an archive name? It isn't taken into account (it doesn't check with the server so it won't warn if an archive of the same name already exists).

from tarsnap.

Ooh, junior hacker task here! A much easier one than generating fake keys.

The reason --dry-run needs an archive name is that the archive name gets stored in the archive metadata, which is then encrypted and signed and dry-run stored (aka not stored but it gets added to the statistics).

Solution: If the user specifies --dry-run and does not specify -f, set a fake archive name -- I'd go with something like "(dry-run)" just in case it gets exposed anywhere visible (I don't think it does right now, but it's best to have an obviously fake name in case it gets exposed at some point in the future).

from tarsnap.

Umm. This is a much more "junior" task than you anticipated. :P

I'll just let 3e6431b speak for itself. (in case there's any doubt, expand the comment above the change)

from tarsnap.

Uhh... yeah, I guess I tried to do this years ago and didn't test whether the change I was making actually fixed it... it's even mentioned in the 1.0.27 release notes. sigh

from tarsnap.

This is now included in PR #12. Turns out I misunderstood how keygen was happening, so all that refactoring of keygen.c and keyregen.c was irrrelevant to this. (I'll still finish it up and send it in, though)

from tarsnap.

PR #12 fixed this; will be included in tarsnap 1.0.36.

from tarsnap.