Re: [Tarsnap GUI] RFC: Automatic job backup and more

[Daniel Staal <DStaal@usa.net>]

--As of June 23, 2015 10:56:29 AM +0300, Shinnok is alleged to have said:

> I'd like to change the default directory for newly generated keys(via the
> Setup Wizard for now) from the system specific APPDATA ones, which
> currently are:
> 1. ~/.local/share/ on Linux/BSD
> 2. ~/Library/Application Support/ on OS X
>
> To just ~/Documents. The reasoning behind it is that we shouldn't hide
> the keys in such obscure places since they are not transient nor
> expendable, whereas the application's data is. We also invite the user to
> keep the key safe(on wizard complete), but then provide a path that he's
> most likely to ignore in first instance and then completely forget about
> it. Another aspect to consider is that a user should be a bit more
> careful with stuff residing Documents, rather than some obscure hidden
> system paths. Think backups, system restore or system reset.

--As for the rest, it is mine.

I would disagree here - Application Support is exactly where I'd expect 
this type of file to reside.  'Documents' to me is the user-created docs 
that the user has created and worked on directly, whereas these keys are 
indirect.  Documents also is stuff that the users talk about with each 
other, copy around to share, etc.  None of which they should be doing with 
Tarsnap keys.

In fact, for your app I'd really be tempted to put them in 
`/Library/Application Support/` - the top-level system where any user might 
in theory be able to use them, depending on the situation.  (More likely 
for write-only keys.)

In short: 'Documents' is *more* expendable than 'Application Support' - 
'Documents' are the documents the user is working on, while 'Application 
Support' is what you need to run the programs that work on the files in 
'Documents'.

In both cases the user should be backing up the complete $HOME dir, not 
just their documents folders if they want to be able to restore their work 
area to what it was before, so saying it's 'obscure' is irrelevant: We 
kinda *want* to be able to forget about the exact key and it's location, 
and this is a location that should by default be included in backups and 
recovery procedures.

Daniel T. Staal

---------------------------------------------------------------
This email copyright the author.  Unless otherwise noted, you
are expressly allowed to retransmit, quote, or otherwise use
the contents for non-commercial purposes.  This copyright will
expire 5 years after the author's death, or in 30 years,
whichever is longer, unless such a period is in excess of
local copyright law.
---------------------------------------------------------------