RAR under linux: any alternative?
Gabriel
Gabriel Parrondo
Oliver Lupton
Gabriel <nqtnn...@gmail.com> wrote:
> Does anyone know a free software alternative to RAR???
Use 'tar' combined with gzip or bzip2 to create a .tar.gz or .tar.bz2
man tar, man bzip2 and man gzip for more info :)
HTH
-ol
--
I will live forever, or die trying.
Gabriel
On Sat, 10 Dec 2005 23:02:50 -0300 Gabriel <nqtnn...@gmail.com> wrote:Does anyone know a free software alternative to RAR???Use 'tar' combined with gzip or bzip2 to create a .tar.gz or .tar.bz2 man tar, man bzip2 and man gzip for more info :) HTH -ol
So I want it so the next time it happens I won't give anyone the chance to defame GNU =P
sorry for the bad english
Gabriel Parrondo
Oliver Lupton
Gabriel <nqtnn...@gmail.com> wrote:
> yeah, I know that, but I was talking about a program to decompress RAR
> files...
Ah okay, I misinterpreted what you meant :)
Cheers,
Steve Kemp
> yeah, I know that, but I was talking about a program to decompress RAR
> files... I know I don't really need it, but today a friend sent me a rar
> file and I needed to tell him to recompress it as zip and send it
> again... (of course that the first thing he did was talk about the
> dis-advantages of using GNU/Linux...)
> So I want it so the next time it happens I won't give anyone the chance to
> defame GNU =P
You can use the 'apt-cache' command to search for programs by
keywords. For example running:
apt-cache search rar unrar
Gives you this in the output:
unrar-free - Unarchiver for .rar files
unrar - Unarchiver for .rar files (non-free version)
Install it as usual:
apt-get install unrar-free
Then use it with:
unrar-free x file.rar (From memory, I haven't used it for a while).
You can also search for packages on the Debian website at:
Steve
--
Debian GNU/Linux System Administration
http://www.debian-administration.org/
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Gabriel
On Sat, Dec 10, 2005 at 11:35:35PM -0300, Gabriel wrote:yeah, I know that, but I was talking about a program to decompress RAR files... I know I don't really need it, but today a friend sent me a rar file and I needed to tell him to recompress it as zip and send it again... (of course that the first thing he did was talk about the dis-advantages of using GNU/Linux...)So I want it so the next time it happens I won't give anyone the chance to defame GNU =PYou can use the 'apt-cache' command to search for programs by keywords. For example running: apt-cache search rar unrar Gives you this in the output: unrar-free - Unarchiver for .rar files unrar - Unarchiver for .rar files (non-free version) Install it as usual: apt-get install unrar-free Then use it with: unrar-free x file.rar (From memory, I haven't used it for a while). You can also search for packages on the Debian website at: http://packages.debian.org/ Steve
Now I found the package unrar-free, but it won't work unless the rar files are from a version <3.0.
I also tried with p7zip... the POSIX version of 7-zip... but it doesn't support rar files...
If anyone else know about an application that works with rar files =>3.0 I'll be really pleased.
I give up.
Gabriel Parrondo
Anton
>Does anyone know a free software alternative to RAR???
apt-cache search rar|grep archiv
--
Regards , Anton Filippov .
Jacob S
Gabriel <nqtnn...@gmail.com> wrote:
> Steve Kemp wrote:
> > apt-cache search rar unrar
> >
> > Gives you this in the output:
> >
> > unrar-free - Unarchiver for .rar files
> > unrar - Unarchiver for .rar files (non-free version)
^^^^^
> Thank you so much... I had searched with "apt-cache search rar" but
> it came up with a lot of packages...
> Now I found the package unrar-free, but it won't work unless the rar
> files are from a version <3.0.
> I also tried with p7zip... the POSIX version of 7-zip... but it
> doesn't support rar files...
>
> If anyone else know about an application that works with rar files
> =>3.0 I'll be really pleased.
> I give up.
If you noticed, the output from apt-cache that Steve quoted showed two
packages for unpacking .rar files. One was unrar-free, which you tried
and the other was 'unrar'. If you do an "apt-cache show unrar-free" it
will also mention that the non-free version of unrar can unpack .rar
files =>3.0.
You might want to apt-get install unrar (and rar while you're at it, if
you have any need to pack .rar files) and see if it works better for
you.
HTH,
Jacob
Eike Lantzsch
> >Gabriel <nqtnn...@gmail.com> wrote:
> >>Does anyone know a free software alternative to RAR???
[snip]
You might try unrar-free.
Have fun
Eike
--
Eike Lantzsch ZP6CGE
Casilla de Correo 1519
Asuncion / Paraguay
Tel.: 595-21-578698 FAX: 595-21-578690
Micha Feigin
Gabriel <nqtnn...@gmail.com> wrote:
> Oliver Lupton wrote:
>
> >On Sat, 10 Dec 2005 23:02:50 -0300
> >Gabriel <nqtnn...@gmail.com> wrote:
> >
> >
> >
> >>Does anyone know a free software alternative to RAR???
> >>
> >>
> >
> >Use 'tar' combined with gzip or bzip2 to create a .tar.gz or .tar.bz2
> >man tar, man bzip2 and man gzip for more info :)
> >
> >HTH
> >
> >-ol
> >
> >
> >
> >
> yeah, I know that, but I was talking about a program to decompress RAR
> files... I know I don't really need it, but today a friend sent me a rar
> file and I needed to tell him to recompress it as zip and send it
> again... (of course that the first thing he did was talk about the
> dis-advantages of using GNU/Linux...)
> So I want it so the next time it happens I won't give anyone the chance
> to defame GNU =P
>
aptitude search rar gives for relevant results:
i rar - Archiver for .rar files
p rar-2.80 - Archiver for .rar files
p unrar - Unarchiver for .rar files (non-free version)
p unrar-free - Unarchiver for .rar files
The first three are non-free in the GNU sense but can handle all rar files
(apt-cache show claims that they are shareware but thats the only reference to
that issue). rar and unrar are in the non-free section, rar-2.80 is in main
although it also claims to be shareware. unrar-free is free in the GNU sense,
but can't handle files from rar >= 3.0.
BTW, if you look at the windows version, it is also shareware and there is no
free alternative, so there is no ground for linux bashing here since in this
case your problem is ideological, not technical (there are accessible although
technically non-free solutions, you just don't want to use them and they are
equivalent to the windows ones)
>
> sorry for the bad english
>
> --
>
>
> ------------------------------------------------------------------------
>
> *Gabriel Parrondo*
>
>
>
> +++++++++++++++++++++++++++++++++++++++++++
> This Mail Was Scanned By Mail-seCure System
> at the Tel-Aviv University CC.
+++++++++++++++++++++++++++++++++++++++++++
This Mail Was Scanned By Mail-seCure System
at the Tel-Aviv University CC.
steef
google around and you will find a free debian.rar package. as ic
remember4 well:
> rar_3.30-2_i386.deb
you can - if i still remember well *unrar* a .rar-file with it on the
(unofficial) debian_way
( i did not read the whole thread, so maybe i tell you things you
already know)
kind regards,
steef
groningen
netherlands
Gnu-Raiz
This is one program that I believe is worth buying the license
for. This is especially true if you have any windows
machine's around. If you use Usenet for any amount of time
you will find that this program is a must have.
Try sending a tar file to a window only user, they might of
seen rar or tar. One thing good about WinRAR is it can zip,
a file for all your non rar, tar buddies.
It's kind of like needing Lame, or Mplayer nowadays, yes
it's non free, but you really do need it.
Gnu_Raiz
Gnu-Raiz
The Window Version comes with the nice GUI, where as the
*nix version is only commandline. If one really needs the
GUI you can run it under wine.
Also the Unrar version has limitations, like you can not
archive with it. But then again as mentioned above in this
thread, you can use tar for that.
I agree totally that there is no need for Linux bashing as
the tools are available.
I do see a stigma with rar, in 98.99% of the time a rar file
is used in the archiving of alt.binaries newsgroups. So if
someone mentions a rar file some people assume that it could
be a copyright vilolation. I don't have a problem with that
but I know some people do, if your in a educational setting
you might be hard pressed to have unrar or rar installed.
It's kind of like bittorrent to the avearage person, if
someone uses bittorrent then they must be pirates. I know
some people who think that as well. Of course you probably
know what the MPAA, RIAA think about it as well.
Gnu_Raiz
John Hasler
> This is one program that I believe is worth buying the license for. This
> is especially true if you have any windows machine's around. If you use
> Usenet for any amount of time you will find that this program is a must
> have.
Interesting. I've been on Usenet for twenty years and I have not felt any
need for that program.
> It's kind of like needing Lame, or Mplayer nowadays, yes it's non free,
> but you really do need it.
Mplayer is licensed under the GPL.
--
John Hasler
Thomas Jollans
>Gnu_Raiz writes:
>
>
>>This is one program that I believe is worth buying the license for. This
>>is especially true if you have any windows machine's around. If you use
>>Usenet for any amount of time you will find that this program is a must
>>have.
>>
>>
>
>Interesting. I've been on Usenet for twenty years and I have not felt any
>need for that program.
>
>
>
>>It's kind of like needing Lame, or Mplayer nowadays, yes it's non free,
>>but you really do need it.
>>
>>
>
>Mplayer is licensed under the GPL.
>
>
and lame is free software as well. it is however illegal to use or
distribute it because of Frauenhofer patents. Mplayer is not included in
debian because of patent issues as well afaik. it strikes me as odd that
xine, a fork of mplayer, is included in debian.
I have never felt the need for RAR, although I have a lot of contact
with windows users. They all use zip. The only thing that I sometimes
have as rar are windows binaries or similiar, which I then open with
7-Zip under windows (as the contents of rar files have never been any
use to me outside windows). It strikes me as odd that the posix 7zip
doesn't support rar - the windows version does.
Georgi Alexandrov
>The Window Version comes with the nice GUI, where as the
>*nix version is only commandline. If one really needs the
>GUI you can run it under wine.
>
>
You are one of those guys that like to complex their life just for fun? ;-)
You need to unrar a .rar file, and you will install and configure wine,
then install
and run in wine the win32 version of rar? Sounds great!
Gabriel
user@localhost:~$ apt-cache search rar unrar
comix - GTK Comic Book Viewer
unrar-free - Unarchiver for .rar files
No, I don't have non-free repositories... and no, I don't want them.
In fact, one of the things I said was:
Does anyone know a free software alternative to RAR???
Aight, that's it.
Thanks to everyone.
Gabriel Parrondo
Gnu-Raiz
> Gnu_Raiz writes:
> > This is one program that I believe is worth buying the license for. This
> > is especially true if you have any windows machine's around. If you use
> > Usenet for any amount of time you will find that this program is a must
> > have.
>
> Interesting. I've been on Usenet for twenty years and I have not felt any
> need for that program.
>
> > It's kind of like needing Lame, or Mplayer nowadays, yes it's non free,
> > but you really do need it.
>
> Mplayer is licensed under the GPL.
> --
> John Hasler
Luke, Luke come to the dark side Luke! I think it is strange
that when a person mentions Usenet all they think about is
the text groups.
It's the other left folks, the alt.binaries side that use's
rar files. Yes their is plenty of uses without copyright
infringement. If your into video and working on a project
and someone asks for a sample if you use zip, or tar they
will probably laugh at you. How else are you going to get a
uniform file size of say 15mb each in your sample if you
don't use rar?
Gnu_Raiz
Sean Davis
> On 11:49, Sun 11 Dec 05, John Hasler wrote:
> > Gnu_Raiz writes:
> > > This is one program that I believe is worth buying the license for. This
> > > is especially true if you have any windows machine's around. If you use
> > > Usenet for any amount of time you will find that this program is a must
> > > have.
> >
> > Interesting. I've been on Usenet for twenty years and I have not felt any
> > need for that program.
> >
> > > It's kind of like needing Lame, or Mplayer nowadays, yes it's non free,
> > > but you really do need it.
> >
> > Mplayer is licensed under the GPL.
> > --
> > John Hasler
>
>
> Luke, Luke come to the dark side Luke! I think it is strange
> that when a person mentions Usenet all they think about is
> the text groups.
>
> It's the other left folks, the alt.binaries side that use's
> rar files. Yes their is plenty of uses without copyright
> infringement. If your into video and working on a project
> and someone asks for a sample if you use zip, or tar they
> will probably laugh at you. How else are you going to get a
> uniform file size of say 15mb each in your sample if you
> don't use rar?
split(1). Been around since AT&T Version 6.
Alex Malinovich
--snip--
> will probably laugh at you. How else are you going to get a
> uniform file size of say 15mb each in your sample if you
> don't use rar?
tar cz sample/ | split -db 15m - sample.tar.gz
Would work just fine for me.
Or, if you have to use something more windows friendly, zipsplit would
do the trick as well.
--
Alex Malinovich
Support Free Software, delete your Windows partition TODAY!
Encrypted mail preferred. You can get my public key from any of the
pgp.net keyservers. Key ID: A6D24837
Steve Lamb
> split(1). Been around since AT&T Version 6.
Now verify each portion has no errors in it with split. Oh, wait, ya
can't. That's because it is just a rough split and not an actual archive
which can be verified.
--
Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
PGP Key: 8B6E99C5 | main connection to the switchboard of souls.
-------------------------------+---------------------------------------------
Wesley J. Landaker
> Sean Davis wrote:
> > split(1). Been around since AT&T Version 6.
>
> Now verify each portion has no errors in it with split. Oh, wait, ya
> can't. That's because it is just a rough split and not an actual archive
> which can be verified.
Well, just use md5sum, sha1sum, etc. Or use .zip with zipsplit -n . . . I
don't see that rar has any particular advantage there.
--
Wesley J. Landaker <w...@icecavern.net> <xmpp:w...@icecavern.net>
OpenPGP FP: 4135 2A3B 4726 ACC5 9094 0097 F0A9 8A4C 4CD6 E3D2
Gnu-Raiz
That's good I like it, infact I might have to try that! Then
I have to explain to them what tar is how to find a window's
client all that sort. Agreed, most competent people probably
won't have a problem with it. Other then where is the GUI to
tar. Trust me I have been asked some weird stuff.
Gnu_Raiz
Steve Lamb
> Well, just use md5sum, sha1sum, etc.
Against what, exactly? How do these verify the contents within that
discrete piece of the archive?
> Or use .zip with zipsplit -n . . . I
> don't see that rar has any particular advantage there.
Point being was that split is a very clunky way to do things. Rar's
splitting is far superior to both the above mentioned hacks.
Alex Malinovich
> Wesley J. Landaker wrote:
> > Well, just use md5sum, sha1sum, etc.
>
> Against what, exactly? How do these verify the contents within that
> discrete piece of the archive?
The same way that RAR does. They tell you whether that discreet part of
the archive is corrupted or not. If it is corrupted it's just as useless
whether it's a RAR archive or any other type of archive.
> > Or use .zip with zipsplit -n . . . I
> > don't see that rar has any particular advantage there.
>
> Point being was that split is a very clunky way to do things. Rar's
> splitting is far superior to both the above mentioned hacks.
Sorry, but I'm just not seeing it. If RAR had some recovery features
along the lines of PAR, I might be more impressed. But seeing as how PAR
works with any type of a multi-part archive I'm just not seeing any
particular strength to using RAR.
Sean Davis
> Sean Davis wrote:
> > split(1). Been around since AT&T Version 6.
>
> Now verify each portion has no errors in it with split. Oh, wait, ya
> can't. That's because it is just a rough split and not an actual archive
> which can be verified.
That's what checksums are for.
Micha Feigin
Gnu-Raiz <Gnu-...@midsouth.rr.com> wrote:
> On 17:32, Sun 11 Dec 05, Alex Malinovich wrote:
> > On Sun, 2005-12-11 at 17:59 -0600, Gnu-Raiz wrote:
> > --snip--
> > > will probably laugh at you. How else are you going to get a
> > > uniform file size of say 15mb each in your sample if you
> > > don't use rar?
> >
> > tar cz sample/ | split -db 15m - sample.tar.gz
> >
> > Would work just fine for me.
> >
> > Or, if you have to use something more windows friendly, zipsplit would
> > do the trick as well.
> >
> > --
> > Alex Malinovich
> > Support Free Software, delete your Windows partition TODAY!
> > Encrypted mail preferred. You can get my public key from any of the
> > pgp.net keyservers. Key ID: A6D24837
> >
>
> That's good I like it, infact I might have to try that! Then
> I have to explain to them what tar is how to find a window's
> client all that sort. Agreed, most competent people probably
> won't have a problem with it. Other then where is the GUI to
> tar. Trust me I have been asked some weird stuff.
>
IIRC both winzip and winrar can handle .tar.gz file, I don't think that they handle .tar.bz2 files though.
> Gnu_Raiz
>
>
> --
> To UNSUBSCRIBE, email to debian-us...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
>
>
> +++++++++++++++++++++++++++++++++++++++++++
> This Mail Was Scanned By Mail-seCure System
> at the Tel-Aviv University CC.
>
+++++++++++++++++++++++++++++++++++++++++++
This Mail Was Scanned By Mail-seCure System
at the Tel-Aviv University CC.
Steve Lamb
> The same way that RAR does. They tell you whether that discreet part of
> the archive is corrupted or not. If it is corrupted it's just as useless
> whether it's a RAR archive or any other type of archive.
Bzt, try again. I asked "against what". You create the archives and
they're sitting there on the disc. You use whatever tool you want and it
spits out a value. Against what do you check that value? There is no
reference to check against. RAR, on the other hand, computes the value for
the files inside the archive and stores that value *in the archive itself*.
Later when you ask it to check the validity of the archive it can reference
the stored value.
> Sorry, but I'm just not seeing it. If RAR had some recovery features
> along the lines of PAR, I might be more impressed.
Be impressed. Why do you think one of the reasons unrar-free can't deal
with >= 3.00 rar files? From RAR's 3.0 notes:
9. Added support of so called recovery volumes (.rev files), which can be used
to reconstruct missing files in a volume set. One .rev file allows to
reconstruct one missing RAR volume, for example, 5 .rev files are able to
reconstruct any 5 volumes.
> But seeing as how PAR
> works with any type of a multi-part archive I'm just not seeing any
> particular strength to using RAR.
Combine the above. Again, reference against what? That information needs
to be created and stored at the time of creation. Having an md5sum 3 months
later with nothing to check it against is useless.
Alex Malinovich
> Alex Malinovich wrote:
> > The same way that RAR does. They tell you whether that discreet part of
> > the archive is corrupted or not. If it is corrupted it's just as useless
> > whether it's a RAR archive or any other type of archive.
>
> Bzt, try again. I asked "against what". You create the archives and
> they're sitting there on the disc. You use whatever tool you want and it
> spits out a value. Against what do you check that value? There is no
> reference to check against. RAR, on the other hand, computes the value for
> the files inside the archive and stores that value *in the archive itself*.
> Later when you ask it to check the validity of the archive it can reference
> the stored value.
That's why you include a checksums file with the archive set and/or list
the sums at the point of origin (web site, FTP site, etc).
> > Sorry, but I'm just not seeing it. If RAR had some recovery features
> > along the lines of PAR, I might be more impressed.
>
> Be impressed. Why do you think one of the reasons unrar-free can't deal
> with >= 3.00 rar files? From RAR's 3.0 notes:
>
> 9. Added support of so called recovery volumes (.rev files), which can be used
> to reconstruct missing files in a volume set. One .rev file allows to
> reconstruct one missing RAR volume, for example, 5 .rev files are able to
> reconstruct any 5 volumes.
>
> > But seeing as how PAR
> > works with any type of a multi-part archive I'm just not seeing any
> > particular strength to using RAR.
>
> Combine the above. Again, reference against what? That information needs
> to be created and stored at the time of creation. Having an md5sum 3 months
> later with nothing to check it against is useless.
I don't know, maybe I'm just dense or something, but explain to me why
you would WANT to put that information in the archive itself? If an
archive is CORRUPTED (which is why we're distributing the sums and the
PARs in the first place), what good will it be that the sums and
recovery info are IN the file? It's ALREADY corrupt, so what makes you
think the recovery data wouldn't be corrupt right along with it?!
Or am I just missing something painfully obvious here?
Steve Lamb
> That's why you include a checksums file with the archive set and/or list
> the sums at the point of origin (web site, FTP site, etc).
Which still tells you nothing of the files inside.
>>9. Added support of so called recovery volumes (.rev files), which can be used
>>to reconstruct missing files in a volume set. One .rev file allows to
>>reconstruct one missing RAR volume, for example, 5 .rev files are able to
>>reconstruct any 5 volumes.
> I don't know, maybe I'm just dense or something, but explain to me why
> you would WANT to put that information in the archive itself?
What, the checksums? Uh, so the reference is where you need it, with the
archive. No need to go external. Also since the checksums are on a
per-file-inside-the-archive basis you can see what files are corrupt and
extract around that. Something tar, esp. split tars, is utterly incapable of.
Trust me, I tried.
> If an archive is CORRUPTED (which is why we're distributing the sums and the
> PARs in the first place), what good will it be that the sums and
> recovery info are IN the file?
Partial recoveries in spite of the above. IE, redundancy is a good thing.
Say the part of the archive that is corrupt is a file that isn't needed. You
don't have to wast an entire PAR on that section. Just extract the other
files and ignore the corrupted one.
> It's ALREADY corrupt, so what makes you
> think the recovery data wouldn't be corrupt right along with it?!
Maybe because, if you'll read the above again, the recovery files are
separate, just like pars.
> Or am I just missing something painfully obvious here?
I'd say that's pretty much a certainty. Please, if you're going to start
blasting a piece of software on its technical merits at least do the
responsible thing and educate yourself of what it can and cannot do prior to
stepping up on your soapbox and inserting your foot into your mouth? Thanks.
I'm out of this discussion. I'm not going to edcuate you further on what I
know you're perfectly capable of looking up on your own.
Alex Malinovich
> Alex Malinovich wrote:
> > I don't know, maybe I'm just dense or something, but explain to me why
> > you would WANT to put that information in the archive itself?
>
> What, the checksums? Uh, so the reference is where you need it, with the
> archive. No need to go external. Also since the checksums are on a
> per-file-inside-the-archive basis you can see what files are corrupt and
> extract around that. Something tar, esp. split tars, is utterly incapable of.
> Trust me, I tried.
This is all assuming that the portion of the file that got corrupted
ISN'T the portion storing the checksum data. If it is, the file is of no
use to you.
> > If an archive is CORRUPTED (which is why we're distributing the sums and the
> > PARs in the first place), what good will it be that the sums and
> > recovery info are IN the file?
>
> Partial recoveries in spite of the above. IE, redundancy is a good thing.
> Say the part of the archive that is corrupt is a file that isn't needed. You
> don't have to wast an entire PAR on that section. Just extract the other
> files and ignore the corrupted one.
I seem to recall someone saying something about being responsible and
educating one's self on a piece of software? You don't "use up" a PAR.
It's not a bandage, or a tissue. It's perfectly possible to restore more
than one file with one PAR. (Depending on the total number of parts in
the archive set and the total number of PAR's included.)
--snip--
> I'd say that's pretty much a certainty. Please, if you're going to start
> blasting a piece of software on its technical merits at least do the
> responsible thing and educate yourself of what it can and cannot do prior to
> stepping up on your soapbox and inserting your foot into your mouth? Thanks.
I don't believe I ever began "blasting" a piece of software. What I did
was refute YOUR assertion that RAR is superior to a combination of free
software tools that performs a nearly-identical function. If you want to
use a non-free archiving utility, you are quite welcome to do so. Just
don't state AS FACT your OPINION that an equivalent result cannot be
obtained using different tools.
I'm very familiar with the RAR program and its evolution over the last
10+ years, including the new features that 3.0 introduced. My question,
as before, remains what practical benefit this software presents that
CANNOT be achieved otherwise?
Mike McCarty
> On Mon, 2005-12-12 at 18:51 -0800, Steve Lamb wrote:
>
>>Alex Malinovich wrote:
>
> --snip--
I've refrained from joining in, so far, but I just can't
resist :-)
>
>>>I don't know, maybe I'm just dense or something, but explain to me why
>>>you would WANT to put that information in the archive itself?
>>
>> What, the checksums? Uh, so the reference is where you need it, with the
>>archive. No need to go external. Also since the checksums are on a
>>per-file-inside-the-archive basis you can see what files are corrupt and
>>extract around that. Something tar, esp. split tars, is utterly incapable of.
>> Trust me, I tried.
>
>
> This is all assuming that the portion of the file that got corrupted
> ISN'T the portion storing the checksum data. If it is, the file is of no
> use to you.
This is not quite true. Usually, with a disc file or a file transmitted
over a link of some sort, a block of bytes gets corrupted, usually with
a size on the order of 1KB. If an archive is much larger than 1KB (the
usual case, in my experience) then most of the archive may actuallly
be usable. If each file contained in the archive has a separate
redundancy check, then one may be able (in my experience, usually can)
do a partial recovery, and extract some of the information. In one case,
I had backups which got corrupted (due to a virus overwriting sectors
on floppy discs). I had the same file corrupted in different places,
and was able to recover the entire archive (it was a PKZIPped archive)
by doing partial recovery on two different backups of the same archive.
>>>If an archive is CORRUPTED (which is why we're distributing the sums and the
>>>PARs in the first place), what good will it be that the sums and
>>>recovery info are IN the file?
Why do you suppose we put cyclic redundancy checks into messages
used in various protocols, like FTP, TCP, IP, MTP, etc? By your
reasoning, ISTM, you would view such cyclic redundancy checks to
be invalid. They should be sent via a separate message. But then
what checks the separate messages? Or in your case, what checks
the separate files? How do you know your separate files containing
the redundancy checks aren't corrupt? Do you have another set of
files checking the check files? And what checks the check check files?
To put it another way, are you aware that hard discs have redundancy
in them to allow one to recover corrupted sectors? By your reasoning,
this could not be put on the same disc, it would have to be on
another disc.
>> Partial recoveries in spite of the above. IE, redundancy is a good thing.
>> Say the part of the archive that is corrupt is a file that isn't needed. You
>>don't have to wast an entire PAR on that section. Just extract the other
>>files and ignore the corrupted one.
[snip]
> I'm very familiar with the RAR program and its evolution over the last
> 10+ years, including the new features that 3.0 introduced. My question,
> as before, remains what practical benefit this software presents that
> CANNOT be achieved otherwise?
I can think of two practical benefits which RAR provides, and
which no other software can provide:
(1) the ability to open and extract files from previously created RAR
format archives, and (2) the exchange of files with people who as a
customary practice use that format for archiving and compression
and prefer to send and receive them in that format.
I can't control my neighbor's dog, let alone my neighbor. If
someone I am doing a contract for requests RAR format, then
that's what he'll get, and I won't argue. I consider putting
food on my table a very practical thing.
Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!
Alex Malinovich
--snip--
> This is not quite true. Usually, with a disc file or a file transmitted
> over a link of some sort, a block of bytes gets corrupted, usually with
> a size on the order of 1KB. If an archive is much larger than 1KB (the
> usual case, in my experience) then most of the archive may actuallly
> be usable. If each file contained in the archive has a separate
> redundancy check, then one may be able (in my experience, usually can)
> do a partial recovery, and extract some of the information. In one case,
> I had backups which got corrupted (due to a virus overwriting sectors
> on floppy discs). I had the same file corrupted in different places,
> and was able to recover the entire archive (it was a PKZIPped archive)
> by doing partial recovery on two different backups of the same archive.
This is a good point. But this is also not a feature specific to RAR, as
you point out. Zip archives, among others, can do this as well.
--snip--
> Why do you suppose we put cyclic redundancy checks into messages
> used in various protocols, like FTP, TCP, IP, MTP, etc? By your
> reasoning, ISTM, you would view such cyclic redundancy checks to
> be invalid. They should be sent via a separate message. But then
> what checks the separate messages? Or in your case, what checks
> the separate files? How do you know your separate files containing
> the redundancy checks aren't corrupt? Do you have another set of
> files checking the check files? And what checks the check check files?
>
> To put it another way, are you aware that hard discs have redundancy
> in them to allow one to recover corrupted sectors? By your reasoning,
> this could not be put on the same disc, it would have to be on
> another disc.
Yes, but CRC checks on packets of data (a few kilobytes at a time) are
much different than a checksum on a 10, 20, or 50 MB archive,
particularly when speaking in terms of a lower-bandwidth connection.
It's easy enough to resend a TCP/IP packet if the CRC check fails.
However, we want to AVOID resending a 50 MB file if the checksum doesn't
agree with the file. It's much easier to re-download a 1K checksum file
than a 50 MB archive.
WRT to your statement about hard drives, I believe the feature you're
referring to is the ability to ignore bad sectors, not recover data from
them. If the drive determines a particular sector to be bad, it will
mark it as being bad and write the data elsewhere. If the data has
already been written to a sector, and that sector subsequently goes bad
I'm not aware of any low-level features to allow the recovery of that
sector after the fact.
--snip--
> (1) the ability to open and extract files from previously created RAR
> format archives, and (2) the exchange of files with people who as a
> customary practice use that format for archiving and compression
> and prefer to send and receive them in that format.
(1) unrar-free would do this as well
(2) see below
> I can't control my neighbor's dog, let alone my neighbor. If
> someone I am doing a contract for requests RAR format, then
> that's what he'll get, and I won't argue. I consider putting
> food on my table a very practical thing.
I completely agree. I'm not fortunate enough to be able to make a living
evangelizing free software either. (I work at a 99% MS shop. Used to be
100% until I got there, so I'm making inroads. :) )
However, the original question referred to how to archive a large amount
of data and split it into pieces for transferring to someone else. If
someone REQUESTS RAR specifically, and I have a business relationship
with them, I'll certainly oblige. However, if the format is unspecified,
as in this case it was, I would certainly choose to use free software to
do the job.
Steve Lamb
> This is all assuming that the portion of the file that got corrupted
> ISN'T the portion storing the checksum data. If it is, the file is of no
> use to you.
*sigh* As you said, it doesn't matter what is corrupt if there is
corruption. But this is a far sight better than nothing at all.
> I seem to recall someone saying something about being responsible and
> educating one's self on a piece of software?
Yes, Alex, and you're showing your ignorance again.
> You don't "use up" a PAR.
> It's not a bandage, or a tissue. It's perfectly possible to restore more
> than one file with one PAR. (Depending on the total number of parts in
> the archive set and the total number of PAR's included.)
No, it's not. PAR (v1) had a fixed size and was used to recreate 1 file
*per PAR*. That file was generally an archive though it was possible to have
PAR applied against several files of varying sizes. The size of the PAR file
was set to the largest file in the set but the rule applied. 1 PAR file for
each file corrupt.
PAR (v2) changed this so that one had a number of blocks one could use to
recover corrupted portions of a file. So it was possible to use only a small
portion of a PAR file to recover only a small portion of a corrupted file. Of
course this did not change the underlying rule; they just changed the
measurement. Instead of 1 PAR file to recover 1 protected file they now
narrowed it down to 1 PAR block to recovered 1 proteted block.
You cannot, as you assert above, take a single PAR file and recover, say,
3 files from a set.
BTW, Alex, little background footnote. For a while I was pushing to
package par2 for Debian. I just wasn't pleased with the method of getting the
package into the distribution. So, unlike you and RAR, I know quite well what
PAR 1 & 2 can and cannot do.
> I don't believe I ever began "blasting" a piece of software. What I did
> was refute YOUR assertion that RAR is superior to a combination of free
> software tools that performs a nearly-identical function.
By claiming that the piece of software in question was incapable of doing
things it most certainly is capable of doing. IE, blasting.
> If you want to
> use a non-free archiving utility, you are quite welcome to do so. Just
> don't state AS FACT your OPINION that an equivalent result cannot be
> obtained using different tools.
I'm not stating my opinion. I'm stating fact. The fact is that tar + gz
does not = rar. There are structures within the rar archive which are missing
from tar + gz. Futhermore tar + gz + split does not even remotely begin to
approach a multi-volume rar. If you don't believe me, read the following and
try... *try* to understand... My comments prefaced with "---"
--- I've created a multivolume rar set of some pictures. The file,
Lflying.jpg exists in one and only one volume. I do an md5sum of the original
file for comparison.
{grey@mania:~/t/t} md5sum ../Lflying.jpg
050f14ee2bacf23aa571a81c336ba4e5 ../Lflying.jpg
--- Delete all other volumes but the one that it exists in.
{grey@mania:~/t/t} rm test.part[12356].rar
--- List the volume to show you the file is there. This is the first thing a
split tar.gz cannot do.
{grey@mania:~/t/t} rar l test.part4.rar
RAR 3.30 Copyright (c) 1993-2004 Eugene Roshal 22 Jan 2004
Shareware version Type RAR -? for help
Volume test.part4.rar
Name Size Packed Ratio Date Time Attr CRC Meth Ver
-------------------------------------------------------------------------------
Ascendance_tabard.png 145615 18247 <-- 20-09-05 23:50 -rw-r--r--
E9E546BC m3c 2.9
Lflying.jpg 49115 48521 98% 15-04-05 23:29 -rwxr--r-- C0111A15 m3c 2.9
rava_face.png 162619 14973 --> 15-04-05 23:29 -rwxr--r-- 3301E1E0 m3c
2.9-------------------------------------------------------------------------------
2 211734 81741 38%
--- Note the CRC right there in the volume. Gee, no need for my external
md5sum except for this exercise. Now to extract the file.
{grey@mania:~/t/t} rar x test.part4.rar Lflying.jpg
RAR 3.30 Copyright (c) 1993-2004 Eugene Roshal 22 Jan 2004
Shareware version Type RAR -? for help
Extracting from test.part4.rar
Extracting Lflying.jpg OK
All OK
--- md5sum again to prove this file is the same as the above file.
{grey@mania:~/t/t} md5sum Lflying.jpg
050f14ee2bacf23aa571a81c336ba4e5 Lflying.jpg
--- And for comparison, here's the previons md5sum
050f14ee2bacf23aa571a81c336ba4e5 ../Lflying.jpg
So, you show me tar.gz being able to extract a file from the middle of a
split archive when none of the other volumes *even exist* and you'll have one
leg to stand on about what is my opinion vs. what is *fact*.
For your edification...
{grey@mania:~/t/t} split -b 80k test.tgz
{grey@mania:~/t/t} ls -l
total 1705
-rw-r--r-- 1 grey grey 868500 2005-12-12 22:46 test.tgz
-rw-r--r-- 1 grey grey 81920 2005-12-12 22:46 xaa
-rw-r--r-- 1 grey grey 81920 2005-12-12 22:46 xab
-rw-r--r-- 1 grey grey 81920 2005-12-12 22:46 xac
-rw-r--r-- 1 grey grey 81920 2005-12-12 22:46 xad
-rw-r--r-- 1 grey grey 81920 2005-12-12 22:46 xae
-rw-r--r-- 1 grey grey 81920 2005-12-12 22:46 xaf
-rw-r--r-- 1 grey grey 81920 2005-12-12 22:46 xag
-rw-r--r-- 1 grey grey 81920 2005-12-12 22:46 xah
-rw-r--r-- 1 grey grey 81920 2005-12-12 22:46 xai
-rw-r--r-- 1 grey grey 81920 2005-12-12 22:46 xaj
-rw-r--r-- 1 grey grey 49300 2005-12-12 22:46 xak
{grey@mania:~/t/t} rm test.tgz
{grey@mania:~/t/t} rm xa[abcdefijk]
{grey@mania:~/t/t} tar xzf xag
gzip: stdin: not in gzip format
tar: Child returned status 1
tar: Error exit delayed from previous errors
I rest my case on your opinion versus my facts.
> I'm very familiar with the RAR program and its evolution over the last
> 10+ years, including the new features that 3.0 introduced.
And you expect me to believe that when you didn't even know about the
recovery volumes introduced in 3.0? Please.
> My question,
> as before, remains what practical benefit this software presents that
> CANNOT be achieved otherwise?
See above. Tired of educating you Alex. Really tired.
Steve Lamb
> This is a good point. But this is also not a feature specific to RAR, as
> you point out. Zip archives, among others, can do this as well.
But you weren't talking zip. 'sides, not that zip is any freer than RAR,
at least not to my knowledge. Feel free to point out if I am wrong.
> Yes, but CRC checks on packets of data (a few kilobytes at a time) are
> much different than a checksum on a 10, 20, or 50 MB archive,
But the checksums we're referring to are on a per file basis inside the
archive itself; not on the entire archive. *Your* checksum with md5sum is
applied against the entire archive or, at smallest, a volume of the archive.
>>(1) the ability to open and extract files from previously created RAR
>>format archives
> (1) unrar-free would do this as well
No. As mentioned in this conversation unrar-free does not work on rar
archives made with rar >= 3.0.
> However, the original question referred to how to archive a large amount
> of data and split it into pieces for transferring to someone else.
Actually the original question was what free alternatives *for RAR* there
were. Check the archives, Alex.
Alex Malinovich
--snip--
> Yes, Alex, and you're showing your ignorance again.
Steve, I would appreciate it if you would refrain from referring to me
explicitly by name. Establishing a false sense of familiarity,
particularly in a discussion which is showing dangerous signs of being
heated, is not an exercise that I would like to participate in.
My discussions with you are about RAR, tar, and friends, not about you,
me, or any other personal matter.
--snip--
> from tar + gz. Futhermore tar + gz + split does not even remotely begin to
> approach a multi-volume rar. If you don't believe me, read the following and
> try... *try* to understand... My comments prefaced with "---"
Ok, I'll try, and I'll include my alternative, using nothing more than
tar, gz, and split (and md5sum as you did).
> --- I've created a multivolume rar set of some pictures. The file,
> Lflying.jpg exists in one and only one volume. I do an md5sum of the original
> file for comparison.
>
> {grey@mania:~/t/t} md5sum ../Lflying.jpg
> 050f14ee2bacf23aa571a81c336ba4e5 ../Lflying.jpg
Ok. Same scenario, only using tar, split, and gzip.
demonbane@Thief:~/gzip-proof$ md5sum Image08.png
324b47a61576cab05f12199457e953c3 Image08.png
> --- Delete all other volumes but the one that it exists in.
>
> {grey@mania:~/t/t} rm test.part[12356].rar
demonbane@Thief:~/gzip-proof$ rm xa[ac-z].gz *.png
(I didn't use a separate directory, so deleting the original images here
as well.)
> --- List the volume to show you the file is there. This is the first thing a
> split tar.gz cannot do.
>
> {grey@mania:~/t/t} rar l test.part4.rar
>
> RAR 3.30 Copyright (c) 1993-2004 Eugene Roshal 22 Jan 2004
> Shareware version Type RAR -? for help
>
> Volume test.part4.rar
>
> Name Size Packed Ratio Date Time Attr CRC Meth Ver
> -------------------------------------------------------------------------------
> Ascendance_tabard.png 145615 18247 <-- 20-09-05 23:50 -rw-r--r--
> E9E546BC m3c 2.9
> Lflying.jpg 49115 48521 98% 15-04-05 23:29 -rwxr--r-- C0111A15 m3c 2.9
> rava_face.png 162619 14973 --> 15-04-05 23:29 -rwxr--r-- 3301E1E0 m3c
> 2.9-------------------------------------------------------------------------------
> 2 211734 81741 38%
The output isn't quite as pretty as yours, but functionally essentially
the same.
demonbane@Thief:~/gzip-proof$ tar tvzf xab.gz
tar: This does not look like a tar archive
tar: Skipping to next header
-rw-r--r-- demonbane/demonbane 1005923 2005-12-13 00:14:55 Image08.png
-rw-r--r-- demonbane/demonbane 1164730 2005-12-13 00:14:55 Image12.png
tar: Unexpected EOF in archive
tar: Error is not recoverable: exiting now
> --- Note the CRC right there in the volume. Gee, no need for my external
> md5sum except for this exercise. Now to extract the file.
--- unless the part of the archive that gets corrupted is the CRC, with
the rest of the data intact
> {grey@mania:~/t/t} rar x test.part4.rar Lflying.jpg
>
> RAR 3.30 Copyright (c) 1993-2004 Eugene Roshal 22 Jan 2004
> Shareware version Type RAR -? for help
>
>
> Extracting from test.part4.rar
>
> Extracting Lflying.jpg OK
> All OK
Ok, still following you here.
demonbane@Thief:~/gzip-proof$ tar xvvzf xab.gz
tar: This does not look like a tar archive
tar: Skipping to next header
-rw-r--r-- demonbane/demonbane 1005923 2005-12-13 00:14:55 Image08.png
-rw-r--r-- demonbane/demonbane 1164730 2005-12-13 00:14:55 Image12.png
tar: Unexpected EOF in archive
tar: Unexpected EOF in archive
tar: Error is not recoverable: exiting now
I don't get the pretty "All OK" message... darn. :(
> --- md5sum again to prove this file is the same as the above file.
>
> {grey@mania:~/t/t} md5sum Lflying.jpg
> 050f14ee2bacf23aa571a81c336ba4e5 Lflying.jpg
demonbane@Thief:~/gzip-proof$ md5sum Image08.png
324b47a61576cab05f12199457e953c3 Image08.png
> --- And for comparison, here's the previons md5sum
>
> 050f14ee2bacf23aa571a81c336ba4e5 ../Lflying.jpg
And for comparison, my previous md5sum. Your point being?
324b47a61576cab05f12199457e953c3 Image08.png
In the interests of full disclosure, this was not done in exactly the
manner that you would normally create a tar.gz. The tarring, and the
gzipping were done in reverse order. A quick command-line run-down of
the process:
tar cf - *.png | split -b 1m
for i in xa*; do gzip $i; done
rm *.png xa[ac-z].gz
tar xzf xab.gz
> So, you show me tar.gz being able to extract a file from the middle of a
> split archive when none of the other volumes *even exist* and you'll have one
> leg to stand on about what is my opinion vs. what is *fact*.
So what exactly do I have to do to get the other leg then? :)
--snip--
> I rest my case on your opinion versus my facts.
As do I.
> > My question,
> > as before, remains what practical benefit this software presents that
> > CANNOT be achieved otherwise?
>
> See above. Tired of educating you Alex. Really tired.
I am feeling pretty tired myself. But, then, it's past midnight, local
time. :)
As a side note, I'm all for continuing this discussion in a civil manner
(if there is anything left to discuss that is), but I don't feel that
it's appropriate for either of us to make personal assaults against the
other in the course of said discussion.
If I have done that in any of my previous statements in this message, or
any other one, I do apologize. So shall we move on?
My question still stands; what practical benefit does the proprietary
RAR solution present that CANNOT be achieved by using the free tools of
tar, gz, and split?
Steve Lamb
> Steve, I would appreciate it if you would refrain from referring to me
> explicitly by name. Establishing a false sense of familiarity,
No familiarity at all. It's called getting your attention since it seems
to be wandering.
> tar cf - *.png | split -b 1m
> for i in xa*; do gzip $i; done
> rm *.png xa[ac-z].gz
> tar xzf xab.gz
*laugh* Thank you for proving my point. You had to go out of your way to
do what rar does normally. Furthermore this makes it rough for the other end
to do what is done since the now everything is completely mangled just to
prove a point. *snicker*
> So what exactly do I have to do to get the other leg then? :)
Get the first one up and running. The above only proves my point, nothing
more.
> My question still stands; what practical benefit does the proprietary
> RAR solution present that CANNOT be achieved by using the free tools of
> tar, gz, and split?
I've given examples. Go back and read until you understand.
Steve Lamb
> It is distributed with a BSD like license. IOW, you can redistribute,
> and source is available, but they retain rights. But no charge
> (unless you meant something different by the term "free").
Free of patent and royalty issues which ZIP is not entirely. :)
Mike McCarty
> On Mon, 2005-12-12 at 21:47 -0600, Mike McCarty wrote:
> --snip--
>
>>To put it another way, are you aware that hard discs have redundancy
>>in them to allow one to recover corrupted sectors? By your reasoning,
>>this could not be put on the same disc, it would have to be on
>>another disc.
>
>
> Yes, but CRC checks on packets of data (a few kilobytes at a time) are
> much different than a checksum on a 10, 20, or 50 MB archive,
> particularly when speaking in terms of a lower-bandwidth connection.
> It's easy enough to resend a TCP/IP packet if the CRC check fails.
> However, we want to AVOID resending a 50 MB file if the checksum doesn't
> agree with the file. It's much easier to re-download a 1K checksum file
> than a 50 MB archive.
>
> WRT to your statement about hard drives, I believe the feature you're
> referring to is the ability to ignore bad sectors, not recover data from
> them. If the drive determines a particular sector to be bad, it will
> mark it as being bad and write the data elsewhere. If the data has
> already been written to a sector, and that sector subsequently goes bad
> I'm not aware of any low-level features to allow the recovery of that
> sector after the fact.
Yes, there are FEC redundancy bits put into them, such that a sector
can be read and the data corrected even in the face of errors.
>
> --snip--
>
>>(1) the ability to open and extract files from previously created RAR
>>format archives, and (2) the exchange of files with people who as a
>>customary practice use that format for archiving and compression
>>and prefer to send and receive them in that format.
>
>
> (1) unrar-free would do this as well
> (2) see below
>
>
>>I can't control my neighbor's dog, let alone my neighbor. If
>>someone I am doing a contract for requests RAR format, then
>>that's what he'll get, and I won't argue. I consider putting
>>food on my table a very practical thing.
>
>
> I completely agree. I'm not fortunate enough to be able to make a living
> evangelizing free software either. (I work at a 99% MS shop. Used to be
> 100% until I got there, so I'm making inroads. :) )
>
> However, the original question referred to how to archive a large amount
> of data and split it into pieces for transferring to someone else. If
I answered your question as asked. I wasn't promoting RAR, I was
stating what RAR can do that nothing else can do. Personally, I've only
used it a few times, and didn't find it to be particularly better
or worse than other archival programs. Also, personally, I *dislike*
the *NIX world's most common technique of compressing entire
archives. This is the worst of all possible worlds, IMO. The way
ARJ, ZIP, etc. works is IMO far superior to the way "tar zf" works.
> someone REQUESTS RAR specifically, and I have a business relationship
> with them, I'll certainly oblige. However, if the format is unspecified,
> as in this case it was, I would certainly choose to use free software to
> do the job.
Glad to see that you retain your sanity, then. I recall a few
months ago when I needed to do some editing on my resume (don't
we all) in order to make a job app. I had a copy in Word
format, and so I wanted to edit it. But Open Office couldn't/
wouldn't save in Word format. The people I was making app to
had specifically requested Word format, so I asked for some help
on another mail echo. I got roundly lambasted by one guy who
wanted me to tell them how wrong they were to want Word format,
and said that so long as I "played their game" I was contributing
to Evil in the World.
Anyway, back to the topic.
If I needed to do that, and had complete freedom of choice in
how to do it, and were worried about getting corruption,
I'd do this...
For a Linux to Linux copy, I'd use tar or cpio to build a
single large archive. Then I'd split it. Then I'd compress
each of the pieces using gzip separately on the pieces,
and transmit them. I'd use the internal redundancy check
while decompressing to look for errors, and retransmit
the pieces which got corrupt. Then I'd concatenate the
pieces and use tar or cpio to recover the files.
Mike McCarty
> Alex Malinovich wrote:
>
>>This is a good point. But this is also not a feature specific to RAR, as
>>you point out. Zip archives, among others, can do this as well.
>
>
> But you weren't talking zip. 'sides, not that zip is any freer than RAR,
> at least not to my knowledge. Feel free to point out if I am wrong.
[snip]
Umm, I believe you do err. There is a free zip/unzip package.
http://linux.about.com/gi/dynamic/offsite.htm?site=http://www.info%2Dzip.org/pub/infozip/
It is distributed with a BSD like license. IOW, you can redistribute,
and source is available, but they retain rights. But no charge
(unless you meant something different by the term "free").
Mike
Seth Goodman
> Sent: Tuesday, December 13, 2005 11:49 AM
> To: debia...@lists.debian.org
> Subject: Re: RAR under linux: any alternative?
>
>
> Mike McCarty wrote:
> > It is distributed with a BSD like license. IOW, you can
> > redistribute, and source is available, but they retain
> > rights. But no charge (unless you meant something
> > different by the term "free").
>
> Free of patent and royalty issues which ZIP is not entirely. :)
I know this is a Debian list, but there is Windows tool called 7-zip
that is distributed under the LGPL that can deal with zip, tar, gz and
bz2. This makes me suspect that there cannot be any patent hindrances
to the zip format itself. This tool, like RAR, can create a split
archive with whatever size the user specifies. Zip files do have CRC's
for each file they contain that are made at the time of file
compression, and this is no different for RAR. Only the formats
supported are different. It also has support for rpm, deb and cab
files, and some support for decompressing RAR, but I haven't tried that.
Since my Windows and Debian boxes are connected through SAMBA, I have no
problem running the 7-zip tool on a Windows box and leaving the result
on a Debian machine. Yes, this is both impure and heretical and I
expect to be flamed all the way to the gates of hell for mentioning it.
Like Mike, I am a practical person and use whatever tool I need to get a
job done. While I prefer GPL'd tools for the same reason we all do,
sometimes you have to use a closed source tool to accomplish a task.
When a commercial software vendor recently asked me to provide him a
particular large file in RAR format with PAR files, I didn't argue or
attempt to "educate" him on the merits of GPL'd software, I just gave
him what he needed. Same goes for what my clients request. Zealotry is
bad for business.
--
Seth Goodman
Seth Goodman
> Sent: Wednesday, December 14, 2005 3:02 PM
>
>
> I know this is a Debian list, but there is Windows tool called 7-zip
There is a port of this tool in Debian unstable
http://packages.debian.org/unstable/utils/p7zip so hopefully this at
least provides another Debian-compatible method to read RAR's. The RAR
decompression is in a non-free area of the developer's web site and I
don't know what the license limitations are. They ported the command
line 7-zip version, not the GUI-based tool, so it is scriptable.
Mike McCarty
>>From: Steve Lamb [mailto:gr...@dmiyu.org]
>>Sent: Tuesday, December 13, 2005 11:49 AM
>>To: debia...@lists.debian.org
>>Subject: Re: RAR under linux: any alternative?
>>
>>
>>Mike McCarty wrote:
>>
>>>It is distributed with a BSD like license. IOW, you can
>>>redistribute, and source is available, but they retain
>>>rights. But no charge (unless you meant something
>>>different by the term "free").
>>
>> Free of patent and royalty issues which ZIP is not entirely. :)
>
>
> I know this is a Debian list, but there is Windows tool called 7-zip
> that is distributed under the LGPL that can deal with zip, tar, gz and
> bz2. This makes me suspect that there cannot be any patent hindrances
> to the zip format itself. This tool, like RAR, can create a split
> archive with whatever size the user specifies. Zip files do have CRC's
> for each file they contain that are made at the time of file
> compression, and this is no different for RAR. Only the formats
> supported are different. It also has support for rpm, deb and cab
> files, and some support for decompressing RAR, but I haven't tried that.
>
> Since my Windows and Debian boxes are connected through SAMBA, I have no
> problem running the 7-zip tool on a Windows box and leaving the result
The ZOO program is also some sort of free source. I've used it under
MSDOS, VMS, HPUX, and Solaris. I dunno if this is the same thing I've
used, but I found this:
http://packages.qa.debian.org/z/zoo.html
Anyway, here's a quote from the the full copyright notice for the
source I have...
[QUOTE MODE ON]
2. DISTRIBUTION IN UNMODIFIED FORM: You may copy this software in
unmodified form for any purpose, whether commercial or
noncommercial, provided that you make no attempt to restrict
distribution of it by others.
[QUOTE MODE OFF]
Anyone who wants a copy of the source I have may get it
by e-mailing me.
Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!
Steve Lamb
> I know this is a Debian list, but there is Windows tool called 7-zip
> that is distributed under the LGPL that can deal with zip, tar, gz and
> bz2. This makes me suspect that there cannot be any patent hindrances
> to the zip format itself.
IIRC one of the algorithms that can be used in zip is lzw which is (or
was) patented. Remember, just because something is under the (l)gpl does not
mean it is patent free. I could easily write an mp3 player and distribute it
under the gpl, doesn't change the fact that mp3 is patented.
> Since my Windows and Debian boxes are connected through SAMBA, I have no
> problem running the 7-zip tool on a Windows box and leaving the result
> on a Debian machine. Yes, this is both impure and heretical and I
> expect to be flamed all the way to the gates of hell for mentioning it.
Not from me. Use 7-zip here myself. Far prefer it to the alternatives on
Windows which are either useless or commercial (and about as useless).
Carl Fink
> IIRC one of the algorithms that can be used in zip is lzw which is (or
> was) patented.
The patent expired in 2003.
http://www.sslug.dk/patent/lzwunisys.html
--
Carl Fink ca...@fink.to
If you attempt to fix something that isn't broken, it will be.
-Bruce Tognazzini
Seth Goodman
> Sent: Wednesday, December 14, 2005 7:21 PM
>
>
> On Wed, Dec 14, 2005 at 02:34:31PM -0800, Steve Lamb wrote:
>
> > IIRC one of the algorithms that can be used in zip is
> > lzw which is (or was) patented.
>
> The patent expired in 2003.
>
> http://www.sslug.dk/patent/lzwunisys.html
In that case, it appears that using 7-zip to produce fixed-size, split
zip files followed by generating a set of PAR files would accomplish the
same thing as using RAR. That seems to answer Gabriel's question that
started the thread, yes? The zip files each contain CRC's, so you can
tell when one is bad and the PAR files allow you to repair defects. The
two approaches are both the same: a message authentication code (hash,
CRC or other MAC) to detect errors, followed by forward error correction
to repair detected errors. You decide how much FEC you get by how many
PAR files you generate. Same old - same old, except the compression and
FEC are better than older methods.
I also don't know if any other program besides 7-zip can put together
the split archives it produces, since 7-zip can't put together split
archives from WinZip. That's not much of an objection, since the
program is free and the code is open for others to build implementations
around.
I haven't bothered doing split 7z or tar archives, yet, but the 7z
archives are similar in size to RAR and have better MAC's. That makes
the main advantage of RAR only that the PAR file generation is
conveniently built-in. If a customer asks for RAR, I don't argue, so
the fact that some people like it is also an advantage.
--
Seth Goodman
Gabriel
On Wed, Dec 14, 2005 at 02:34:31PM -0800, Steve Lamb wrote:IIRC one of the algorithms that can be used in zip is lzw which is (or was) patented.The patent expired in 2003. http://www.sslug.dk/patent/lzwunisys.html
It's the same algorithm used on GIF.
Gabriel Parrondo
Gene Heskett
>Carl Fink wrote:
>>On Wed, Dec 14, 2005 at 02:34:31PM -0800, Steve Lamb wrote:
>>> IIRC one of the algorithms that can be used in zip is lzw which
>>> is (or was) patented.
>>
>>The patent expired in 2003.
>>
>> http://www.sslug.dk/patent/lzwunisys.html
>
>The license was owned by Unisys and IBM. The one expired in 2003 was
> the Unisys license. The IBM license expires on 08/11/2006 (in the
> USA). It's the same algorithm used on GIF.
'scuse me? If the unisys patent expired in 2003, then either the USTPO
screwed up again (what else is new?) in issueing the same patent to
IBM, or their 'license' is not in fact anything to do with a patent,
and should be absolutely moot now that the Unisys patent has expired,
all over the planet I believe. Any legal manuevering(sp) should be
entirely between IBM & Unisys. And likely a waste of time & shyster
fees.
If not, and IBM does have a legal claim on the lzw algorythm, please
cite some links so that we can become better educated.
--
Cheers, Gene
People having trouble with vz bouncing email to me should use this
address: <gene.h...@verizononline.net> which bypasses vz's
stupid bounce rules. I do use spamassassin too. :-)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
Gabriel
On Thursday 15 December 2005 19:29, Gabriel wrote:Carl Fink wrote:On Wed, Dec 14, 2005 at 02:34:31PM -0800, Steve Lamb wrote:IIRC one of the algorithms that can be used in zip is lzw which is (or was) patented.The patent expired in 2003. http://www.sslug.dk/patent/lzwunisys.htmlThe license was owned by Unisys and IBM. The one expired in 2003 was the Unisys license. The IBM license expires on 08/11/2006 (in the USA). It's the same algorithm used on GIF.'scuse me? If the unisys patent expired in 2003, then either the USTPO screwed up again (what else is new?) in issueing the same patent to IBM, or their 'license' is not in fact anything to do with a patent, and should be absolutely moot now that the Unisys patent has expired, all over the planet I believe. Any legal manuevering(sp) should be entirely between IBM & Unisys. And likely a waste of time & shyster fees. If not, and IBM does have a legal claim on the lzw algorythm, please cite some links so that we can become better educated.
Check it out:
http://www.gnu.org/philosophy/gif.html
Gabriel Parrondo
Gene Heskett
I see, and many thanks for the link. The one thing it doesn't explain
however, is why the USTPO allowed 2 different entities to patent the
lzw algorythm. That is still a puzzlement to me, but what do I know.
Mike McCarty
>>http://www.gnu.org/philosophy/gif.html
>
>
> I see, and many thanks for the link. The one thing it doesn't explain
> however, is why the USTPO allowed 2 different entities to patent the
> lzw algorythm. That is still a puzzlement to me, but what do I know.
Umm, I haven't read them, nor am I a lawyer. However, I took a short
course in "Intellectual Property Law" a few years ago, and learned a
little something, and this is my understanding.
One does not patent algorithms, whatever you may have read or
heard. Patents are issued for exactly two things: processes and
devices. Now these terms are pretty broadly interpreted. For
example, a mouse with a particular set of genes may be a device.
So, the mathematical algorithm, in the sense of means of computation
of a given result, is not patentable. What is patentable is the
application of a given algorithm to create a process. For example,
the computations involved in computing the LZW compression of any
given stream is not patentable. But the application of that
computation to the compression of a video image *is* patentable.
So the same algorithm, if it is applied in different ways, may
result in more than one patentable process.
So this may be an answer to your question.
Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!
Gabriel
Even if Unisys really did give permission for free software to generate GIFs, we would still have to deal with the IBM patent. Both the IBM and the Unisys patents cover the same "invention"--the LZW compression algorithm. (This could reflect an error on the part of the US Patent and Trademark Office, which is famous for incompetence and poor judgment.)
about the middle of the page. :-P
-- Cheers -- Gabriel Parrondo Linux User #404138 "In theory there's no difference between the theory and the practice. In the practice There is."
Gene Heskett
>Gene Heskett wrote:
>>>http://www.gnu.org/philosophy/gif.html
>>
>> I see, and many thanks for the link. The one thing it doesn't
>> explain however, is why the USTPO allowed 2 different entities to
>> patent the lzw algorythm. That is still a puzzlement to me, but
>> what do I know.
>
>Umm, I haven't read them, nor am I a lawyer. However, I took a short
>course in "Intellectual Property Law" a few years ago, and learned a
>little something, and this is my understanding.
>
>One does not patent algorithms, whatever you may have read or
>heard. Patents are issued for exactly two things: processes and
>devices. Now these terms are pretty broadly interpreted. For
>example, a mouse with a particular set of genes may be a device.
>
>So, the mathematical algorithm, in the sense of means of computation
>of a given result, is not patentable. What is patentable is the
>application of a given algorithm to create a process. For example,
>the computations involved in computing the LZW compression of any
>given stream is not patentable. But the application of that
>computation to the compression of a video image *is* patentable.
>So the same algorithm, if it is applied in different ways, may
>result in more than one patentable process.
>
>So this may be an answer to your question.
>
>Mike
Interesting, Mike and thanks, another example of why we need to
overhaul the USTPO. Its busted. But then WE knew that already.
--
Cheers, Gene
People having trouble with vz bouncing email to me should use this
address: <gene.h...@verizononline.net> which bypasses vz's
stupid bounce rules. I do use spamassassin too. :-)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
hen...@topoi.pooq.com
> Carl Fink wrote:
>
> >On Wed, Dec 14, 2005 at 02:34:31PM -0800, Steve Lamb wrote:
> >
> >
> >
> >> IIRC one of the algorithms that can be used in zip is lzw which is (or
> >>was) patented.
> >>
> >>
> >
> >The patent expired in 2003.
> >
> > http://www.sslug.dk/patent/lzwunisys.html
> >
> >
> The license was owned by Unisys and IBM. The one expired in 2003 was the
> Unisys license. The IBM license expires on 08/11/2006 (in the USA).
> It's the same algorithm used on GIF.
Id does suggest that if IBM were to try to enforce their patent, you
could claim the Unisys patent as prior art in your defence. This might
possibly be enough for IBM's lawyers to back off. After all, what's
the point of fighting a probably losing case when the whole thing's
going to expire far sooner than the kawsuit would be settled anyway?
But then, why bother provoking them when the wole thing's going to
expire so soon anyway? Might as well use PNG.
-- hendrik
>
> --
>
>
> ------------------------------------------------------------------------
>
> *Gabriel Parrondo*
John Hasler
> I see, and many thanks for the link. The one thing it doesn't explain
> however, is why the USTPO allowed 2 different entities to patent the lzw
> algorythm. That is still a puzzlement to me, but what do I know.
One does not patent an algorithm. One patents an invention that utilizes
the algorithm. I don't find it puzzling that Unisys and IBM came up with
two different inventions that use the LZW algorithm. It is possible that
the two patents interfere, but obviously neither patent owner has seen fit
to do anything about it if they do.
Unless you have evidence that IBM's patent applies to something we
distribute and that there is reason to believe that they are likely to
enforce it against us or our users, I see no reason to be concerned. I
have no doubt that Debian contains hundreds of potential infringements of
IBM patents.
--
John Hasler
Seth Goodman
> Sent: Friday, December 16, 2005 11:58 AM
<...>
> I have no doubt that Debian contains hundreds of potential
> infringements of IBM patents.
That wouldn't surprise me. If someone violates your patent and you fail
to defend it in any meaningful way, you are considered to have
abandoned the patent and it becomes effectively void. Defending it can
be as simple as sending an infringing party a letter demanding that they
cease and desist from infringing on the patent.
IANAL, but have some familiarity with the process because I have a
number of patents. From the practical viewpoint, the fact that someone
has legally abandoned their patent and would not prevail in court does
not stop them from suing anyone. Patent suits are _extremely_
expensive, and unless you have very deep pockets, most organizations are
compelled to settle even if there is no legal basis for the suit. Even
if they _do_ have the resources to see it through and win, many
companies will make a business decision to settle a patent suit that
does not impact them in some horribly way on the advice of their
lawyers.
My non-lawyer understanding is that for all intents and purposes, if a
patent is widely ignored and the patent owner neither warns the
infringers nor initiates legal action against any of them, you are
pretty safe doing what everyone else is doing. If the infringement is
in "broad daylight", and not obscure and hidden, so much the better.
--
Seth Goodman
Carl Fink
> That wouldn't surprise me. If someone violates your patent and you fail
> to defend it in any meaningful way, you are considered to have
> abandoned the patent and it becomes effectively void. Defending it can
> be as simple as sending an infringing party a letter demanding that they
> cease and desist from infringing on the patent.
That's trademark. Patents are not invalidated by lack of defense.
See, for instance,
http://www.uspto.gov/web/offices/pac/mpep/documents/2100_2134.htm
My own understanding of this issue comes from Gary Shaw (Assistant Dean,
Touro Law School).
--
Carl Fink ca...@fink.to
If you attempt to fix something that isn't broken, it will be.
-Bruce Tognazzini
John Hasler
> If someone violates your patent and you fail to defend it in any
> meaningful way, you are considered to have abandoned the patent and it
> becomes effectively void.
This is not true. You are confounding patents and trademarks.
> My non-lawyer understanding is that for all intents and purposes, if a
> patent is widely ignored and the patent owner neither warns the
> infringers nor initiates legal action against any of them, you are pretty
> safe doing what everyone else is doing.
Said patent owner might not be awarded damages for past infringement but he
can still start enforcing his patent. He _might_ lose his patent if it can
be shown that he misused it, but I don't think mere non-enforcement
qualifies.
--
John Hasler