Hello Ole.
Ole Tange wrote:
I was puzzled that nothing happened and 'lziprecover -v' was just
sitting there. That is until I did 'ls'. Oh my freaking god! 58000
files.
I recognize I didn't even think about so many members in a file.
I even got: newton.log.lzip lziprecover: too many members in file
(there seems to be a limit at 100000 parts - is there any reason for
that?).
Yes. It is the same limit bzip2recover uses. :-)
As I see the current limit is not large enough, I'll implement an
improvement I had already planned. I'll make lziprecover to use just the
needed decimal positions for the number of members in the input file.
For example, a file with 6 members will use names like 'rec1<name>',
while a file with 6 million members will use names like 'rec0000001<name>'.
I had expected -v would be somewhat more verbose (e.g. telling me it
was writing files).
Splitting files (with not so many members) is fast, so I didn't use -v
on it. I'll make it more verbose now.
But another improvement I have planned is to repair (or merge) the files
'in place', without having to split them before. Stay tuned. :-)
And I would like an option to 'lzcat' the result instead of putting it
into files.
I do not understand. Do you mean something like 'lziprecover -cd file.lz'?
Best regards,
Antonio.
_______________________________________________
Lzip-bug mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/lzip-bug
