arhiveri.713dejanr,
U direktorijumu IBMPC\ARCHIVER je "poslastica" - pre-release novog
ARJ-a zvani ARJ239D.EXE. Uz njega je i ARJU239D.ARJ, dodatak uz
pre-relase, nisam joź stigao da pogledam źta taŽno tamo ima ali, ako
sam dobro razumeo, neźto źto su zaboravili da zapakuju u glavnu
arhivu.
Download-ujte, probajte i da Žujemo prva iskustva!
arhiveri.714ppekovic,
-> #713, dejanr>> Download-ujte, probajte i da Žujemo prva iskustva!
ZIP je standard. Novi ZIP je brČi i bolje kompresuje. Ostaje
jedino pitanje multi volume-a, a tu arj nalazi svoji mesto kao
program za deljenje ZIP arhive, a ne kao program za kompresiju. Za
tu svrhu bi mogli naęi neki drugi, kraęi (LCOPY).
Paya
arhiveri.716viktor,
Zdravo,
Izasao je novi SHEZ (8.8).
Pozdrav.
arhiveri.717bulaja,
-> #716, viktor│Izasao je novi SHEZ (8.8).
└───
Znamo :), dobili smo ga pre nekoliko dana, al' je Jim Deer poceo mnogo
da nas nervira pa necemo da stavimo Shez u dir :). Ozbiljno, vec je
otkriven (by Drakce) jedan bug u novom Shez-u, ne moze da se stavi *.*
za default masku za prikaz fajlova u tekucem diru. Moze $.$ (samo
arhive), a kad se stavi *.* javi error. Znaci ceka nas sesta verzija
Shez-a za dva meseca :(.
arhiveri.718ssokorac,
-> #714, ppekovic ─┼┤ ZIP je standard. Novi ZIP je brČi i bolje kompresuje. Ostaje
Je si li probao novi ARJ ili je to opet ono 'ZIP je bolji, Žik neka neko
kaČe suprotno' ? :)
arhiveri.719bulaja,
**** new file ****
R:\IBMPC\ARCHIVER\*.*
----------------------
zip2stru zip 12331 Opis strukture PKZIP 2.0+ arhiva
arhiveri.720darone,
-> #716, viktor>> Izasao je novi SHEZ (8.8).
Ja gledam u buduęnost: izaźao je i najnoviji, 9.0!
;)
darone
arhiveri.721dejanr,
-> #718, ssokorac>> > ZIP je standard. Novi ZIP je brČi i bolje kompresuje. Ostaje
>>
>> Je si li probao novi ARJ ili je to opet ono 'ZIP je bolji, Žik neka neko
>> kaČe suprotno' ? :)
Mislim da je Payina poruka naprosto prvi utisak, arhiver treba detaljno
testirati. Ja sam napravio samo jedan test, i evo źta je bilo: raspakovao
sam ARJ239d.exe i onda uradio PKZIP -ex MMM *.* a onda i ZIP2EXE MMM.ZIP.
Dobio sam MMM.EXE Žijim se startovanjem dobija isto (osim AV check-a,
naravno) źto i startovanjem ARJ239D.EXE. Uporedio sam veliŽine te dve
arhive: ARJ239D.EXE: 220386 bajta, MMM.EXE 214853. Ukratko, Jung bi
korisnicima skratio download-ovanje da je svoj arhiver spakovao ZIP-om ;>
Jedan test, naravno, ne znaŽi mnogo, ali mislim da novi ARJ nema źanse
da se meri sa ZIP-om (bar po brzini) jer je Jung izgleda reźio da NE
koristi "prave" 386 instrukcije, DPMI itd. No, moČda tako dobije na
pouzdanosti, koja je kod mene uvek bitniji parametar.
Najzad, ovo je ipak pre-release, da saŽekamo "pravi" ARJ 2.50 (jel ęe
tako da se zove?) za opseČnije testiranje.
arhiveri.722ppekovic,
-> #718, ssokorac>> ─┼┤ ZIP je standard. Novi ZIP je brČi i bolje kompresuje. Ostaje
>>
>> Je si li probao novi ARJ ili je to opet ono 'ZIP je bolji, Žik neka neko
>> kaČe suprotno' ? :)
Sedi pa izmeri.
Paya
arhiveri.723ppekovic,
-> #721, dejanr>> Mislim da je Payina poruka naprosto prvi utisak,
Raspakovao sam ga, napunio jedan direktorijum svim i svaŽim,
podigao maźinu bez keźera, rezidentnih programa i sliŽnih
zezalica, spakovao sam taj direktorijum uz pomoę novog arj-a sa
svim onim switch-evima, spakovao i uz pomoę zip-a sa razliŽitim
switch-evima za kompresiju, brzinu i sl., izmerio vreme, i napisao
onu poruku. Razlika je zaista bila oŽita.
Paya
P.S. MoČda moja maźina navija za ZIP ;)))
arhiveri.724dcolak,
-> #713, dejanr│ Download-ujte, probajte i da Žujemo prva iskustva!
Ex, do ZIP2.0 bejaźe ONLY ARJ, no posle ZIP2.0
beźe ZIP2.0. Onda je doźao ARJ prerel. i ostade
ZIP2.0, jer: ZIP JE BR▓I
ZIP DAJE KRA»E
ZIP JE LEP▒I O;)
Sledge DAMMIR!
arhiveri.725wizard,
-> #717, bulaja> Ozbiljno, vec je
> otkriven (by Drakce) jedan bug u novom Shez-u, ne moze da se stavi *.*
> za default masku za prikaz fajlova u tekucem diru.
A ne radi ni SHEZ <ime.arhive>. :(((
arhiveri.726viktor,
-> #725, wizardZdravo,
Evo komentara oko problema oko SHEZ-a 8.8.
Moram priznati da sam zbunjen. "SHEZ <ime_arhive>" radi kao zmaj.
"SHEZ." radi takodje kao zmaj daje sve datoteke cija su prezimena zadata
u shezcfg kao "arhivska prezimena" ali tek F6 daje sve datoteke bile one
zadate kao arhive ili ne, kada smo vec jednom u SHEZ-u. Dakle, jedino
sto priznajem da ne radi jeste "SHEZ *.*" ali ne znam da li je to
radilo u ranijim verzijama, jer nisam koristio taj pristup. Ja sam
oduvek koristio ovo skraceno pozivanje "SHEZ ." Dakle, ja nista od
problema nisam uocio, verovatno je to jer se nisam dovoljno dugo trudio
:), ali sve sto je navedeno kao problem, nekako mi ne stoji ...
SHEZ pozivam alias-om u 4DOS-u:
SHEZ=c:\...\shez.exe
postavljene su sledece okolinske promenljive:
SHEZCFG=C:\...\SHEZ.CFG
SHEZWORK=C:\...\SHEZ
(SHEZ je i u putanji ...)
mada sam sve isprobao i direktnim pozivanjem. Probao sam i sa
COMMAND.COM-om i iskustva su ista.
Pozdrav.
arhiveri.727wizard,
-> #726, viktor> Moram priznati da sam zbunjen. "SHEZ <ime_arhive>" radi kao zmaj.
Kod mene samo uŽita spisak fajlova iz arhive, a kada Čelim da pogledam
neki - arhiver prijavi da ne moČe da na¬e (ne postoji) fajl. Isto se
deźava i sa ZIP-ovanim, ARJ-ovanim i ARC-ovanim arhivama.
Apgrejd :) sam uradio tako źto sam (kao i uvek) prekopirao novi SHEZ
preko starog. Ovog puta sam joź jednom preźao preko svih opcija u
SHEZCFG, par puta snimao konfiguraciju i niźta.
Probaęu sa SET promenljivima, do sada ih nisam koristio, iako mi je
enviroment ogroman. Imam definisane set promenljive i za programe koje
ne koristim ni jednom u pola godine. :) Jel ona prva spreŽava
koriźeęenje onog Z# direktorijuma?
InaŽe i ja radim pod 4DOS-om, ali nemam alias koji direktno poziva SHEZ,
imam jedan koji na <Alt-H> ispiźe 'shez ' iz komandnog prompta, a onda
ja dodajem źta mi treba ili samo lupam <enter>. :)
arhiveri.728pele,
-> #724, dcolak>=} ZIP JE LEP▒I O;)
Ovakve konkretne i objektivne ocene su uvek dobrodoźle :))
pele.
arhiveri.729dr.grba,
-> #714, ppekovic>> ZIP je standard. Novi ZIP je brzi i bolje kompresuje. Ostaje
>> jedino pitanje multi volume-a, a tu arj nalazi svoji mesto kao
Molim te, ne davi.
arhiveri.730ppekovic,
-> #729, dr.grba>>>> ZIP je standard. Novi ZIP je brzi i bolje kompresuje. Ostaje
>>>> jedino pitanje multi volume-a, a tu arj nalazi svoji mesto kao
>>
>> Molim te, ne davi.
Ajmo redom:
ZIP je standard.
SHAREWARE Magazine, Nov-Dec 1991, Fall Releases, Joseph Speaks.
"Don't tell the creators of ARJ that PKZIP is the standard for
data compression. They probably already know. ..."
Pored toga źto to i vrapci na grani znaju, evo ti i
napismeno. Ovo je izvod iz fajl-a WHY_ARJ.DOC koji je deo arhive
novog arj-a (tek uz put da pokaČem i da sa vrlo paČljivo Žitao
veęi deo dokumentacije novog arj-a). Datum koji stoji je Nov-Dec
1991, a Jung to joź drČi u njegovoj arhivi znaŽi da i on dalje
priznaje da je ZIP standard.
Novi ZIP je brzi i bolje kompresuje.
Ajde lepo uzmi novi ZIP i novi ARJ pa ih pusti da rade sa
odgovarajuęim switch-evima za kompresiju, uzmi źtopericu u ruke pa
meri.
Paya
arhiveri.731dcolak,
-> #728, pele│> =} ZIP JE LEP▒I O;)
│
│ Ovakve konkretne i objektivne ocene su uvek dobrodoźle :))
Objektivnost iznad svega!
Za domovinu, sa Titom!
:))))
Sledge DAMMIR!
arhiveri.732mbole,
Nisam Žitao dokumentaciju novog ZIP-a al mi je jedna stvar Čestoko
zasmetala.
Naime kada pravi multi volume arhive zip menja ime diskete
(PKBACK#broj), umesto da imenuje fajlove drugaŽije (kao arj). Malo mi
slu¬uje disk kataloger.
arhiveri.733zkrstic,
-> #729, dr.grba>>> ZIP je standard. Novi ZIP je brzi i bolje kompresuje. Ostaje
>>> jedino pitanje multi volume-a, a tu arj nalazi svoji mesto kao
>
> Molim te, ne davi.
Savrźeno argumentovano! Tako treba! Ua Zip! ;)
arhiveri.734bulaja,
**** new file ****
R:\IBMPC\ARCHIVER\*.*
----------------------
shez89 arj 112484 Shez v8.9, shell za laksi rad sa arhiverima #1/2
shez89 a01 111526 Shez v8.9, shell za laksi rad sa arhiverima #2/2
Ň═══════════════════════════════════════════════════════════════════════════Ş
│ UPDATES/FIXES IN SHEZ Version 8.9 │
Ă═══════════════════════════════════════════════════════════════════════════Á
│When entering an un-qualified filename on the command │
│line SHEZ would not allow access to the file, this has been │
│corrected. │
│ │
│When entering a filename with a $ anywhere in the name, SHEZ │
│would not allow access to the file, this has been fixed. │
│ │
│To display the mouse menu, double clicking the left mouse │
│button has been reinstated. │
│ │
│Added Freshen file, and External Viewer launch, to the mouse │
│menu. │
│ │
│When entering a filespec on the command line sometimes SHEZ │
│would not find the file, -- FIXED -- │
│ │
│When using *.* on the command line, or in the configuration │
│file SHEZ would not find any files. --FIXED-- │
│ │
│SHEZ will now accept relative path names on the command line. │
│I.E. ..\any\*.* │
│ │
│The environment variable SHEZEV is no longer used to specify │
│external viewers. This has been replaced by a SHEZ.EV external │
│file. │
ď═══════════════════════════════════════════════════════════════════════════ż
arhiveri.735bulaja,
BUUUUUUUUUUG u ZIP2EXE iz ZIP 2.04 paketa!!! Jeeeeeeeeeeeeee :)))))))).
Bug se ogleda u sledecem - ukoliko se napravi mali (mini/junior) PKSFX
program on se nece se nece ispravno raspakovati u neki drugi dir. Npr.
imate SFX ARHIVA.EXE u kome se nalaze TETRIS.EXE i READ.ME. Kada ga
startujete sa arhiva e:\tmp SFX UNZIP ce na E:\ napraviti datoteke
TMPTETRIS.EXE i TMPREAD.ME. Sto bi rekao Bole, Ha ha GLUPI ZIP O;>.
arhiveri.736wizard,
-> #735, bulaja> Bug se ogleda u sledecem - ukoliko se napravi mali (mini/junior) PKSFX
> program on se nece se nece ispravno raspakovati u neki drugi dir.
To sam veę 100 puta iskusio. :( Mislio sam da je to FEATURE a ne BUG. :)
Jesi li siguran da je problem samo u "junior" verziji?
Pretpostavljam da znaź, ali ako dodaź jedno '\' na kraj, problem je
reźen. :)
arhiveri.738viktor,
-> #734, bulajaZdravo,
Bili ste u pravu ...
Pozdrav.
arhiveri.739todorp,
-> #721, dejanr> Najzad, ovo je ipak pre-release, da sacekamo "pravi" ARJ 2.50 (jel ce
> tako da se zove?) za opseznije testiranje.
Najverovatnije nece jer je 2.50 hack verzije 2.30, dok je 2.40 trojanac.
Pozdrav od Todora.
arhiveri.740dr.grba,
-> #722, ppekovic
>> Sedi pa izmeri.
Kojom velicinom u testu meris pouzdanost ?
arhiveri.741ppekovic,
-> #740, dr.grba>>>> Sedi pa izmeri.
>>
>> Kojom velicinom u testu meris pouzdanost ?
Drago mi je da si se vratio u vode razgovora bez uvreda
(bezrazloČnih), te źto smo se sloČili na osnovu oŽiglednih
Žinjenica da je ZIP standard i da brČe i bolje kompresuje.
Pouzdanost se meri brojem i fatalnoźęu (uh izraza) problema u
duČem vremenskom periodu. Verzija ZIP-a 1.1 koja je u upotrebi veę
viźe godina je moraź se sloČiti pouzdana, źto pokazuje mali broj
(nijedna (?)) prituČba na njegov raŽun. Na ARJ su se nekoliko puta
Čalili (dejanr ako se dobro seęam). Novi ZIP i novi ARJ (beta) su
isuviźe kratko na trČiźtu da bi se generalno moglo govoriti o
pouzdanosti. Ono o Žemu se moČe govoriti je brzina i stepen
kompresije.
Kad veę źirimo problem, plus za zip je i raźirenost zip-a u
drugim operativnim sistemima. Postoji mnogo ZIP klonova, a za ARJ
za unix recimo, ja tragam veę odavno. Unarj imam, ali arj-a nema.
Da, baź malopre gledam listu fajlova sa nekih FTP server-a i
zanimljivo, nijedan nije zapakovan arj-om. Uglavnom vladaju ZIP,
ARC i LHA.
Paya
arhiveri.742bulaja,
-> #736, wizard│Jesi li siguran da je problem samo u "junior" verziji?
└───
Da, "normalna" verzija SFX radi Ok, al' ona produzava file za 20Kb :(.
arhiveri.743darone,
-> #735, bulaja>> startujete sa arhiva e:\tmp SFX UNZIP ce na E:\
>> napraviti datoteke TMPTETRIS.EXE i TMPREAD.ME.
>> Sto bi rekao Bole, Ha ha GLUPI ZIP O;>.
Aaaaaaa, Čestoko greźiź i 'bag' je dokumentovan.
Naime, SFXJR je toliko mali (a sluČi svrsi) da ne
podrazumeva dir bez beksleźa (dakle, mora temp\ a
ne temp). «itao sam ja to, al da sad na¬em... ne
bih osim ako mi plate :)
darone
arhiveri.744ssokorac,
-> #730, ppekovic ─┼┤ Ajde lepo uzmi novi ZIP i novi ARJ pa ih pusti da rade sa
─┼┤ odgovarajuęim switch-evima za kompresiju, uzmi źtopericu u ruke pa
─┼┤ meri.
Izbroj switcheve pa uporedi, pakuj na viźe disketa pa otpakuj i uporedi
pozdanost.
arhiveri.745ppekovic,
-> #744, ssokorac>> ─┼┤ Ajde lepo uzmi novi ZIP i novi ARJ pa ih pusti da rade sa
>> ─┼┤ odgovarajuęim switch-evima za kompresiju, uzmi źtopericu u ruke pa
>> ─┼┤ meri.
>>
>> Izbroj switcheve pa uporedi, pakuj na viźe disketa pa otpakuj i uporedi
>> pozdanost.
Da izbrojim switch-eve? Kakve to veze ima sa brzinom i
stepenom kompresije.
ARJ sam dugo koristio za posao arhiviranja na viźe disketa i
nikad mi nije pravio problem (dejanr-u jeste). ZIP multivolume
koristim poslednjih mesec dana (5-6 puta) i za sada nije pravio
nikakvih problema. Multivolume opciju novog arj-a nisam koristio.
Za novi ZIP i ARJ ęe se tek pokazati koliko su pouzdani.
Sve u svemu, niźta novo nisi rekao kao prednost arj-a.
Paya
arhiveri.746dusanp,
-> #745, ppekovic=> Sve u svemu, niźta novo nisi rekao kao prednost arj-a.
Meni MNOGO znaci da mogu da arhivu pocepam na delove
proizvoljne velicine.Znam da postoje programi za cepanje
zip (i svih drugih fajlova) ali da bi se oni koristili
na disku moras da imas dovoljno mesta za spajanje arhive
(sto kod mene NIKAD nije slucaj). Sa druge strane ni -&
opcija zip-a mi se ne dopada jer ne radi sa hardom (!!!)
i ne moze joj se zadati velicina parceta.
Kada bi zip imao lepo resenu multivolume podrsku (sto
je u mom slucaju opcija koju najvise koristim), stvarno
bi bio bez premca. Ovako, onih par procenata bolje kom-
presije ne mogu da me nateraju da koristim zip kao glavni
arhiver. U stvari, koristim zip, ali samo kada arhiviram
nesto sto ce mi sluziti kao privremena arhiva. Kada ide
na diskete, koristim arj.
arhiveri.747ssokorac,
-> #741, ppekovic ─┼┤ Pouzdanost se meri brojem i fatalnoźęu (uh izraza) problema u
─┼┤ duČem vremenskom periodu. Verzija ZIP-a 1.1 koja je u upotrebi veę
─┼┤ viźe godina je moraź se sloČiti pouzdana, źto pokazuje mali broj
─┼┤ Čalili (dejanr ako se dobro seęam). Novi ZIP i novi ARJ (beta) su
─┼┤ isuviźe kratko na trČiźtu da bi se generalno moglo govoriti o
─┼┤ pouzdanosti. Ono o Žemu se moČe govoriti je brzina i stepen
─┼┤ kompresije.
«ekaj, Žekaj... Kad govorimo o pouzdanosti, onda priŽamo o zipu 1.1 (koji
po kompresiji ne moČe ni da se poredi sa arj-om) a kada govorimo o brzini i
kompresiji onda o zipu 2.04 (koji po pouzdanosti ne moČe da se poredi sa
arj-om, naravno, govorim o najnovijoj zvaniŽnoj verziji, tj. 2.30; neęu da
skaŽem sa jedne na drugu kako mi odgovara). Dakle, izjasni se o Žemu priŽaź
pa onda moČemo da govorimo o argumentima.
arhiveri.748dejanr,
-> #747, ssokorac>> «ekaj, Žekaj... Kad govorimo o pouzdanosti, onda priŽamo o zipu 1.1 (koji
>> po kompresiji ne moČe ni da se poredi sa arj-om) a kada govorimo o brzini
>> i kompresiji onda o zipu 2.04 (koji po pouzdanosti ne moČe da se poredi sa
>> arj-om, naravno, govorim o najnovijoj zvaniŽnoj verziji, tj. 2.30
Odakle tvrdlja o nepouzdanosti ZIP-a 2.04? Kako mi se Žini, jedan broj
korisnika je imao probleme sa DPMI-om, i to je reźeno u tekuęoj verziji
2.04e. Baź sam prekjuŽe zvao PKWare-ov BBS i malo Žitao poruke, ne nai¬oh
ni na kakvo pominjanje problema sa nepouzdanoźęu ZIP-a. Jesi li ti imao
problema sa njim, i moČe li se neki od tih problema ponoviti?
arhiveri.749ppekovic,
-> #747, ssokorac>> «ekaj, Žekaj... Kad govorimo o pouzdanosti, onda priŽamo o zipu 1.1 (koji
>> po kompresiji ne moČe ni da se poredi sa arj-om) a kada govorimo o brzini i
>> kompresiji onda o zipu 2.04 (koji po pouzdanosti ne moČe da se poredi sa
>> arj-om, naravno, govorim o najnovijoj zvaniŽnoj verziji, tj. 2.30; neęu da
>> skaŽem sa jedne na drugu kako mi odgovara). Dakle, izjasni se o Žemu priŽaź
>> pa onda moČemo da govorimo o argumentima.
Uvek sam jasno govorio o verzijama i rekao isto źto ęu i sad.
Poredimo novi ZIP i novi ARJ. Veę sam rekao da o pouzdanosti
istih neęu govoriti jer je suviźe rano.
Elem, kao źto rekoh,
ZIP 2.04e je brČi i bolje pakuje (dokazano). Nalednik je
neŽega źto se zove standard (pokazano). Ima multivolume opciju
(istina ne na proizvoljnu duČinu, mada postoji gomila split
programa, tako da to nije veliki problem). Veoma bitno je i źto ga
ima na veęini operativnih sistema.
Osim źto su mi govorili da ne davim, da ne znam o Žemu priŽam
i sl. kao jedini argument (osim fleksibilnijeg multivolume-a) za
arj, ima li neko zaista iźta viźe da doda u priog arj-u, ili da
zakljuŽimo i preporuŽimo korisnicima koji se manje razumeju u celu
problematiku da koriste ZIP, ukoliko im nije neophodno deljenje
arhiva na proizvoljno velike delove, a da to bude baź ugradjeno u
sam arhiver?
Paya
arhiveri.750adzem,
-> #749, ppekovic> arj, ima li neko zaista iźta viźe da doda u priog arj-u, ili da
Na primer nalazim se na disketi A ili B koja je gotovo popunjena
(slobodan prostor je manji od buduęe arhive) i hoęu da uradim sle-
deęe :
A:> PKZIP C:PRIMER
▒ta se sad deźava? Zbog manjka prostora na disketi i nemoguęnosti
da formira svoje privremene fajlove, ZIP ęe odbiti da radi uz sledeęu
poruku A:> PKZIP: (E14) Disk full.
U tom sluŽaju prinu¬en sam da pre¬em na C i uradim :
C:> PKZIP PRIMER A:*.*
Kako stoje stvari sa ARJ-om ? Ako uradim sledeęe :
A:> ARJ A C:PRIMER
ARJ ęe fino napraviti arhivu PRIMER na disku C, bez ikakvih upozorenja
i maltretiranja korisnika. ZnaŽi nije bitan prostor na izvornom disku
veę na odrediźnom.
▒etanje sa diska na disk, a zbog hirova arhivera, mi nimalo ne treba
i to je jedan od razloga da uglavnom koristim ARJ. Me¬utim, poźto ima
ljudi koje ne mrzi da naprave ZIP pa da ga nekim drugim programom ce-
pkaju na komade, njih neęe mrzeti ni da skakuęu sa diska na disk, pa
ovo verovatno i ne primaju kao neki minus za ZIP.
arhiveri.751darone,
-> #748, dejanr>> u tekuęoj verziji 2.04e.
Ipravka: tekuęa verzija ja 2.04g.
darone
arhiveri.752bulaja,
-> #749, ppekovic│ZIP 2.04e je brzi i bolje pakuje (dokazano).
└───
Da je brzi to je neosporno, ali uopste nije dokazano da bolje pakuje.
Pogledaj rezultate testova koje sam svojevremeno (kad je izasao PKZ
2.04c) poslao ovde, cini mi se da je ARJ jos uvek u prednosti (doduse
vrlo blagoj :) u vecini slucajeva u odnosu na ZIP.
arhiveri.753mbole,
-> #750, adzem> ▒ta se sad deźava? Zbog manjka prostora na disketi i
> nemoguęnosti da formira svoje privremene fajlove, ZIP ęe odbiti
> da radi uz sledeęu poruku A:> PKZIP: (E14) Disk full.
Postoji parametar (mislima da je -bdisk) koji odre¬uje gde ęe se praviti
temp fajl.
arhiveri.754ppekovic,
-> #752, bulaja>> Da je brzi to je neosporno, ali uopste nije dokazano da bolje pakuje.
>> Pogledaj rezultate testova koje sam svojevremeno (kad je izasao PKZ
>> 2.04c) poslao ovde, cini mi se da je ARJ jos uvek u prednosti (doduse
>> vrlo blagoj :) u vecini slucajeva u odnosu na ZIP.
Na brzinu sam probao (po ko zna koji put) arj239d i pkz204e i
dobio sledece:
Pakovao sam fajloce iz arj239d arhive.
arj -m1 203233
zip -ex 202069
Sor baza:
arj -m1 159557
zip -ex 157977
Jedinu prednost arj stekne kada kompresuje samo veę
kompresovane arhive (kad li se to koristi?) tj. kada radi samo
arhiviranje iz prostog razloga źto zip informacije o svakom fajlu
drČi na dva mesta ( sigurnost podataka? ).
Dakle ZIP BOLJE pakuje! pored toga (odgovor na jednu od
prethodnih primedbi) swap drive moČeź da mu zadaź. Sve u svemu,
opet niźta novo, ostaju jedino fleksibilniji multivolume-i, i? i?
Paya
P.S. ZIP je standardni arhiver na Sezamu. ARJ-a nema na sezamu :)
arhiveri.755dejanr,
-> #750, adzem>> Na primer nalazim se na disketi A ili B koja je gotovo popunjena
>> (slobodan prostor je manji od buduęe arhive) i hoęu da uradim sledeęe :
>> A:> PKZIP C:PRIMER ▒ta se sad deźava? Zbog manjka prostora na disketi
>> i nemoguęnosti da formira svoje privremene fajlove, ZIP ęe odbiti da
>> radi uz sledeęu poruku A:> PKZIP: (E14) Disk full. U tom sluŽaju
>> prinu¬en sam da pre¬em na C i uradim : C:> PKZIP PRIMER A:*.*
>> Kako stoje stvari sa ARJ-om ? Ako uradim sledeęe : A:> ARJ A C:PRIMER
>> ARJ ęe fino napraviti arhivu PRIMER na disku C, bez ikakvih upozorenja
>> i maltretiranja korisnika. ZnaŽi nije bitan prostor na izvornom disku
>> veę na odrediźnom.
Pa, nije ti baź previźe ubedljiv primer. ▒ta da, źto je po meni mnogo
Žeźęi sluŽaj, hoęeź da arhiviraź fajl koji je na disku u neku arhivu
na disketi, dakle otkucaź PKZIP A:TMP TEST.TXT. Ako ARJ stvarno koristi
odrediźni disk za privremene fajlove, doęi ęe do greźke i to joź
neprijatnije jer ni A: neęe reźiti problem.
Ako ti samo to smeta kod ZIP-a, ugradi u AUTOEXEC neźto kao:
SET PKTMP=C:\TEMP i ubuduęe ęe se svi privremeni fajlovi upisivati
u ovaj direktorijum, ne "misleęi" o izvoru/odrediźtu. Verovatno i ARJ
ima neki sliŽan SET.
>> ▒etanje sa diska na disk, a zbog hirova arhivera, mi nimalo ne treba
>> i to je jedan od razloga da uglavnom koristim ARJ.
Kao źto vidiź, razlog nije naroŽito jak. Imaź li joź neki?
arhiveri.756dejanr,
-> #752, bulaja>> > ZIP 2.04e je brzi i bolje pakuje (dokazano).
>> >
>> Da je brzi to je neosporno, ali uopste nije dokazano da bolje pakuje.
>> Pogledaj rezultate testova koje sam svojevremeno (kad je izasao PKZ
>> 2.04c) poslao ovde, cini mi se da je ARJ jos uvek u prednosti (doduse
>> vrlo blagoj :) u vecini slucajeva u odnosu na ZIP.
Moraęu da se podsetim tih testova, ali ja sam veoma opseČno testirao
koliko ZIP i ARJ arhiviraju i gotovo uvek je ZIP arhivirao neźto viźe.
U me¬uvremenu, kad god me ne mrzi da Žekam, ja posle ZIP-ovanja neŽega
radi prenosa na diskete uradim i jedan "dummy" ARJ istog fajla, Žisto
da vidim koliko koji arhivira u nekim "Čivotnim" situacijama. Gotovo
bez izuzetka ZIP arhivira bolje, desilo mi se par puta da ARJ neźto
viźe arhivira kada sam pakovao neke header fajlove kojih je bilo
podosta u direktorijumu.
Mada, dodao bih, razlike su u jednom i drugom sluŽaju priliŽno male tako
da bih i stepen kompresije PKZIP-a i ARJ-a oznaŽio kao "pribliČan", uz
malu prednost PKZIP-a.
arhiveri.757dusanp,
-> #752, bulaja=> Da je brzi to je neosporno, ali uopste nije dokazano da
=> bolje pakuje.
Na zalost ;) pakuje bolje skoro uvek. "Bolje" je uglavnom
samo simbolicno poboljsanje od 0.2-2%, tako da se moze
ignorisati (a ne mora). Radi lakseg merenja preformansi ;)
arhivera, napisao sam malo programce koje sve lepo do-
kumentuje. Mnogi ce me proklinjati zbog toga sto relativno
dug bat fajl ukljucujem u poruku, ali to je jedini nacin
da vas lenjost ne spreci da ga isprobate.
Za koriscenje TEST.BTM-a je potreban 4dos, zip, arj i
dobra volja. Test se vrsi bez kes programa i ostalih
zezalica, a posebno bez set promenljivih (arj_sw i
kako_se_vec_zove_zip_promenljiva).
Program se koristi tako sto se prekopira u root, predje
se u dir koji se arhivira i startuje \test.btm
TEST.BTM:
**************************************
@echo ******************************************** > \results
@echo %_CWD >> \results
@dir /u /k >> \results
@echo ******************************************** >> \results
@echo ZIP SA PODRAZUMEVANOM KOMPRESIJOM >> \results
@timer > NUL
@pkzip \test.xxx *.*
@timer >> \results
@dir /k \test.xxx >> \results
@del \test.xxx
@echo ******************************************** >> \results
@echo ZIP SA MAXIMALNOM KOMPRESIJOM >> \results
@timer > NUL
@pkzip -ex \test.xxx *.*
@timer >> \results
@dir /k \test.xxx >> \results
@del \test.xxx
@echo ******************************************** >> \results
@echo ARJ SA PODRAZUMEVANOM KOMPRESIJOM >> \results
@timer > NUL
@arj a \test.xxx *.*
@timer >> \results
@dir /k \test.xxx >> \results
@del \test.xxx
@echo ******************************************** >> \results
@echo ARJ SA MAXIMALNOM KOMPRESIJOM >> \results
@timer > NUL
@arj a -jm -m1 \test.xxx *.*
@timer >> \results
@dir /k \test.xxx >> \results
@del \test.xxx
@echo ******************************************** >> \results
@cls
@type \results
**************************************
arhiveri.758dusanp,
-> #754, ppekovic=> arj -m1 203233
=> zip -ex 202069
Zip vodi za 0.576...%
=> arj -m1 159557
=> zip -ex 157977
I za 1.0000...%
btw: maximalna kompresija arja se dobija upotrebom -m1 -jm
ne tvrdim da bi se nesto drasticno promenilo, al opet...
arhiveri.759dusanp,
-> #756, dejanr=> Mada, dodao bih, razlike su u jednom i drugom sluŽaju
=> priliŽno male tako da bih i stepen kompresije PKZIP-a i
=> ARJ-a oznaŽio kao "pribliČan", uz malu prednost PKZIP-a.
To je tacno, ja to pricam u vec nekoliko poruka.
arhiveri.760ppekovic,
-> #758, dusanp>> btw: maximalna kompresija arja se dobija upotrebom -m1 -jm
>> ne tvrdim da bi se nesto drasticno promenilo, al opet...
bio je ukljuŽen i -jm switch.
Paya
arhiveri.761dr.grba,
-> #741, ppekovicDobro sad, da ne sirim dalje : nisam imao nameru da vredjam (bulaja mi nece
verovati), vec sam koristio svoj cinizam da ispoljim neslaganje sa nekim
principom. (BTW, kako cinizam verovatno nije dobrodosao na SEZAM-u, to cu
verovatno morati da ga se lisim. Ali bolje je biti i cinik...).
Elem, malo (mnogo?) mi je zasmetalo ono teranje maka na konac u vezi sa
suprotstavljanjem dva ili vise programa. Nije mi namera da diskreditujem
ovaj ili onaj, nego da izrazim svoje misljenje da se cesto raspravlja o
drugorazrednim planovima ovih alata. Ubedjen sam da nije kljucna stvar
u brzini arhiviranja. Ubedjen sam da nije strasno ako se otkuca dva tri znaka
vise ili ako komandna linija ne prija necijem oku. Ubedjen sam da je pouzdanost
procesa arhiviranja NAJBITNIJA osobina nekog programa. Naravno, ustedi li se
kojih 5 - 10% u razlici stepena kompresije, odlicno! Itd, itd...
Kao sto se cesto kaze, od antagonizma softverskih kuca korisnik ima najvecu
korist. Svakako, ako se korisniku pomogne da razmrsi guzvu nastalu galamom...
...a imam utisak da nije preovladala konstruktivna rasprava, vec galama.
Priznajem, bio sam deo te galame. Necu vise, vec mnogo vas na SEZAM-u misli
da sam ovde samo da bih prosipao gluposti...
Pozdrav, dr ÔpŰa
arhiveri.762adzem,
-> #753, mbole> Postoji parametar (mislima da je -bdisk) koji odre¬uje gde ęe se
> praviti temp fajl.
Sjajno, ;> sad umesto kratkog PKZIP C:PRIMER dodajem kobasicu -bdisk+temp
i ZIP postaje joź neprijatniji za rad. Razlog viźe da koristim ARJ.
arhiveri.763adzem,
-> #755, dejanr> Pa, nije ti baź previźe ubedljiv primer. ▒ta da, źto je po meni
Dovoljno puta sam imao taj problem da je za mene ubedljiv.
> arhivu na disketi, dakle otkucaź PKZIP A:TMP TEST.TXT. Ako ARJ
> stvarno koristi odrediźni disk za privremene fajlove, doęi ęe do
> greźke i to joź neprijatnije jer ni A: neęe reźiti problem.
Onako kako sam ja napisao stvarno bi doźlo do greźke, ali pogreźio
sam. Umesto odrediźnog diska, "temp" datoteke se trpaju na hard.
> Ako ti samo to smeta kod ZIP-a, ugradi u AUTOEXEC neźto kao:
> SET PKTMP=C:░TEMP i ubuduęe ęe se svi privremeni fajlovi upisivati
Uh, uh, mnogo gnjavaČe. Poźto u firmi imam pristup na viźe raŽunara,
morao bih to da ęuźnem u svaki AUTOEXEC, a onda se pojavi neko ko je
"źef" na tom raŽunaru i to izbriźe, pa me opet doŽeka jedno "Disk
full". Za po kuęi to moČe da pro¬e, ali je mnogo jednostavnije kori-
stiti ARJ. :)
> Kao źto vidiź, razlog nije naroŽito jak. Imaź li joź neki?
Za sada ne. Na ovaj problem sam Žeźęe nailazio zadnjih dana jer sam
uporno hteo da koristim ZIP zbog kakvog-takvog dobitka u brzini. Na
kraju sam se vratio na ARJ.
arhiveri.764adzem,
-> #755, dejanr>>> i maltretiranja korisnika. ZnaŽi nije bitan prostor na izvornom
>>> disku veę na odrediźnom.
>
> Ako ARJ stvarno koristi odrediźni disk za privremene fajlove, doęi
> ęe do greźke i to joź neprijatnije jer ni A: neęe reźiti problem.
Kad sam pomenuo odrediźni disk nisam mislio na formiranje privreme-
nih datoteka veę na slobodan prostor za buduęu arhivu. Privremene
datoteke se, valjda, formiraju na hardu.
arhiveri.765banex,
-> #749, ppekovic>> arj, ima li neko zaista iźta viźe da doda u priog arj-u, ili da
>> zakljuŽimo i preporuŽimo korisnicima koji se manje razumeju u celu
Moram priznati da me je novi zip malo razoŽarao.
▒to se brzine tiŽe svaka mu Žast, ali su svi vaźi testovi su
prikazivali mnogo veęe razlike nego źto ih ja dobijam.
Imao sam na disku negde oko 30-40mb raznih programa spakovanih
sa arj-om v2.93a koje sam prebacio u zip v2.04g. Iako rezultati
oŽito pokazuju da zip viźe pakuje (samo jedan sluŽaj je dao
drugaŽiji odnos) razlike su bile toliko minimalne da se ceo posao
nije isplatio (razlika je bila negde oko 2-3% mereno odoka ;).
OŽekivao sam mnogo viźe od programa koji prepoznaje i koristi 386
procesor te ems/xms memoriju ;))
InaŽe, jedini sluŽaj da je arj bolje spakovao datoteke je gomila
malih datoteka 3-4k pojedinaŽno. Sa druge strane, pri pakovanju
velike datoteke arj je vrlo brzo shvatio da je bolje da datoteku
samo iskopira, dok je zip gurao do kraja da bi razlika na kraju bila
jedva 1%.
Ono źto je po meni prednost arj-a je pre svega multi volumen
filozofija koja je kod arj-a dovedena do savrźenstva(?)
(uzimajuęi u obzir da je sve viźe programa koji arhivirani prelaze
par mega) i moguęnost da se definiźu sve Čeljeni prekidaŽi u .cfg
datoteci. Dovoljno mi je bilo da jedanput paČljivo proŽitam uputstvo
i definiźem sve po meni potrebne prekidaŽe a zapamtim samo /v za
volumen i to u 3 forme (/v /vnum /va).
▒to se tiŽe standarda za arhiver Žinjenica je da se zip
(zakljuŽno sa verzijom 1.10) pojavio u pravo vreme i da je mnogo
bolje pakovao od tadaźnjeg arc-a te je defakto postao standard,
samo mislim da trŽimo ispred rude źto se novog zip-a tiŽe. Nisam
tako siguran da ęe on brzo zameniti staru verziju.
▒to se pouzdanosti tiŽe, arj je pravio probleme sa multivolumen
opcijom arhiviranja na diskete dok je ukljuŽen i neki od
keźera za disk (źto je vrlo brzo priznato i ispravljeno u
verziji 2.93a) ali mi se od tada NI JEDNOM nije desilo da
prijavi bilo kakvu greźku u datoteci. «ak i tada (u prethodnoj
verziji) se vrlo lako mogao povratiti sadrČaj svih spakovanih
datoteka osim (uglavnom) jedne koju nije mogao povratiti zbog
greźke.
To je, po meni, mnogo bolje od zip-a koji Žak ima poseban program
za spaźavanje datoteka koji prijavi da je sredio neispravan zip
koji ni posle toga ne mogu ni pogledati a kamoli raspakovati. Do
sada nisam uspeo ni jednu neispravnu zip datoteku da povratim ;).
Da ne ispadne da pljujem po novom zipu, koristim i koristięu
oba jer mi svaki na svoj naŽin odgovara sve dok se se (opet?) ne
pojavi neki bug.
CU! -BANE-
PS. Kad sam se veę ovoliko raspisao, da li neko zna razlog zaźto
zip (204g) prepoznaje 386sx a ne prepoznaje klasiŽan 386 25?
arhiveri.766ppekovic,
-> #761, dr.grba>> Ubedjen sam da je
>> pouzdanost procesa arhiviranja NAJBITNIJA osobina nekog programa.
Ok. stari ZIP se zaista pokazao kao veoma pouzdan kao i stari
ARJ, premda se dejanr neźto Čalio. Novi ZIP i ARJ su skoro izaźli
i prerano je govoriti o pouzdanosti.
Ajde da i ja kaČem zaźto koristim ZIP a ne ARJ. Ima dva
razloga. Prvi je źto kada nekom od raŽunarskih laika (nisu svi
ljudi koji koriste arhivere na Sezamu, Žak źta viźe, nije veęina
:)) dam ARJ arhivu, vrlo Žesto mi se desi da me pitaju a źta je to
arj? Drugi, najbitniji razlog je źto na UNIX-u i VMS-u nema arj-a.
Paya
arhiveri.767bulaja,
-> #754, ppekovic│Na brzinu sam probao (po ko zna koji put) arj239d i pkz204e i dobio sledece:
│ arj -m1
│ zip -ex
└───
A zasto ZIP probas sa maksimalnom a ARJ sa default kompresijom? :)
Kako bi bilo da ja testiram zip -e0 i arj -jm :). Ako cemo da pravimo
testove, onda nek to uvek bude sa default kompresijom - 99% korisnika
tako i radi, a valjda su i autori kao default stavili neki optimalni
metod. Samo bolje da batalimo te testove, posto je ocigledno da sada
nema pobednika u stepenu kompresije - razlike su minimalne (nekoliko
promila) i varijabilne.
│P.S. ZIP je standardni arhiver na Sezamu. ARJ-a nema na sezamu :)
└───
Jel'? :) ARJ-a nema medju arhiverima za pakovanje PAD-a samo zato sto mu
Sezam ostavlja suvise malo memorije (kao sto ti je poznato). Ali je zato
u PC direktorijumima 57.1% datoteka spakovano ARJ-om, a 39.9% ZIP-om :).
Btw "standarni" arhiver je ZIP 1.1, a ne 2.04.
arhiveri.768bulaja,
Jos jedan BUG :) PKSFXjr modula u ZIP-u 2.04 - ukoliko je SFX arhiva
ostecena to vam SFX nece ispisati - zaglavice se :). Nije stvar u tome
sto je u EXE deo uletelo nesto pa sludelo program (tu stvarno nema leka)
vec je taj junior unzip deep shit - jeste mali ali nista ne radi :).
arhiveri.769dejanr,
-> #765, banex>> Imao sam na disku negde oko 30-40mb raznih programa spakovanih
>> sa arj-om v2.93a koje sam prebacio u zip v2.04g. Iako rezultati
>> oŽito pokazuju da zip viźe pakuje (samo jedan sluŽaj je dao
>> drugaŽiji odnos) razlike su bile toliko minimalne da se ceo posao
>> nije isplatio (razlika je bila negde oko 2-3% mereno odoka ;).
>>
>> OŽekivao sam mnogo viźe od programa koji prepoznaje i koristi 386
>> procesor te ems/xms memoriju ;))
Teźko bi se moglo oŽekivati da koriźęenje EMS memorije smanji arhive,
tu je presudan algoritam. Koriźęenje EMS-a i 386 instrukcija utiŽe
na brzinu, dok je uticaj na kompresiju sasvim posredan (ako program
brČe radi, moČeź da primeniź bolji algoritam... ako ga znaź ;).
InaŽe, mene Žudi da novi ARJ (kako izgleda) neęe ozbiljnije koristiti
386-EMS/XMS/DPMI itd. «ini mi se da bez toga jednostavno ne moČe da
bude konkurentan ZIP-u...
>> To je, po meni, mnogo bolje od zip-a koji Žak ima poseban program
>> za spaźavanje datoteka koji prijavi da je sredio neispravan zip
>> koji ni posle toga ne mogu ni pogledati a kamoli raspakovati. Do
>> sada nisam uspeo ni jednu neispravnu zip datoteku da povratim ;).
Meni je PKZIPFIX pomogao viźe puta. Desi se da je disketa neispravna,
a samim tim arhiva ne moČe sa nje da se COPY na disk. Tu dam ignore
na Data error, pustim PKZIPFIX, onda PKUNZIP PKFIXED.ZIP i dobijem
fajl koji, doduźe, "pada" na CRC testu ali je veęina podataka (i
ispred i iza greźke!) ispravna. Imam ovde jednu takvu disketu, mogu
da je dam na uvid.
arhiveri.770dexi,
-> #760, ppekovic>> ne tvrdim da bi se nesto drasticno promenilo, al opet...
bio je ukljuŽen i -jm switch.
Kod mene je najbolja kompresija bila sa -jm bez -m1 !?
Koristim inaŽe i jedan i drugi arhiver i ne vidim razloga za
toliku galamu. Veęina ljudi koji imaju toliko znanja &
tehmiŽke kulture bez problema se koriste i PKZIP-om i
ARJ-om. InaŽe kao neutralni (samozvani) korisnik, tvrdim da
se ne moČe izreęi pauźalna ocena ocena: xxx.exe pakuje bolje
od yyy.exe, jer u mom to ne bi bilo utemeljeno na rezultatima
iz prakse...
dexi :)
arhiveri.771dnikolic,
-> #767, bulaja>> Jel'? :) ARJ-a nema medju arhiverima za pakovanje PAD-a samo zato sto mu
>> Sezam ostavlja suvise malo memorije (kao sto ti je poznato). Ali je zato
Sto ti je politika! :))
Pristalica ARJ-a: Sezam mu ostavlja malo memorije.
Protivnik ARJ-a: Arj trazi mnogo memorije.
dn
arhiveri.772peca.st,
-> #760, ppekovic!-> bio je ukljuŽen i -jm switch.
Nisam siguran, ali moguęe je da ono -m1 ako ga staviź u liniju
ima veęu prednost nad -jm iz SETa.
U opźte, kada pravite veę te testove (ja nemam nameru, povremeno koristim
ovo, povremeno ono, zavisno źta mi treba) izbacite sve SETove pa ispiźite
celu kobasicu, i onda merite.
I ajde prestanite da se sva¬ate, zna se za źta sluČi ARJ a za źta ZIP.
Pe¬a.
arhiveri.773peca.st,
-> #757, dusanp!-> ▓arj a -jm -m1 ░test.xxx *.*
Zaźto -m1?
Zaźto posle setovanja maximalne kompresije setovati i default kompresiju?
Tako se moČe desiti (ne tvrdim, ali moguęe je) da dva sviŽa, koja sluČe za
odre¬ivanje iste stvari a razliŽite "nijanse", smetaju jedan drugom.
Mislim, moguęe je da se raŽuna ZADNJI od takvih sviŽeva, ako ih je navedeno
viźe.
Pe¬a.
arhiveri.774peca.st,
-> #769, dejanr!-> Meni je PKZIPFIX pomogao viźe puta. Desi
!-> se da je disketa neispravna,
Meni i nije. :( Ne seęam se da je ikad uspeo da potpuno oporavi arhivu,
Žak i ako je u njoj bila samo jedna datoteka.
Pe¬a.
arhiveri.775spantic,
Pitamo o sigurnosti PKZIP 2.X? Xa! Evo pogledajte źta mi je javio prilikom
raspakivanja fajla koji je spakovan i raspakivan na goloj maźini, bez ikakvih
rezidentnih programa i bilo Žega.
PKUNZIP (R) FAST! Extract Utility Version 2.04g 02-01-93
Copr. 1989-1993 PKWARE Inc. All Rights Reserved. Shareware Version
PKUNZIP Reg. U.S. Pat. and Tm. Off.
80386 CPU detected.
EMS version 4.00 detected.
XMS version 3.00 detected.
Searching ZIP: N2.ZIP
Inflating: BGLOBALS.DAT
Extracting: DESC
Inflating: PLAYER.DAT
Inflating: SCD.ARK
Inflating: LEV.ARK PKUNZIP: (W23) Warning! file has bad table
PKUNZIP: (W15) Warning! file fails CRC check
PKUNZIP: (W26) Warning! N2.ZIP has errors!
arhiveri.776mbole,
-> #762, adzem> Sjajno, ;> sad umesto kratkog PKZIP C:PRIMER dodajem kobasicu
> -bdisk+temp i ZIP postaje joź neprijatniji za rad. Razlog viźe
> da koristim ARJ.
Vidiź zato postoji set pomenjliva = idt. Meni ovo odavno stoji u
autoexecu za arj pa ne vidim zaźto ne bi stajalo i za zip. InaŽe mislim da
su oba programa sasvim u redu. Jedan ima neke stvari mnogo bolje ura¬ene
(arj arhive iz viźe delova), dok je drugi malo bolji u nekim stvarima koje
su u principu bitnije za svakodnevni rad (zip po brzini i stepenu
kompresije). Oba nisu predugaŽka tako da ne vidim problem u tome da ih
drČim zajedno na disku, i koristim onaj Žije mi moguęnosti u tom trenutku
viźe odgovaraju.
arhiveri.777mbole,
-> #754, ppekovic> P.S. ZIP je standardni arhiver na Sezamu. ARJ-a nema na sezamu
> :)
Jel se ti to źaliź ili stvarno odavno nisi bacio pogled u neki
direktorijum.
arhiveri.778mbole,
-> #765, banex> i definiźem sve po meni potrebne prekidaŽe a zapamtim samo /v
> za volumen i to u 3 forme (/v /vnum /va).
Meni i -va stoji u cfg fajlu. I pri tom se arj ne buni pri pakovanju na
disk za razliku od zip-a. He sad mi pade na pamet. Joź mi se nije desilo al
ako bi napunio hard, dal bi mi traČio da "ubacim" sledeęi ;))))
arhiveri.779dejanr,
-> #774, peca.st>> Meni i nije. :( Ne seęam se da je ikad uspeo da potpuno oporavi arhivu,
>> Žak i ako je u njoj bila samo jedna datoteka.
Normalno da ne moČe potpuno oporaviti arhivu, kako bi i mogao? Ako je
fajl fiziŽki oźteęen, deo podataka je nepovratno izgubljen i tu nema
nazad. Poenta je da PKZIPFIX oporavi koliko moČe - dakle, ako je u pitanju
tekst, izgubiź u sredini neki kilobajt ali je ono pre i posle ok. Ako
je baza podataka, izgubiź neki broj slogova. Ako je slika, dobijeź (!)
mrlju, a ako je .EXE program... onda moČeź da ga baciź ;)
Doduźe, mogao bi se zamisliti algoritam koji bi ubacivao redundane
informacije u fajl na osnovu kojih bi se docnije, ako se fajl oźteti,
*sve* informacije mogle rekonstruisati. Pri tome je, naravno, bitan odnos
nekorisnog dela informacija i broja greźaka koje bi se mogle ispraviti.
Obzirom da pri kopiranju sa diskete obiŽno pukne ceo sektor, ili nekoliko
sektora, redundanca bi bila tolika da od arhiviranja ne bi bilo vajde, pa
Žisto sumnjam da ęe neko to napraviti.
Ukratko, kada se snimi arhiva na disketu, obavezno COPY /B A:*.* NUL, a
ako se ima vremena, moČda je joź bolje PKUNZIP -t A:*.ZIP. Da, ako se
flopi keźira, treba to iskljuŽiti.
arhiveri.780djelovic,
-> #769, dejanr> Teźko bi se moglo oŽekivati da koriźęenje EMS memorije smanji arhive, tu
> je presudan algoritam.
Not so. Algoritam je, naravno, najvaČniji, ali je ovde potrebna
i Žista sila :). Viźe memorije omoguęuje modeliranje veęeg reda, tj.
omoguęuje pamęenje tablica za viźe slova odjednom. Recimo, pri
Hofmanovom kodiranju se pamte statistiŽke vrednosti za svako slovo, ali
bi se mnogo bolji rezultati dobili ako bi se pamtile statistiŽke
vrednosti za sve razliŽite dvoslovne kombinacije, źto opet zahteva 256
puta viźe memorije. Na DOS-u je zato maksimum modeliranje drugog reda,
dok na UNIX-u recimo moČeź da piŽiź sa order-3 modeliranjem bez problema.
Neka je procena da se modeliranje treba gurati do petog stepena
a da posle toga i nema svrhe jer tu manje-viźe prestaje (relativno)
visok stepen korelacije me¬u podacima, mada to zavisi od tipa podataka.
Ovo se sve naravno ne odnosi samo na Hofmanovo kodiranje veę i na
bilo koju drugu vrstu kodiranja koja podleČe zakonima entropije.
arhiveri.781ppekovic,
-> #765, banex>> OŽekivao sam mnogo viźe od programa koji prepoznaje i koristi 38
>> procesor te ems/xms memoriju ;))
Sasvim je normalno da zbog toga ne pakuje bolje veę
samo brČe ;)
>> To je, po meni, mnogo bolje od zip-a koji Žak ima poseban program
>> za spaźavanje datoteka koji prijavi da je sredio neispravan zip
>> koji ni posle toga ne mogu ni pogledati a kamoli raspakovati. Do
>> sada nisam uspeo ni jednu neispravnu zip datoteku da povratim ;).
Sama struktura ARJ i ZIP fajlova gde ZIP na dva mesta
drČi informacije o fajlovima ide u prilog ZIP-u. Deźavalo mi
se nekoliko puta do sada da nai¬em na oźteęene ZIP i ARJ
fajlove i pri "sre¬ivanju" nisam primetio prednost ni jednog
od nih. Jednostavno, izvadili su źta se moglo izvaditi. Sam
postupak "vraęanja" arhive u neko nromalno stanje nije nikakva
specijalna filosofija. Ako te zanima poslaęu ti opise
struktura ARJ i ZIP fajli.
Paya
arhiveri.782ppekovic,
-> #767, bulaja>> A zasto ZIP probas sa maksimalnom a ARJ sa default kompresijom? :)
>> Kako bi bilo da ja testiram zip -e0 i arj -jm :).
Kao źto rekoh dati rezultati su dobijeni sa -m1 -jm.
Dakle, nema greźke :)
>> Jel'? :) ARJ-a nema medju arhiverima za pakovanje PAD-a samo zato
>> sto mu Sezam ostavlja suvise malo memorije (kao sto ti je
>> poznato). Ali je zato
Ili zato źto on jede previźe memorije? :) Kratko: ZIP
moČe da radi na Sezamu, ARJ ne moČe ;)
>> Btw "standarni" arhiver je ZIP 1.1, a ne 2.04.
TaŽno, s tim źto znaź i samda se razmiźlja o
stavljanju novog ZIP-a u listu arhivera. A kad ęe ARJ? :)
Paya
P.S. Ludo se zabavljam dok piźem sve ovo, iako mi je ponekad
Čao źto sam stao na stranu koja sigurno dobija, nije
zanimljivo. :))))
arhiveri.783ppekovic,
-> #768, bulaja>> Jos jedan BUG :) PKSFXjr modula u ZIP-u 2.04 - ukoliko je SFX
>> arhiva ostecena to vam SFX nece ispisati - zaglavice se :). Nije
>> stvar u tome sto je u EXE deo uletelo nesto pa sludelo program (tu
>> stvarno nema leka) vec je taj junior unzip deep shit - jeste mali
>> ali nista ne radi :).
Au Bulaja poŽeo si ko Hercog :)))
Ajde da je to rekao neki laik ali ti? Pa znaź i sam da
kad praviź program kojem je osnovni cilj da bude źto manji,
da ęeź prvo da izbaciź raznorazne provere.
Kad smo veę kod toga, baci oko na unarj230 sakati
dearhiver koga je pisao liŽno Jung. Po istoj logici po kojoj
ti ceniź juniora ja bi treba da kaČem deep shit puta stotinu!
;))
Paya
arhiveri.784mladenp,
-> #766, ppekovic> Ajde da i ja kaČem zaźto koristim ZIP a ne ARJ.
Joź jedan razlog: sto puta je lakźe reęi - program
je zipovan. "Arjovan" zvuŽi jezivo. ;)
> arj? Drugi, najbitniji razlog je źto na UNIX-u i VMS-u
> nema arj-a.
Ja od onog Zipa sa UBBG-a nisam imao vajde. Kako god
da prenesem arhivu (GSZ sa svim moguęim sviŽevima,
TM-ov imterni Zmodem, SZ i SZNEW) ne mogu da je raspakujem.
Sad se viźe ne seęam, radila je samo jedna kombinacija
(valjda TM-ov Z sa -b i stari SZ) ali mi mije zgodna. Zato
rabim Arc. ;)
arhiveri.785zkrstic,
-> #767, bulaja> Sezam ostavlja suvise malo memorije (kao sto ti je poznato). Ali je
> zato u PC direktorijumima 57.1% datoteka spakovano ARJ-om, a 39.9%
> ZIP-om :).
BoČe, da te neznam, reko bi "pusti ga komunjara" ;)))))
Pa ko je pakovo' fajlove za DIR, ti ili ja ? Koliko me pamęenje
sluČi, ti si joź uvek File moderator :))))
Zkr ;)
arhiveri.787viktor,
-> #784, mladenp
Zdravo,
Ovako, ja sam imao problema sa prenosenjem ZIP-ovanih file-ova
Kermit-om ali nsu nestali kada sam poceo da koristim ZIP2.
Probaj.
Pozdrav.
arhiveri.788spantic,
-> #766, ppekovic> arj? Drugi, najbitniji razlog je źto na UNIX-u i VMS-u
> nema arj-a.
Imaź UNARJ Payo :)
arhiveri.790zkrstic,
-> #774, peca.st> !-> Meni je PKZIPFIX pomogao viźe puta. Desi
> !-> se da je disketa neispravna,
>
> Meni i nije. :( Ne seęam se da je ikad uspeo da potpuno oporavi
> arhivu, Žak i ako je u njoj bila samo jedna datoteka.
Bio si baksuz. Ja sam uspeo da vratim neke fajlove, konkretno
baze i tekstove. I to ne jedanput.
Zkr
arhiveri.791dusanp,
-> #773, peca.st=> Zaźto -m1?
=> Zaźto posle setovanja maximalne kompresije setovati i
=> default kompresiju?
Da znas da si me zabrinuo, u stvari nisam bio 100% siguran
da treba oba switcha.
Seo i isprobao:
default arj 850003 Gô arj, bez ijednog switcha, najgori rezultat.
m1 arj 849998 Arj -m1 *NE DAJE* isti rezultat kao default!
jmm1 arj 849514 Arj -jm -m1 i ...
m1jm arj 849514 ... arj -m1 -jm daju iste rezultate.
jm arj 849512 Samo -jm, najbolja kompresija.
Bio si u pravu! Arhivirao sam data dir iz sor-a, i razlike su
po dva bajta, ali mislim da bi odnos bio isti i na nekim drugim
podacima - ako neko ima vremena nek isproba. Posebno je cudno
sto arj bez prekidaca i arj -m1 ne daju iste rezultate.
Zanimljivo za testiranje, zao mi je sto nemam vise vremena...
arhiveri.792ssokorac,
-> #782, ppekovic ─┼┤ Kao źto rekoh dati rezultati su dobijeni sa -m1 -jm.
─┼┤ Dakle, nema greźke :)
Probaj pkzip -ex -e0, isti efekat ;).
─┼┤ stavljanju novog ZIP-a u listu arhivera. A kad ęe ARJ? :)
Kad Sezam bude ostavljao dovoljno memorije da ozbiljan arhiver radi. ;)
P.S. Sorry źto je proźla poruka bila malo suviźe svadjalaŽka, ali dobio sam
2 iz Algebre :) :(.
arhiveri.793ssokorac,
-> #745, ppekovic ─┼┤ Da izbrojim switch-eve? Kakve to veze ima sa brzinom i
─┼┤ stepenom kompresije.
Nikakve, samo sam, nabrojao 2 prednosti arj-a. Za to si me i pitao. O
brzini, zipu svaka Žast, kompresiju ipak ne moramo ni da spominjemo, razlika
je viźe nego zanemarljiva...
arhiveri.794ssokorac,
-> #783, ppekovic ─┼┤ Ajde da je to rekao neki laik ali ti? Pa znaź i sam da
─┼┤ kad praviź program kojem je osnovni cilj da bude źto manji,
─┼┤ da ęeź prvo da izbaciź raznorazne provere.
▒ta ęe mi mali program koji ęe svaki drugi put da mi blokira
kompjuter/obriźe podatke/neźto sliŽno?
arhiveri.795dnikolic,
-> #765, banex>> verziji) se vrlo lako mogao povratiti sadrzaj svih spakovanih
>> datoteka osim (uglavnom) jedne koju nije mogao povratiti zbog
Znam za zipov PKZIPFIX, ali ne znam kako da ispovracam ostecenu ARJ arhivu?
dn
arhiveri.796dejanr,
-> #794, ssokorac>> ▒ta ęe mi mali program koji ęe svaki drugi put da mi blokira
>> kompjuter/obriźe podatke/neźto sliŽno?
Pa, niko te ne tera da ga koristiź. Imaź "pun" ZIP2EXE, koji nema nikakve
probleme. Ako neko hoęe "male" EXE fajlove, i spreman je da ih koristi
jedino za raspakivanje u tekuęi direktorijum i tako to, ima i SFXjr.
arhiveri.797peca.st,
-> #782, ppekovic!-> Kao źto rekoh dati rezultati su dobijeni
!-> sa -m1 -jm. Dakle, nema greźke :)
Ja teoretski, a dusanP praktiŽno, dokazao da ima greźke.
Pe¬a.
arhiveri.798dejanr,
-> #795, dnikolic>> Znam za zipov PKZIPFIX, ali ne znam kako da ispovracam ostecenu ARJ arhivu?
MoČda je jedina komanda za rad sa oźteęenim ARJ arhivama DEL ;>
▒alu na stranu, imaź ARJ e -jr, radi sliŽno źto i PKZIPFIX - rekonstruiźe
koliko moČe.
arhiveri.799banex,
-> #781, ppekovic>> specijalna filosofija. Ako te zanima poslaęu ti opise
>> struktura ARJ i ZIP fajli.
Za zip si mi veę poslao, mogao bi i za arj pa da kompletiram :)
arhiveri.800janko,
-> #763, adzem> Uh, uh, mnogo gnjavaČe. Poźto u firmi imam pristup na viźe
> raŽunara, morao bih to da ęuźnem u svaki AUTOEXEC, a onda
> se pojavi neko ko je "źef" na tom raŽunaru i to izbriźe,
> pa me opet doŽeka jedno "Disk full". Za po kuęi to moČe da
> pro¬e, ali je mnogo jednostavnije kori- stiti ARJ. :)
MoČda ne bi morao? PKZIP Žita konfiguraciju iz DATOTEKE, a
PKUNZIP iz env. romenljive. Probaj?
arhiveri.801mbole,
-> #774, peca.st> Meni i nije. :( Ne seęam se da je ikad uspeo da potpuno oporavi
> arhivu, Žak i ako je u njoj bila samo jedna datoteka.
Pa vidiź, "popravljanje" kod svih arhivera radi tako źto povadi iz
arhive sve neoźteęeno. To znaŽi da ako u oźteęenoj arhivi postoji samo
jedna datoteka, i ona mora biti oźteęena nakon fix-a. Ako ih ima viźe
(recimo da je samo jedna od njih zeznuta), fix ęe povratiti sve ostale u
potpunosti, a tu jednu kolko je god moguęe (onaj oźteęen deo ne moČe nikako
ni da se povrati).
arhiveri.802ppekovic,
-> #770, dexi>> Kod mene je najbolja kompresija bila sa -jm bez -m1 !?
;)) To je iz razloga źto je -m1 default :)))
Paya
arhiveri.803ppekovic,
-> #772, peca.st>> !-> bio je ukljuŽen i -jm switch.
>>
>> Nisam siguran, ali moguęe je da ono -m1 ako ga staviź u liniju
;))))))))) E stvarno si ma razveselio. Ja jesam siguran da
sam stavio -jm jer sam JA! radio testove. A sad ako mi ne verujeź,
onda lepo sam napravi testove. Par minuta posla.
Paya
arhiveri.804ppekovic,
-> #777, mbole>>> P.S. ZIP je standardni arhiver na Sezamu. ARJ-a nema na sezamu
>>> :)
>>
>> Jel se ti to źaliź ili stvarno odavno nisi bacio pogled u neki
>> direktorijum.
Govorimo o set archiver.
Paya
arhiveri.805ppekovic,
-> #775, spantic>> Pitamo o sigurnosti PKZIP 2.X? Xa! Evo pogledajte źta mi je javio prilikom
>> raspakivanja fajla koji je spakovan i raspakivan na goloj maźini, bez
ikakvih
>> rezidentnih programa i bilo Žega.
A na osnovu Žega moČeź da tvrdiź da je ZIP zeznuo stvar? Loźi
sektori, ukrźteni fajlovi, źteker? ;)
Paya
arhiveri.806peca,
Evo moga iskustva - ja koristim pkzip,uglavnom za ovo
arhiviranje oko Sezama.Medjutim sada sam dosao sa puta
i sacekame pismo od jednog kolege iz Pirota,koji mu je
poslao neke diskete sa projeknom dokumentacijom.Sedam
BASF disketa od 1.2 megabajta,na dve je ta dokumentacija
a na ostalima neki softver,igrice,sta li je.Ja skinem
ovaj ARJ sa Sezama, i pustim kad ono svaka svakcijata
disketa mi javi bad hufman kod i nista!Ja sam tu malo
popizdeo jer mi to treba za ponedeljak da se stampa,
zovem coveka telefonom a on mi kaze jao zaboravio sam
da iskljucim neki cech program i to onda uvek bude
tako.Rezultat evo danas covek dolazi iz Pirota da to
donese a ja uranio da idem na stanicu da ga cekam.
Taj ARJ sto tako radi(sve i ako su to posle ispravili)
ne bi koristio ni za sta pa da mi placaju posle takvoga
iskustva.A i ovaj Pirocanac ima da ga bachi, muka ga
ufatila sto je morao kartu da kupuje, znate vec kakvi
su Pirocanci :))
PECA
arhiveri.807zkrstic,
-> #794, ssokorac> ▒ta ęe mi mali program koji ęe svaki drugi put da mi blokira
> kompjuter/obriźe podatke/neźto sliŽno?
U mom stilu:
- Da ti Žini Čivot dinamiŽnijim i razbija monotoniju ;)
- Da imaź źta da daź, bez obzira na CopyRight tkzv. "prijateljima" ;)
Zkr ;)
arhiveri.808dgrbic,
-> #780, djelovic:: Not so. Algoritam je, naravno, najvaČniji, ali je ovde
:: potrebna i Žista sila :). Viźe memorije omoguęuje
:: modeliranje veęeg reda, tj.
Hm, da...
Ali, da bi program radio jednako (te da bi mogao i da raspakuje jednako) i
na raŽunaru sa 3 Mega i sa 300 k slobodne memorije, mora se raŽunati na
gori sluŽaj.
Pa se za tabele koristi uvek ista memorija (npr. 16k) a ostalo za bafere i
sliŽno, Žisto radi izbegavanja muljanja po disku kad ne mora (pravljenje
.tmp fajlova i sliŽno).
arhiveri.809isekulovic,
-> #778, mbole>> na disk za razliku od zip-a. He sad mi pade na pamet. Joź mi se nije
>> desilo al ako bi napunio hard, dal bi mi traČio da "ubacim" sledeęi
>> ;))))
Ispisuje iste poruke kao i za diskete. Pita da li da nastavi
sa sledeęim delom/disketom i ako se odgovori potvrdno kaČe da nema
dovoljno prostora na disku.
arhiveri.811darone,
-> #791, dusanp>> podacima - ako neko ima vremena nek isproba.
>> Posebno je cudno sto arj bez prekidaca i arj -m1
>> ne daju iste rezultate. Zanimljivo za
>> testiranje, zao mi je sto nemam vise vremena...
Eh, da, to je ona arjova boljka źto ponekad u dva
arhiviranja koja su izvedena na istoj maźini, pod
istim uslovima, u razmaku od po pet minuta, napravi
dve razliŽite arhive (razlika se ogleda u duČini, i
to za par bajtova).
darone
arhiveri.812mjova,
da se malo nadoveČem na diskusiju o arhiverima: meni stvarno nije
poźlo za rukom da zip daje iskljuŽivo bolje rezultate u pakovanju kako
neki ovde napraviźe. doduźe, meni je potreban samo pkunzip ;), ali
opet, morao sam da probam pakovanje zip-om. evo źta je rearj zabeleČio
u log (oba su imala maksimalne kompresije):
1) pretpostavljam da je sve bilo spakovano starim zipom, pa sam
prebacio u arj (239d):
11:08:52 ARJ Old size New size Savings Original name
11:09:45 ARJ 150459 132217 18242 C:\WORK\ACTLIB11.ZIP
11:10:29 ARJ 248945 223666 25279 C:\WORK\HLPDK20.ZIP
11:11:20 ARJ 259691 218497 41194 C:\WORK\HTEX071.ZIP
11:11:26 ARJ 28232 26097 2135 C:\WORK\LINGU11A.ZIP
11:13:05 ARJ 348145 304071 44074 C:\WORK\SNIP1292.ZIP
11:13:09 ARJ 1035472 904548 130924
2) i tu nije bilo dvosmislenih rezultata ;), a onda sam prebacio u
novi zip:
11:16:27 ZIP Old size New size Savings Original name
11:17:08 ZIP 132217 132519 -302 C:\WORK\T\ACTLIB11.ARJ
11:17:49 ZIP 223666 221742 1924 C:\WORK\T\HLPDK20.ARJ
11:18:41 ZIP 218497 215651 2846 C:\WORK\T\HTEX071.ARJ
11:18:46 ZIP 26097 26837 -740 C:\WORK\T\LINGU11A.ARJ
11:19:58 ZIP 304071 314130 -10059 C:\WORK\T\SNIP1292.ARJ
11:20:02 ZIP 904548 910879 -6331
kako se vidi, arj je *uźio* zip za 10059 bajtięa na poznatom paketu
koji se sastoji uglavnom od c koda, a na ostalim su bili pribliČni,
ako ne raŽunamo dva paketa koja se sastoje od nekoliko exe-a.
mislim da je bezpredmetno priŽati źta je bolje a źta ne - kod mene je
zip zaista brČi od arj-a, nema priŽe, ali 1) navika, 2) obimnost
arj-a, 3) brdo, ogromno brdo, parametara, 4) arj je najbolji ;).
arhiveri.813bulaja,
-> #782, ppekovic│Tacno, s tim sto znas i samda se razmislja o stavljanju
│novog ZIP-a u listu arhivera.
└───
A znas li zasto jos nema novog ZIP-a tamo? Jer nije
dovoljno pouzdan! :)) (ovo nisu moje reci)
arhiveri.814bulaja,
-> #783, ppekovic││Jos jedan BUG :) PKSFXjr modula u ZIP-u 2.04 - ukoliko je SFX
││arhiva ostecena to vam SFX nece ispisati - zaglavice se :).
│└───
│Ajde da je to rekao neki laik ali ti? Pa znas i sam da kad pravis
│program kojem je osnovni cilj da bude sto manji, da ces prvo da
│izbacis raznorazne provere.
└───
Mozes da branis ZIP koliko hoces, ali ipak priznaj da je ZIP2EXEjr trash. :)
Pa koji ce mi kratak program ako ne radi nista, ima bugove i stalno se
zaglavljuje? For your info, jrSFX ima u sebi poruke poput "Error in
ZIP", "file falis CRC check" i sl. Izgleda da mu nicemu i ne sluze. Meni
se desilo da se ostecena arhiva zaglavi, a moglo je da bude i mnogo
ozbiljnije - da kao otpakuje osteceni file i ne javi gresku a ti si
ubedjen da je sve Ok.
arhiveri.815dejanr,
-> #813, bulaja>> A znas li zasto jos nema novog ZIP-a tamo? Jer nije
>> dovoljno pouzdan! :)) (ovo nisu moje reci)
Nisu tvoje, ali zbilja ne znam Žije su. Nije na listi zato
źto se joź nije potvrdio kao dovoljno pouzdan. Treba vremena
da se eventualni problemi pokaČu. Za sada mi ZIP204g izgleda
sasvim pouzdano, u smislu da meni nikakav problem nije
napravio. Doduźe, i dalje redovno kucam PKUNZIP -t *
arhiveri.816bearboy,
-> #751, darone║>> u tekuęoj verziji 2.04e.
║
║ Ipravka: tekuęa verzija ja 2.04g.
Opet novo ? Sta li ęe gos'n Kac uraditi kad mu ponestanu slova i brojke ? :)
arhiveri.817bearboy,
-> #765, banex║ sa arj-om v2.93a koje sam prebacio u zip v2.04g. Iako rezultati
Dal' bi mogao da ' pozajmiź tu 2.93 verziju ?