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

[edgar . soldin]

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?

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

> 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