---

Hej NG,

Jeg vil tage en kopi af en større mængde filer med zip - har brugt denne
kommande:
zip -r /root/backup/samba_rest.zip /samba/it /samba/production
/samba/regnskab /samba/salg

Dog for jeg denne fejl hvis jeg vil læse zip-filen:
[root@vulcano backup]# zip -l samba_rest.zip
zip warning: missing end signature--probably not a zip file (did you
zip warning: remember to use binary mode when you transferred it?)

Denne zip fil fylder 4.1GB. Jeg har ikke overført den til andre maskiner
så det er ikke overførslen som går galt. Jeg zipper andre filer og får
samme fejl. Alle zip filer er større end 4GB - måske det er problemet.

Jeg har også prøvet at reparere zip filen, men mister så det meste af
filen. Med zip -F og zip -FF.

Filsystemet er ext3.

Nogen bud på hvorfor det går galt ?

Hvilke andre måder kunne jeg gemme filerne på ? Fylder et iso-image ikke
mere? Jeg kunne godt tænke mig at evt. at overføre til dvd så filen skal
ikke fylde mere end 4.7GB.

/Jan

---

jma <jpeace73@hotmailFJERNTHIS.com> writes:

> Denne zip fil fylder 4.1GB. Jeg har ikke overført den til andre maskiner
> så det er ikke overførslen som går galt. Jeg zipper andre filer og får
> samme fejl. Alle zip filer er større end 4GB - måske det er problemet.

prøv med 'tar -z' istedet.

> Nogen bud på hvorfor det går galt ?

Nogle programmer har problemer med filer der er større end 4GB.

--
Peter Makholm | Vi smider blade allesammen - hele tiden
peter@makholm.net | som et konstant spirende efterår
http://hacking.dk | Og hele tiden vokser nye frugter frem
| og vi finder nogen til at plukke dem
| -- Tilt, Perkussive popler

---

On Wed, 03 May 2006 11:40:24 +0200, Peter Makholm wrote:

> jma <jpeace73@hotmailFJERNTHIS.com> writes:
>
>> Denne zip fil fylder 4.1GB. Jeg har ikke overført den til andre maskiner
>> så det er ikke overførslen som går galt. Jeg zipper andre filer og får
>> samme fejl. Alle zip filer er større end 4GB - måske det er problemet.
>
> prøv med 'tar -z' istedet.
>
>> Nogen bud på hvorfor det går galt ?
>
> Nogle programmer har problemer med filer der er større end 4GB.

Tak for svarene.
Jeg vil forsøge mig med tar i stedet. Ville dog helst bruge et
komprimeringsformat der kunne bruges i et windows miljø også.

Hilsen Jan

---

jma <jpeace73@hotmailFJERNTHIS.com> writes:

> Jeg vil forsøge mig med tar i stedet. Ville dog helst bruge et
> komprimeringsformat der kunne bruges i et windows miljø også.

GNU tar findes til Windows (og kan iøvrigt splitte i klumper ligesom
zip kan svjh). Winzip og Winrar har det fint med tar filer.
--
Thorbjørn Ravn Andersen

---

"jma" <jpeace73@hotmailFJERNTHIS.com> wrote in message
news:pan.2006.05.03.12.30.42.530494@hotmailFJERNTHIS.com...
> On Wed, 03 May 2006 11:40:24 +0200, Peter Makholm wrote:
>
>> jma <jpeace73@hotmailFJERNTHIS.com> writes:
>>
>>> Denne zip fil fylder 4.1GB. Jeg har ikke overført den til andre maskiner
>>> så det er ikke overførslen som går galt. Jeg zipper andre filer og får
>>> samme fejl. Alle zip filer er større end 4GB - måske det er problemet.
>>
>> prøv med 'tar -z' istedet.
>>
>>> Nogen bud på hvorfor det går galt ?
>>
>> Nogle programmer har problemer med filer der er større end 4GB.
>
> Tak for svarene.
> Jeg vil forsøge mig med tar i stedet. Ville dog helst bruge et
> komprimeringsformat der kunne bruges i et windows miljø også.

Er der ikke noget med at .zip filer kan deles i flere ?
Bemærk at http://www.7-zip.org/ til Windows kan håndtere de mest udbredte
formater (7z, ZIP, GZIP, BZIP2, TAR, RAR, CAB, ARJ, LZH, CHM, Z, CPIO, RPM,
DEB) og er i modsætning til WinZip og WinRAR gratis.

Niels Dybdahl

---

Jacob Gaarde <-dont@dev.null> writes:

> bzip2 forsøger altid lige hårdt på at komprimere, så "-[1-9]" påvirker
> ikke CPU-belastningen væsentligt, men kan derimod påvirke wall-tiden
> for at komprimere en given datamængde.

[...]

> nej, jeg talte som jeg har forsøgt at klargøre her i anden ombæring om
> hvorvidt bzip2 skifter algoritme eller ej

Det er korrekt at bzip2 ikke skifter algoritme med -1 og -9 men bare
den blokstørelse bzip2's algoritme arbejder med. Men dette har altså
indflydelse på hvor hårdt data bliver komprimeret.

Det fremgår også klart af afsnittet Memory Management der henvises til
under -1 og -9:

MEMORY MANAGEMENT
bzip2 compresses large files in blocks. The block size affects
both the compression ratio achieved, and the amount of memory
needed for compression and decompression.

[...]

In general, try and use the largest block size memory constraints
allow, since that maximises the compression achieved. Compression
and decompression speed are virtually unaffected by block size.

[...]

Here is a table which summarises the maximum memory usage for
different block sizes. Also recorded is the total compressed size
for 14 files of the Calgary Text Compression Corpus totalling
3,141,622 bytes. This column gives some feel for how compression
varies with block size. These figures tend to understate the
advantage of larger block sizes for larger files, since the Corpus
is dominated by smaller files.

Compress Decompress Decompress Corpus
Flag usage usage -s usage Size

-1 1200k 500k 350k 914704
-2 2000k 900k 600k 877703
-3 2800k 1300k 850k 860338
-4 3600k 1700k 1100k 846899
-5 4400k 2100k 1350k 845160
-6 5200k 2500k 1600k 838626
-7 6100k 2900k 1850k 834096
-8 6800k 3300k 2100k 828642
-9 7600k 3700k 2350k 828642

Det er en tydelig forskel på 10%. Og så påstås det endda at dette er
en undervurdering af forskellen i rigtige tilfælde.

--
Peter Makholm | I have no caps-lock but I must scream...
peter@makholm.net | -- Greg
http://hacking.dk |

---

jma wrote:
....
> Hvilke andre måder kunne jeg gemme filerne på ? Fylder et iso-image ikke
> mere? Jeg kunne godt tænke mig at evt. at overføre til dvd så filen skal
> ikke fylde mere end 4.7GB.

Du kan ikke brænde DVD'er i iso format som indeholder
filer større end 2GB. Så skal filen først splittes op.

Muligvis kan du lægge zip filen på DVD rå uden at gå via iso...

Mogens
--
Mogens Kjaer, Carlsberg A/S, Computer Department
Gamle Carlsberg Vej 10, DK-2500 Valby, Denmark
Phone: +45 33 27 53 25, Fax: +45 33 27 47 08
Email: mk@crc.dk Homepage: http://www.crc.dk

---

"jma" <jpeace73@hotmailFJERNTHIS.com> wrote in message
news:pan.2006.05.03.09.04.32.818831@hotmailFJERNTHIS.com...
> Hej NG,
>
> Jeg vil tage en kopi af en større mængde filer med zip - har brugt denne
> kommande:
> zip -r /root/backup/samba_rest.zip /samba/it /samba/production
> /samba/regnskab /samba/salg
>
> Dog for jeg denne fejl hvis jeg vil læse zip-filen:
> [root@vulcano backup]# zip -l samba_rest.zip
> zip warning: missing end signature--probably not a zip file (did
> you
> zip warning: remember to use binary mode when you transferred it?)
>
> Denne zip fil fylder 4.1GB. Jeg har ikke overført den til andre maskiner
> så det er ikke overførslen som går galt. Jeg zipper andre filer og får
> samme fejl. Alle zip filer er større end 4GB - måske det er problemet.

Jeg er ikke sikker på at ZIP-formatet understøtter mere end 4 GB...

Niels Dybdahl

---

"Niels Dybdahl" <niels@dybdahl.dk> writes:

> Jeg er ikke sikker på at ZIP-formatet understøtter mere end 4 GB...

"tar" måske i stedet? Evt GNU tar.

--
Thorbjørn Ravn Andersen

---

On Wed, 3 May 2006 12:48:17 +0200, "Niels Dybdahl" <niels@dybdahl.dk>
wrote:


>Jeg er ikke sikker på at ZIP-formatet understøtter mere end 4 GB...

Faktisk er grænsen for formatet 2 GB - en ZIP fil må max komprimteret
fylde 2 GB, og den kan ikke indeholder filer der - ukomprimeret -
fylder mere end 2 GB.

Det er ihvertfald grænserne i den implemtering der er i Total
Commander. Vi rammer dem indimellem når vi arbejder med SQL Database
dumps der skal hentes hjem (> 5 GB). Så enten brug tar/gzip, zip i
mindre portioner eller split filerne.


Med venlig hilsen
Nicolai

--
http://nicolai.hjorth.com

---

Nicolai Lang <nnews0403051902@hjorth.com> writes:

> Det er ihvertfald grænserne i den implemtering der er i Total
> Commander. Vi rammer dem indimellem når vi arbejder med SQL Database
> dumps der skal hentes hjem (> 5 GB). Så enten brug tar/gzip, zip i
> mindre portioner eller split filerne.

GNU tar har også -M som kan splitte filerne. Jeg har brugt det for så
længe siden at jeg vil henvise til Google til brugen af sammen, men
det virkede den gang.

Har man kontrol over begge ender, og ændringerne fra gang til gang er
forholdsvis små, er rsync fin. Dette inkluderer også hvis det fx er
zipfiler med lettere varierende indhold - jarfiler fx.
--
Thorbjørn Ravn Andersen

---

jma <jpeace73@hotmailFJERNTHIS.com> hit the keyboard.
Afterwards the following was on the screen:

> On Wed, 03 May 2006 11:40:24 +0200, Peter Makholm wrote:
>
>> jma <jpeace73@hotmailFJERNTHIS.com> writes:
>>
>>> Denne zip fil fylder 4.1GB. Jeg har ikke overført den til andre maskiner
>>> så det er ikke overførslen som går galt. Jeg zipper andre filer og får
>>> samme fejl. Alle zip filer er større end 4GB - måske det er problemet.
>>
>> prøv med 'tar -z' istedet.
>>
>>> Nogen bud på hvorfor det går galt ?
>>
>> Nogle programmer har problemer med filer der er større end 4GB.
>
> Tak for svarene.
> Jeg vil forsøge mig med tar i stedet. Ville dog helst bruge et
> komprimeringsformat der kunne bruges i et windows miljø også.

Tar findes skam også til Windows. Winzip kan f. eks. også læse tar og
gzip (jeg husker ikke om den kan læse bzip2).

--
-- [ Rasmus "Møffe" Bøg Hansen ] ---------------------------------------
I'm gonna wear some fake disguise.
-- Mick Jagger
----------------------------------------------[ moffe at zz9 dot dk ] --

---

On Wed, 03 May 2006 14:48:40 +0200, Rasmus Bøg Hansen wrote:

>>> prøv med 'tar -z' istedet.
>>>
>>>> Nogen bud på hvorfor det går galt ?
>>>
>>> Nogle programmer har problemer med filer der er større end 4GB.
>>
>> Tak for svarene.
>> Jeg vil forsøge mig med tar i stedet. Ville dog helst bruge et
>> komprimeringsformat der kunne bruges i et windows miljø også.
>
> Tar findes skam også til Windows. Winzip kan f. eks. også læse tar og
> gzip (jeg husker ikke om den kan læse bzip2).

ok - fint

Det ser dog desværre ud til at tar -czvf file.tar /somedir ikke pakker så
meget som zip. I hvert fald får jeg en noget større fil på noget færre
data!

---

jma <jpeace73@hotmailFJERNTHIS.com> writes:

>Det ser dog desværre ud til at tar -czvf file.tar /somedir ikke pakker så
>meget som zip. I hvert fald får jeg en noget større fil på noget færre
>data!

tar cvf - /somedir | bzip2 -9c > file.tar.bz2

9-tallet angiver maksimal kompression, men det tager naturligvis
tid. Skru eventuelt ned for tallet, hvis du bliver utålmodig.

En anden skribent har nævnt i hvert fald ét Windows-program, der
spiser bzip2.

Mvh.
   Klaus.

---

On Wed, 03 May 2006 14:11:48 +0000, Klaus Ellegaard wrote:

> jma <jpeace73@hotmailFJERNTHIS.com> writes:
>
>>Det ser dog desværre ud til at tar -czvf file.tar /somedir ikke pakker så
>>meget som zip. I hvert fald får jeg en noget større fil på noget færre
>>data!
>
> tar cvf - /somedir | bzip2 -9c > file.tar.bz2
>
> 9-tallet angiver maksimal kompression, men det tager naturligvis
> tid. Skru eventuelt ned for tallet, hvis du bliver utålmodig.
>
> En anden skribent har nævnt i hvert fald ét Windows-program, der
> spiser bzip2.

Tak for tippet. Jeg har ikke lige haft tid til at test, pga. det også er
så store filer at jeg ikke kan køre pakningen på alle tidspunkter. Men
laver en test først med fuld kompression, og så må jeg se hvor langt ned
jeg kan gå, inden størrelsen bliver for stor.
/Jan

---

On Wed, 10 May 2006 11:24:22 +0200
jma <jpeace73@hotmailFJERNTHIS.com> wrote:

> On Wed, 03 May 2006 14:11:48 +0000, Klaus Ellegaard wrote:
>
> > jma <jpeace73@hotmailFJERNTHIS.com> writes:
--SNIP--
> >
> > tar cvf - /somedir | bzip2 -9c > file.tar.bz2
> >
> > 9-tallet angiver maksimal kompression, men det tager naturligvis
> > tid. Skru eventuelt ned for tallet, hvis du bliver utålmodig.

bzip2 komprimerer _altid_ lige meget.
parammetren -[1-9] angiver hvor meget memorey, der skl bruges til at
udføre komprimeringen/dekomprimeringen, læs man-siden

-[0-9] til gzip derimod giver forskellig komprimering
læs man-siden

--SNIP--
> Men laver en test først med fuld kompression, og så må jeg se hvor
> langt ned jeg kan gå, inden størrelsen bliver for stor.

se ovenst.


--
//Jacob Gaarde
//Dont reply to my (aparent) e-mail address. Instead Use
//e-mail : gaarde <at> mailme <dot> dk

---

Jacob Gaarde <-dont@dev.null> writes:

>bzip2 komprimerer _altid_ lige meget.

Det er forkert.

> parammetren -[1-9] angiver hvor meget memorey, der skl bruges til at
>udføre komprimeringen/dekomprimeringen, læs man-siden

Lige præcis. Og blokstørrelsen har effekt på kompressionen i
de tilfælde, hvor der er en stor repetition inden for blokken.

$ dd if=/dev/zero of=test1 bs=32768 count=1024
1024+0 records in
1024+0 records out
$ dd if=/dev/zero of=test2 bs=32768 count=1024
1024+0 records in
1024+0 records out
$ bzip2 -1 test1
$ bzip2 -9 test2
$ ls -l test1.bz2 test2.bz2
-rw-r--r-- 1 klaus staff 231 May 10 16:35 test1.bz2
-rw-r--r-- 1 klaus staff 46 May 10 16:35 test2.bz2

I følge din påstand er 231=46?

Mvh.
   Klaus.

---

---

---

---

---

---

---

On Wed, 10 May 2006 14:38:08 +0000 (UTC)
Klaus Ellegaard <klausellegaard@msn.com> wrote:

> Jacob Gaarde <-dont@dev.null> writes:
>
> >bzip2 komprimerer _altid_ lige meget.
>
> Det er forkert.
>
> > parammetren -[1-9] angiver hvor meget memorey, der skl bruges til at
> >udf_re komprimeringen/dekomprimeringen, l_s man-siden
>
> Lige pr_cis. Og blokst_rrelsen har effekt p_ kompressionen i
> de tilf_lde, hvor der er en stor repetition inden for blokken.
godt, så , lad mig omformulere

bzip2 forsøger altid lige hårdt på at komprimere, så "-[1-9]" påvirker
ikke CPU-belastningen væsentligt, men kan derimod påvirke wall-tiden
for at komprimere en given datamængde.
dette til forskel fra gzip, der skifter
algoritme ved forksllige valg af [0-9], og dermed påvirker
run-time cpubelastning samt størrelse af output-fil.


--SNIP eksempler med null-files --

i de fleste, hvor jeg har brug for at komprimere, er det dog ikke filer
med ene nuller.


> I f_lge din p_stand er 231=46?
nej, jeg talte som jeg har forsøgt at klargøre her i anden ombæring om
hvorvidt bzip2 skifter algoritme eller ej



--
//Jacob Gaarde
//Dont reply to my (aparent) e-mail address. Instead Use
//e-mail : gaarde <at> mailme <dot> dk

---

On Wed, 10 May 2006 19:40:30 +0200, Jacob wrote:

> dette til forskel fra gzip, der skifter
> algoritme ved forksllige valg af [0-9],

Hvilke algoritmer skifter gzip i mellem?


Mvh.

--
"Mr. Lambada, rejser kun charter Adam Sjøgren
Sidder i baren og sælger falske anparter" asjo@koldfront.dk

---

On Wed, 10 May 2006 20:25:37 +0200
asjo@koldfront.dk (Adam Sjøgren) wrote:

> Hvilke algoritmer skifter gzip i mellem?
LZ77 og Huffman

--
//Jacob Gaarde
//Dont reply to my (aparent) e-mail address. Instead Use
//e-mail : gaarde <at> mailme <dot> dk

---

On Wed, 10 May 2006 20:45:48 +0200, Jacob wrote:

> On Wed, 10 May 2006 20:25:37 +0200
> asjo@koldfront.dk (Adam Sjøgren) wrote:

>> Hvilke algoritmer skifter gzip i mellem?

> LZ77 og Huffman

Hvor har du det fra?

I manualen står der:

" Gzip reduces the size of the named files using Lempel-Ziv coding
(LZ77). [...]

[...]

Gzip uses the Lempel-Ziv algorithm used in zip and PKZIP. The amount
of compression obtained depends on the size of the input and the dis-
tribution of common substrings. Typically, text such as source code or
English is reduced by 60-70%. Compression is generally much better
than that achieved by LZW (as used in compress), Huffman coding (as
used in pack), or adaptive Huffman coding (compact)."
- gzip(1)


Så vidt jeg kan se i deflate.c ændrer de ni niveauer "bare" på fire
parametre til samme mølle?


Mvh.

--
"Tabloidtidningen representerar för mig ytterligare Adam Sjøgren
ett område av tillvaron som har lidit asjo@koldfront.dk
snuttifieringsdöden."

---

On Wed, 10 May 2006 21:15:07 +0200
asjo@koldfront.dk (Adam Sjøgren) wrote:

> On Wed, 10 May 2006 20:45:48 +0200, Jacob wrote:
>
> > On Wed, 10 May 2006 20:25:37 +0200
> > asjo@koldfront.dk (Adam Sjøgren) wrote:
>
> >> Hvilke algoritmer skifter gzip i mellem?
>
> > LZ77 og Huffman
>
> Hvor har du det fra?
<http://www.gzip.org/>
"The format of the .gz files generated by gzip is described in RFCs
(Request For Comments) 1951 and 1952. "

<ftp://ftp.uu.net/graphics/png/documents/zlib/zdoc-index.html>
under rfc1951
"...hat compresses data using a combination of the LZ77 algorithm and
Huffman coding..."


>
> I manualen står der:
--SNIP--

> Så vidt jeg kan se i deflate.c ændrer de ni niveauer "bare" på fire
> parametre til samme mølle?

så detaljeret har jeg ikke gået til den.
jeg har bare konstateret , at i anvendelser á la

# cd /some/where ; tar -i -S --ignore-failed-raed --one-file-system -cf
- ./ gzip -1 | ssh -cblowfish -oCompression=off user@host
"cd /some/where/else ; tar -zxf -"

giver det ikke mening at bruge n større end 3, hvis der er tale om et
100Mbit (ellr bredere) netværk, og den "knækker" markant ved skiftet
fra 3 til 4



>
>
> Mvh.
>
> --
> "Tabloidtidningen representerar för mig ytterligare Adam
> Sjøgren ett område av tillvaron som har lidit
> asjo@koldfront.dk snuttifieringsdöden."


--
//Jacob Gaarde
//Dont reply to my (aparent) e-mail address. Instead Use
//e-mail : gaarde <at> mailme <dot> dk

---

On Wed, 10 May 2006 21:43:16 +0200, Jacob wrote:

> On Wed, 10 May 2006 21:15:07 +0200
> asjo@koldfront.dk (Adam Sjøgren) wrote:

>> Hvor har du det fra?

> <ftp://ftp.uu.net/graphics/png/documents/zlib/zdoc-index.html>
> under rfc1951
> "...hat compresses data using a combination of the LZ77 algorithm and
> Huffman coding..."

Der står at gzip bruger en kombination, ikke at den skifter alt efter
hvad options den får - ikke sandt?

>> Så vidt jeg kan se i deflate.c ændrer de ni niveauer "bare" på fire
>> parametre til samme mølle?

> så detaljeret har jeg ikke gået til den.
> jeg har bare konstateret , at i anvendelser á la

> # cd /some/where ; tar -i -S --ignore-failed-raed --one-file-system -cf
> - ./ gzip -1 | ssh -cblowfish -oCompression=off user@host
> "cd /some/where/else ; tar -zxf -"

> giver det ikke mening at bruge n større end 3, hvis der er tale om et
> 100Mbit (ellr bredere) netværk, og den "knækker" markant ved skiftet
> fra 3 til 4

Godt, så behøver jeg ikke at revidere min opfattelse af at gzip
implementerer en enkelt algoritme og at -1 til -9 alene ændrer på
parametrene til denne.


Mvh.

--
"Where hell waits behind every door Adam Sjøgren
With John Denver songs" asjo@koldfront.dk

---

On Wed, 10 May 2006 21:51:51 +0200
asjo@koldfront.dk (Adam Sjøgren) wrote:

-SNIP--
> > <ftp://ftp.uu.net/graphics/png/documents/zlib/zdoc-index.html>
> > under rfc1951
--SNIP--
> Der står at gzip bruger en kombination, ikke at den skifter alt efter
> hvad options den får - ikke sandt?
tjoh

>
> >> Så vidt jeg kan se i deflate.c ændrer de ni niveauer "bare" på fire
> >> parametre til samme mølle?
>
--SNIP--

>
> Godt, så behøver jeg ikke at revidere min opfattelse af at gzip
> implementerer en enkelt algoritme og at -1 til -9 alene ændrer på
> parametrene til denne.
som du selv har skrevet tidligere
min misssion var ikke at ændre nogens opfattelse af implenteringen, men
at gøre opmærksom på forskellen i, hvorledes bzip2 hhv gzip skifter
adfærd ved forkellige valg af -[1-9]. fordi et af de tidlige indlæg i
tråden for mig såud til at give udtryk for en tro på, at man kunne
reducere forvente gzip-lignende adfærd fra bzip2

jeg beklager, at jeg "kom til" at skrive "skifter algoritme" i stedet
for "skifte måde at beregne på"
--SNIP--


--
//Jacob Gaarde
//Dont reply to my (aparent) e-mail address. Instead Use
//e-mail : gaarde <at> mailme <dot> dk

---

On Wed, 10 May 2006 23:57:03 +0200, Jacob wrote:

> min misssion var ikke at ændre nogens opfattelse af implenteringen, men
> at gøre opmærksom på forskellen i, hvorledes bzip2 hhv gzip skifter
> adfærd ved forkellige valg af -[1-9].

Ok, så det lykkedes dig at sige "bzip2s hastighed påvirkes stort set
ikke af -1 til -9, i modsætning til gzips" på en meget kringlet og
fejlfyldt måde?

Manual-siden siger det således:

"In particular, --fast doesn't make things significantly faster."


,

--
"Where hell waits behind every door Adam Sjøgren
With John Denver songs" asjo@koldfront.dk