duplicity-team team mailing list archive

[Kenneth Loafman <kenneth@xxxxxxxxxxx>]

Peter Schuller wrote:
>>>  ~/.duplicity/<backup_name>/cache - cache files, removable at any time
>>>  ~/.duplicity/<backup_name>/config - backup profile configs, etc
>>>  ~/.duplicity/<backup_name>/checkpoints - checkpoint info
>> That really should be:
>> $XDG_CACHE_HOME/duplicity/<name> (aka ~/.cache/duplicity/<name>),
>> $XDG_CONFIG_HOME/duplicity/<name> (aka ~/.config/duplicity/<name>), and
>> $XDG_CONFIG_HOME/duplicity/<name>/checkpoints (maybe, not really clear
>> on what all checkpoint data is)
>>
>> See http://standards.freedesktop.org/basedir-spec/latest/
> 
> Great. I was already thinking the 'cache' should be separated at the
> "root" level, but wasn't aware there was an actual freedesktop
> standard. I think it's a great idea to follow that. Random dumping of
> "bulk data" into home directories in a way which isn't easily
> excluded, is a pet peeve of mine :)
> 
>> Using those fields makes life so much easier.  I know we already
>> shipped a version that uses ~/.duplicity, but wherever possible, use
>> the XDG spec.  That way, applications can treat the directories
>> appropriately.  For example, Deja Dup excludes $XDG_CACHE_HOME by
>> default.
> 
> Agreed. 
> 
>>> I do to, but in practice I know for a fact most people simply don't do
>>> that. Backing up a live file system is standard practice,
>>> unfortunately. I've had to work pretty hard to convince people it's a
>>> bad idea, even among "techies".
>> I'm one of those people that encourages non-quiescent backups by
>> virtue of Deja Dup almost always running when non-quiescent.  The user
>> is logged in and almost certainly doing something.  It's an important
>> use case for me.
> 
> Yes, absolutely. There  are plenty of practical cases  where it's just
> the only viable  option, especially if you want to  be friendly to the
> user.
> 
> (In some ideal mythological world we'd have an API to request a
> snapshot of a particular path in an fs/volume management/root perms
> independent way.)

OK, I think the message is clear, but the problem is that adhering to
standards after the fact is going to mean some extra coding to move
files around during the first run of the new package.  Maybe later.

Back to the smart-archive-dir branch (merged), I've been playing with it
and I think it should do things a bit differently, namely:

  --archive-dir  changes the base dir (default ~/.duplicity)
  --name         changes the sub-dir name (default hash of URL)

In any use case, the path to the archive dir is given by:
  os.path.join(globals.archive_dir, globals.backup_name)

Right now, you can change archive dir, but it loses name, or you can
leave the default archive dir and either use the name or the hash.

This gives us great flexibility, and to me is less confusing.

Thoughts?

...Ken