Re: Using dar for archives to optical discs

On 11/06/2023 15:27, John Goerzen wrote:
> On Tue, Jun 06 2023, Denis Corbin wrote:
>> For info, I have made available the slicing information of the archive of
>> reference present in a isolated catalogue (dar -l <cat> -q).
>>
>> this is enhancement is available in release candidate for version 2.7.10 (also
>> available in git on branch_2.7.x)
> 
> Thank you!  That'll be great!
> 
> Question: If the archive was made without -s/-S -- that is, one big
> slice -- will it be able to present the size of that one big slice?

if the backup is sliced, this information (slice size) with the number 
of slice (dar -l -Tslice) gives approximated overall backup size 
(accuracy is +/- half od a slice size)

But, correct, if the backup was not sliced, as the slice layout is just 
and exactly the values given to -S and -s options, this does not help 
providing an estimated size of the backup. You are back to fetching from 
the libdar API (C/C++ or Python) the offset of the last saved file... 
from which you can add the catalogue size and still have a approximated 
backup size...

You fall in a situation where the information you need is located in the 
backups, which have been destroyed, or better saying, have never been 
created (--dry-run option AFAIR)

there is still a possibility without coding something on top of the API, 
using the -Txml output (with dar -l). It gives you the storage size used 
for each file. You could gather all the stored="xxxx" fields from the 
output and sum them up to have a still approximated backup size.

	dar -l <backup> Txml -ay

adding -ay will be easier to sum up the storage sizes.


> 
> Thanks!
> 
> - John
>