Re: [Duplicity-talk] [PATCH] Added command line options to use different prefixes for manifest/sig/archive files

[edgar . soldin]

thanks!

sorry to bother you again, but i just now realize that the descriptions for the 
manpage are still missing! could you please add them after --file-prefix in 
bin/duplicity.1 ? the syntax is quite obvious and can be checked via 'man -l 
bin/duplicity.1' with gnu man.

you could probably group the options together with one explanation text as they 
essentially do the same just to different files.

..ede/duply.net

On 30.01.2014 17:45, Matthew Lai wrote:
> Hi Edgar,
> 
> I've made the changes. Attached is the updated patch.
> 
> Thanks!
> Matthew
> 
> On 1/30/2014 2:56 AM, address@hidden wrote:
>> just a cosmetic but nonetheless an improvement request. we have a jungle of 
>> options already which grows kind of wildly .. the new options might fit in 
>> more structured when named like
>>
>> --file-prefix-manifest
>> --file-prefix-...
>>
>> as manifest and archive are written out words you might consider doing the 
>> same with signature.
>>
>> thanks ..ede/duply.net
>>
>>
>> On 30.01.2014 11:35, Kenneth Loafman wrote:
>>> This does look a lot safer.  Thanks!
>>>
>>>
>>> On Thu, Jan 30, 2014 at 3:49 AM, Matthew Lai <address@hidden 
>>> <mailto:address@hidden>> wrote:
>>>
>>>      Hello!
>>>
>>>      Please see attached for a patch that adds command line options to use 
>>> different prefixes for manifest/sig/archive files.
>>>
>>>      --manifest-file-prefix
>>>      --sig-file-prefix
>>>      --archive-file-prefix
>>>
>>>      This is useful, for example, when backing up to an Amazon S3 bucket 
>>> with life cycle rules to move archives to Glacier.
>>>
>>>      We can only move archives and not manifest files, because Duplicity 
>>> downloads manifest files on every incremental backup.
>>>
>>>      Life cycle rules can only match prefixes, not suffixes, which is a 
>>> little stupid, but otherwise S3 + Glacier is a very attractive backup 
>>> destination.
>>>
>>>      I do agree it makes more sense to fix it on the Amazon side (making 
>>> life cycle rules more flexible), but there's not much we can do about that.
>>>
>>>      PS. Someone has figured out an alternative workaround, but it's not 
>>> very safe: http://blog.epsilontik.de/?__page_id=68 
>>> <http://blog.epsilontik.de/?page_id=68>
>>>
>>>      Thanks!
>>>      Matthew
>>>