first run shouldn't warn about a broken cache dir

Question

first run shouldn't warn about a broken cache dir

gperciva opened this issue 8 years ago · 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)

Shinnok · Answer 1 · Thu Jan 28 2016 18:06:03 GMT+0800 (China Standard Time)

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

Graham Percival · Answer 2 · Fri Jan 29 2016 02:30:50 GMT+0800 (China Standard Time)

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.
" 
--------------------------------------------------------------------------------

Shinnok · Answer 3 · Mon Feb 08 2016 20:53:26 GMT+0800 (China Standard Time)

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

tarsnap-keygen
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?

Graham Percival · Answer 4 · Tue Feb 09 2016 03:21:08 GMT+0800 (China Standard Time)

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.

Shinnok · Answer 5 · Tue Mar 15 2016 23:24:31 GMT+0800 (China Standard Time)

Any progress on this one?

Colin Percival · Answer 6 · Wed Mar 16 2016 08:13:43 GMT+0800 (China Standard Time)

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?

Shinnok · Answer 7 · Wed Mar 16 2016 15:51:53 GMT+0800 (China Standard Time)

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?

Colin Percival · Answer 8 · Wed Mar 16 2016 16:38:19 GMT+0800 (China Standard Time)

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.

Shinnok · Answer 9 · Wed Mar 16 2016 16:44:35 GMT+0800 (China Standard Time)

@cperciva Ok, that would suffice then.

Graham Percival · Answer 10 · Thu Apr 07 2016 05:27:03 GMT+0800 (China Standard Time)

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

Shinnok · Answer 11 · Thu Apr 07 2016 16:46:06 GMT+0800 (China Standard Time)

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