Tarsnap / tarsnap-gui

Cross-platform GUI for the Tarsnap backup service.

Home Page:https://www.tarsnap.com

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

first run shouldn't warn about a broken cache dir

gperciva opened this issue · comments

The first time you run the app, IMO it should automatically (and silently) create the cache directory. The current warning about a "broken or missing cache dir; run fsck to fix" is a bit unfriendly. (it implies that something is wrong)

Is this on a pristine environment? Where did the previous cache come from?

Fresh user account. Note the almost-completely-empty home directory. Here's the command-line:

blah@gin:~$ ls -al
total 20
drwxr-xr-x 2 blah blah 4096 Jan 28 10:27 .
drwxr-xr-x 6 root root 4096 Dec  2 17:54 ..
-rw-r--r-- 1 blah blah  220 Dec  2 17:54 .bash_logout
-rw-r--r-- 1 blah blah 3637 Dec  2 17:54 .bashrc
-rw-r--r-- 1 blah blah  675 Dec  2 17:54 .profile
blah@gin:~$ /tmp/tarsnap-gui/tarsnap-gui 
libGL error: failed to open drm device: Permission denied
libGL error: failed to load driver: i965
src/widgets/setupdialog.cpp(348): Registration details >>
 "/usr/local/bin" 
"/home/blah/.local/share/Tarsnap Backup Inc./Tarsnap" 
"/home/blah/.local/share/Tarsnap Backup Inc./Tarsnap/new-machine-name-2016-01-28-10-27-59.key" 
"/home/blah/.cache/Tarsnap Backup Inc./Tarsnap" 
"Executing [/usr/local/bin/tarsnap-keygen --user gperciva@tarsnap.com --machine new-machine-name --keyfile /home/blah/.local/share/Tarsnap Backup Inc./Tarsnap/new-machine-name-2016-01-28-10-27-59.key]" 
--------------------------------------------------------------------------------

"[/usr/local/bin/tarsnap-keygen --user gperciva@tarsnap.com --machine new-machine-name --keyfile /home/blah/.local/share/Tarsnap Backup Inc./Tarsnap/new-machine-name-2016-01-28-10-27-59.key] finished with exit code 0 and no output." 
-------------------------------------------------------------------------------- 
src/widgets/setupdialog.cpp(416): Settings location is  "/home/blah/.config/Tarsnap Backup Inc./Tarsnap.conf" 

(tarsnap-gui:4879): GConf-WARNING **: Client failed to connect to the D-BUS daemon:
Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
"Executing [/usr/local/bin/tarsnap --keyfile /home/blah/.local/share/Tarsnap Backup Inc./Tarsnap/new-machine-name-2016-01-28-10-27-59.key --cachedir /home/blah/.cache/Tarsnap Backup Inc./Tarsnap --list-archives -vv]" 
-------------------------------------------------------------------------------- 
"[/usr/local/bin/tarsnap --keyfile /home/blah/.local/share/Tarsnap Backup Inc./Tarsnap/new-machine-name-2016-01-28-10-27-59.key --cachedir /home/blah/.cache/Tarsnap Backup Inc./Tarsnap --list-archives -vv] finished with exit code 0 and no output." 
-------------------------------------------------------------------------------- 
"Executing [/usr/local/bin/tarsnap --keyfile /home/blah/.local/share/Tarsnap Backup Inc./Tarsnap/new-machine-name-2016-01-28-10-27-59.key --cachedir /home/blah/.cache/Tarsnap Backup Inc./Tarsnap --print-stats --no-humanize-numbers]" 
-------------------------------------------------------------------------------- 
"[/usr/local/bin/tarsnap --keyfile /home/blah/.local/share/Tarsnap Backup Inc./Tarsnap/new-machine-name-2016-01-28-10-27-59.key --cachedir /home/blah/.cache/Tarsnap Backup Inc./Tarsnap --print-stats --no-humanize-numbers] finished with exit code 1 and output:
tarsnap: Error reading cache directory from /home/blah/.cache/Tarsnap Backup Inc./Tarsnap
tarsnap: Error generating archive statistics
tarsnap: Error exit delayed from previous errors.
" 
--------------------------------------------------------------------------------

(the libGL errors and GConf-WARNING are not relevant)

In the GUI window right now, I've got the "... Run tarsnap fsck to fix this" message.

Apparently tarsnap-gui has created the .cache directory? However, running tarsnap-gui again still gives me the "... Run tarsnap fsck to fix this" error.

blah@gin:~$ ls -al .cache/Tarsnap\ Backup\ Inc./Tarsnap/
total 8
drwx------ 2 blah blah 4096 Jan 28 10:27 .
drwxrwxr-x 3 blah blah 4096 Jan 28 10:27 ..
blah@gin:~$ /tmp/tarsnap-gui/tarsnap-gui 

(tarsnap-gui:4927): GConf-WARNING **: Client failed to connect to the D-BUS daemon:
Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
libGL error: failed to open drm device: Permission denied
libGL error: failed to load driver: i965
"Executing [/usr/local/bin/tarsnap --keyfile /home/blah/.local/share/Tarsnap Backup Inc./Tarsnap/new-machine-name-2016-01-28-10-27-59.key --cachedir /home/blah/.cache/Tarsnap Backup Inc./Tarsnap --list-archives -vv]" 
-------------------------------------------------------------------------------- 
"[/usr/local/bin/tarsnap --keyfile /home/blah/.local/share/Tarsnap Backup Inc./Tarsnap/new-machine-name-2016-01-28-10-27-59.key --cachedir /home/blah/.cache/Tarsnap Backup Inc./Tarsnap --list-archives -vv] finished with exit code 0 and no output." 
-------------------------------------------------------------------------------- 
"Executing [/usr/local/bin/tarsnap --keyfile /home/blah/.local/share/Tarsnap Backup Inc./Tarsnap/new-machine-name-2016-01-28-10-27-59.key --cachedir /home/blah/.cache/Tarsnap Backup Inc./Tarsnap --print-stats --no-humanize-numbers]" 
-------------------------------------------------------------------------------- 
"[/usr/local/bin/tarsnap --keyfile /home/blah/.local/share/Tarsnap Backup Inc./Tarsnap/new-machine-name-2016-01-28-10-27-59.key --cachedir /home/blah/.cache/Tarsnap Backup Inc./Tarsnap --print-stats --no-humanize-numbers] finished with exit code 1 and output:
tarsnap: Error reading cache directory from /home/blah/.cache/Tarsnap Backup Inc./Tarsnap
tarsnap: Error generating archive statistics
tarsnap: Error exit delayed from previous errors.
" 
--------------------------------------------------------------------------------

This problem is related to the sequence of commands that the GUI executes when creating a new keyfile:

  1. tarsnap-keygen
  2. tarsnap --print-stats

Tarsnap doesn't create the cache upon --print-stats, however it would have done so if one issues tarsnap -c immediately after. Should I run fsck explicitly after tarsnap-keygen or maybe handle the issue in the CLI code, removing the hostile tarsnap reaction for this quite reasonable sequence of commands?

Hmm. I think that --fsck is overkill; it takes over 7 seconds on my quad-core machine with a fresh account with no online tarsnap data.

@cperciva? I can make tarsnap --print-stats work happily without a cachedir by doing:

diff --git a/tar/chunks/chunks_stats.c b/tar/chunks/chunks_stats.c
index cc9e922..8041b39 100644
--- a/tar/chunks/chunks_stats.c
+++ b/tar/chunks/chunks_stats.c
@@ -245,7 +245,7 @@ chunks_stats_init(const char * cachepath)

        /* Read directory. */
        if ((C->HT = chunks_directory_read(cachepath, &dir,
-           &C->stats_unique, &C->stats_total, &C->stats_extra, 1, 1)) == NULL)
+           &C->stats_unique, &C->stats_total, &C->stats_extra, 0, 1)) == NULL)
                goto err2;
        C->dir = dir;

where that 0->1 is the mustexist argument. However, I don't know if setting that to 1 was a deliberate choice or not.

Another option could be a new tarsnap --initialize-cache-directory, documented as being for GUI use and not needed for normal usage.

Any progress on this one?

Sorry, I didn't realize you were waiting for me. Please add --initialize-cachedir to the CLI; I don't want to change the mustexist value on --print-stats because it's useful for catching user error (outside of the GUI, users aren't likely to ask to view statistics when they haven't created any archives yet).

Shinnok, can you (a) check for tarsnap 1.0.38+, (b) use --initialize-cachedir if present, and (c) silence the warning if not?

Not sure if c) would achieve much. Maybe leave it there for <1.0.38 since the cache needs to be fixed at some point. Either I issue auto --fsck or leave to the user upon receiving the warning.

Upon reproducing this flow again I see that --list-archives creates the dir with message(addition in 1.0.37):
Directory /Users/shinnok/Library/Caches/Tarsnap Backup Inc./Tarsnap created for "--cachedir /Users/shinnok/Library/Caches/Tarsnap Backup Inc./Tarsnap"

However the dir is empty thus cache still "broken". What would --initialize-cachedir do exactly in comparison to this and fsck?

If the cache hasn't been initialized, it will be automatically initialized the first time an archive is created. So there's no need to run --fsck.

The --initialize-cachedir would actually initialize the directory rather than merely creating it -- the same way as --fsck does, except without needing to communicate with the server to get an (empty) list of blocks.

@cperciva Ok, that would suffice then.

Hi @shinnok , the tarsnap --initialize-cachedir argument has just been added to git master.

Awesome, I'll use it if CLI >= 1.0.38. For lower the warn box will pop up still.