[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Lzip-bug] lziprecover

From: Antonio Diaz Diaz
Subject: Re: [Lzip-bug] lziprecover
Date: Tue, 23 Apr 2013 18:31:17 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.7.11) Gecko/20050905

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

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

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,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]