Re: [Fwd: Re: [Duplicity-talk] How do you list all files since the backup chain started]

[Kenneth Loafman]

address@hidden wrote:
> Hey Richard,
> two questions for Ken included ..
> 
>> I don't see the need (or any advantage) in totally re-writing the way
>> file information is
>> displayed. I feel that the above sort of listing may make things
>> harder to process this output via
>> a script or frontend application as the required information for a
>> file is split over a number of
>> lines.
>>   
> because it helps to keep the overview if _more_ then one files is listed,
> also having the same name multiple times would be redundant
> long path/filenames will have more spaces to be printed completely
> 
>> Perhaps just extending the output style we currently have would be
>> better e.g:
>>
>> Thu Oct 23 14:05:15 2008 12345 121 myfile
>> Thu Oct 24 14:05:15 2008 12360 122 myfile
>> Thu Oct 25 14:05:15 2008 12370 123 myfile
>>   
> I'd rather see the now missing, but imho very helpful backup datetime
> value on the end of the line
> 
>> Ordering the list by date and then by filename. That way we can
>> process the output and all
>> relevant data regarding a file from one line and in the following
>> space separated format:
>>
>> timestamp [space] osize [space] csize [space] filename [newline]
>>   
> 
> One objects versions of course shuould be listed together, about the
> order (oldest, youngest first) I don't have  a preference
> 
>> The osize and csize would be "original size" and "compressed size" if
>> we could have that much info
>> that would be nice too :-)
>>   
> 
> why would you want to have the compressed size here?
> @Ken .. is this value available?

No, the tar file is compressed, not the individual files.  On
incremental backup all we store are the changed blocks, so you could
just use that size instead.

> any preference if size should be human readable? eg. 25M instead of
> 26082972 ... Usually duplicity is used in the shell by now, so it would
> maybe help the readability of an entry. But this could be kept optional
> for later as well.
> 
>> Also, is there any way to display what the object is. For example, in
>> the above listing's we have
>> no idea of knowing if "myfile" was actually a directory, a file, a
>> symlink etc. Perhaps having a
>> flag in the output may help?
>>
>> timestamp [space] osize [space] csize [space] flag [space] filename
>> [newline]
>>
>> These flags could be something really simple:
>>
>> F = File
>> D = Dir
>> L = Symlink
>>   
> 
> good idea,
> again: @Ken can duplicity deliver these

There are file types for all of those.

>> I don't know if this is another request or an addition to the current
>> one :-) I'm just trying to
>> figure out how we can make things easier for a frontend to manage and
>> process the outputed data.
>>   
> 
> as I am maintaining ftplicity, a shell frontend to duplicity by now, and
> would have to write a parser, I can't see the advantage of having the
> file name in every line. Every standardized way would suffice, as long
> as it's describable as regular expression, which both ways are.
> Actually I am planning to write a restore all versions from/to time into
> ftplicity, so I will need at least --list-at-time function or even
> better this multi purpose --list-files
> 
> regards ede
> 
> 
> _______________________________________________
> Duplicity-talk mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/duplicity-talk
>

signature.asc
Description: OpenPGP digital signature