19 éve lapuló kódfuttatási sebezhetőséget találtak a WinRAR-ban

Titkosítás, biztonság, privát szféra

Több száz millióan érintettek a hibában. Részletek itt.

( uid_16313 | 2019. 02. 21., cs – 14:26 )

Szóval biztonságos volt 19 évig, mivel kutya sem tudott róla kb.

--
robyboy

Vagy nem használták. A zip egy kényelmes általános tömörítés, ha viszont tényleg tömöríteni akarunk, akkor az LZMA jobb.

Szerintem a rar már nem oszt, nem szoroz.

Valaki emlékszik még az arj-re (régen az volt a menő)? Na abban is kereshetik a sebezhetőségeket, az sem fog érdekelni.

Én még vmi ACE tömörítésre is emlékszem 2000 környékén. A Total Commanderben (akkor még Windows Commander) volt rá beépülő pluginom is :)

Amúgy én ma is használom a WinRAR-t. Ugyanis .iso fileok kicsomagolására még mindig ez a legjobb. Vagy hát nem tudom ki mit használ .iso fileok kicsomagolására...

TC nem nyitja meg? Lehet, hogy valami plugin is kell hozza, de szerintem bele tudsz menni.
Amugy mount -o loop.

szerk: marmint az iso-ra, ace-t reg lattam mar

--
When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin

> Én még vmi ACE tömörítésre is emlékszem 2000 környékén.

Valójában a topicindító sebezhetőség is a Winrar ACE fájlok kezelésében van.

> Vagy hát nem tudom ki mit használ .iso fileok kicsomagolására...

jobbklikk > mount (Windows 8 óta a Windows alapból támogatja az iso fájlok mountolását)

iso fájlok kicsomagolása:
pár éve még az mc sima rákattintással lazán belemászott, de aztán elbasztak benne valamit, és most összevisszaságokat ad...

ez viszont (még) működik:

mkdir valami; mount -o loop valami.iso ./valami;
aztán már csak be kell mászni a "valami"-be...

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.

( carlcolt | 2019. 02. 21., cs – 14:32 )

Hadd talaljam ki: nem futott le a 40 napos trial idoszak vegen a tilto kod. :P

( uid_17784 | 2019. 02. 21., cs – 15:14 )

Sosem ertettem, hogy minek kell ezt a programot feltelepiteni.

(Amikor uzemeltettem, es szolt a titkarno v. vig. asszisztens, hogy kapott egy rart, akkor mondtam neki, hogy szoljon a kuldonek, hogy Windowst hasznalunk; kuldjek zippen, ha azt akarják, hogy ki tudjuk bontani.)

A torrent ellenőrzi a letöltött fájlok állapotát, viszont ahol még FTP megy (jellemzően teljesen privát megosztások), ott még lehet értelme. Azért sok BlueRay ISO letöltését a legtöbb gyors net is megérzi. Illetve csomagolva bármikor ellenőrizheted offline is a fájlok állapotát, bár erre vannak más, tömörítés nélküli megoldások is.
Ettől függetlenül én is feleslegesnek gondolom.

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

Igen, ezt mondtam, csak nem akartam így direktben leírni. Viszont az integritás-kezeléshez számtalan más eszköz is elérhető, nem biztos, hogy egy tömörítőprogram a legjobb megoldás.

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

Nagyon úgy tűnik, hogy a feladatra rossz eszközt használnak, aminek a hiányosságát egy további rossz eszközel próbálják pótolni.

Rossz eszköz az FTP, mert nem képes megbízható fájlátvitelt biztosítani.
Rossz eszköz a RAR, mert feleslegesen és eredménytelenül tömörít, ráadásul nem is az a cél.

Ironikus módon pont a torrent alkalmas leginkább a feladatra.

A rar tud "store" módon, tömörítés nélkül csak tárolni és és darabolni. Ez egy kényelmes, egyéb segédprogram nélküli darabolás+crc ellenőrzésre teljesen jó.

Az igazán ostoba felhasználás a split+crc, amikor a crc a teljes állományra értelmezett. Így pont arra nem jó, hogy pl. a 20 darabra vágott cucc 13. szeletében detektált hiba miatt csak azt tötsem le újra. ;)

A torrentnek meg lehetne olyan opciója, amikor nem torrentet készít, hanem darabol és crc-t készít. (Talán van, csak soha nem használtam.)

btw az így kiadott és darabolt release-ek minden esetben csak tömörítés nélkül készülhetnek, így teljesen mindegy a tömörítés eredményessége (gyakorlatilag csak a rar header kerül bele), csak a darabolás számít.

a crc check mellett van még egy fontos szerepe: ilyen módon sokkal gyorsabban terjedhetnek kiadott release-ek, mert különböző fájlok egyszerre töltődhetnek különböző forrásból.

Elvileg technikailag a torrent alkalmas lehetne a leváltására, de privacy szempontból problémás lenne, a hatékonyság valószínű csökkenne, illetve ez egy hierarchikusan felépített rendszer, így torrent-nél magasabb szintű kontrolra van szükség.

Pl. en. Kenyelmes, sokat ki tud bontani, megadom neki a jelszot meg hany file/mekkora meret legyen es kesz.

vagyis...TC-n hasznalom, de az ebben levo "rar.exe"-t hivja a tc.

Azon tunodok, 7zip az ami olyan iszonyat lassu Linuxon? Mar legalabbis tar.gz-hez kepest. Vagy mas ?

--
http://www.micros~1
Rekurzió: lásd rekurzió.

A 7zip sebessege beallitasfuggo. Viszont azonos sebesseg mellett jobban tomorit, es ha nem sajnalod a prociidot, akkor sokkal tomorebb lesz a vegeredmeny.

--
When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin

Nem tudom, utoljara mikor tomoritettem be merheto meretu (ertsd, gigas nagysagrendu) fileokat.
Kitomoritesnel tunt fel az eszveszto lassusas a 7z-nel. mondjuk, szamomra a bzipnel is. Zavaro volt, hoyg 2%-ot nyerunk a tomoritesen (mikozben a szukseges hely ezerszerese rendelkezesre all), cserebe rohadt lassu a kitomorites, ha kell.

Szoval nekem tovabbra is a tar.gz meg a rar a favorit.

--
http://www.micros~1
Rekurzió: lásd rekurzió.

Eleg gyakran elofordul, foleg archivalaskor, illetve amikor nagy mennyisegu, jol tomoritheto adatrol van szo. Kb. 2 hete futott le (automatikusan) 7GB nyers adatbol lett 5MB (reszvenyarfolyamok html-ben, az informaciotartalma nem sok, de szeretem eltenni az eredetit is). Elozoleg meg amit kezzel futtattam, 40GB-bol lett <2GB. Utobbi raadasul a laptopomon kell, es a Linux egy 256GB-os particion van. (neuronok mezopotencialja, szinten jol tomoritheto, foleg, hogy a legtobb csatornan nincs ertelmes jel)

A legtobb esetben persze azert csomagolok ossze dolgokat, hogy egyben lehessen kezelni (pl. kilinkelek valakinek par doksit). Ilyenkor mindegy a meret, ezert zipet szoktam hasznalni, mert minden kezeli.

--
When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin

Archivalas ? Egyszeru gzip. Backupra meg ott a Bacula, sztem az is gzip-et hasznal.

Lehetne persze bzip2 is, fonokom azt hasznalta, csak nem ertettem, miert. Hajnalban futott, szoval nem evett idot. Viszotn a kibontasa az nem automata volt, csak akkor, ha nekem kellett - es rohadt lassu volt.

gzip nagyszeruen tomorit pl. sql dumpokat. Lehet, hogy 10M helyett 9M lenne bzip2-vel a gigas filebol, de a kibontasa gyilkos.
--
http://www.micros~1
Rekurzió: lásd rekurzió.

Engem egyszer megkért egy indiai jómunkáskóder, hogy telepítsek a windows-os jenkins agentre egy winrart neki, mert a pipelineban meg akarja hívni, hogy zip fájlokat hozzon létre. Inkább adtam neki egy oneliner powershellt ami megcsinálja a melót :)

--
arch,ubuntu,windows,libreelec,omnirom,microg
zbook/elitebook/rpi3/motog4_athene

WinZIP felett a Corel "bábáskodik", ha kifizette az ügyfél a licenceket, akkor biztos lehet, hogy nem lesznek a használata miatt jogi problémái. (Ha minden kliensen vele tömörít be, akkor a kitömörítésnél a nem Corel-t használók lehet hogy elvéreznek. - Ennek is lehet előnye.) - Mostanában nem néztem a Corel WinZip-fejlesztés állapotát, - ha nem elég a TC, - keretrendszerként PeaZip-et használok.

(Egyszer kaptunk külföldről egy zip formátumban csomagolt anyagot, semmi más nem bontotta ki, csak a Corel WinZip-je.)

Bármibe fogadnék, hogy azt a más által kicsomagolt anyagot a Corel WinZip-je kreálta. Régi szép idők, utoljára Win98-on használtam WinZip-et.

Pont ez a bajuk a fizetős tömörítőknek, sokszor nem szabványos archívumokat állítanak elő. Már csak azért is érdemes őket kerülni.

No keyboard detected... Press F1 to run the SETUP

Ez egy szerver oldali alkalmazás, csak sokan nem tudják! :-)

Legalábbis Cirka 15-20 évvel ezelőtt a windowsos file megosztásról ezzel csináltam inkrementálist mentést, hajnalban egy script lefutott, és megparaméterezve a winrar.exe -t, az szépen összevadászta az összes archive bittel rendelkező állományt, betömörítette, és clearelte az archive bitet.
Sok évig működött hiba nélkül. Nesze neked, drága mentő rendszerek...

BTW, a 7zip az valójában nem egy átnevezett/elforkolt rar formátum?
Én valahogy mindig ugyanabba a skatulyába helyeztem a fejemben: a zip az egyszerű, a rar/7zip meg a jó tömör formátum. Szerintem.

Van Linuxra is, mert a kitömörítése nyílt forráskódú, ezért csak unrar, libunrar formájában létezik. Betömörítő is van hozzá, de azt csak zárt forráskóddal, fizetős binárisként terjesztve. Az sem a winrar változat, hanem a „sima” terminálos rar.

No keyboard detected... Press F1 to run the SETUP

( zrubi v | 2019. 02. 21., cs – 18:56 )

amióta 7-zip létezik, ez és a többi hasonló shareware "szemét" teljesen értelmetlen.
én azon lepődtem meg, hogy ez még egy élő projekt, nem azon hogy bugos :)

--
zrubi.hu

Pedig van előnye a rar-nak. Pl. ez kezeli legjobban a darabolt archívumokat (ki tud csomagolni belőlük önállóan, az előttük lévő archívumszeletek nélkül), meg tud hibás archívumot javítani. Sokan a felhasználói felületét is szeretik, mert szép színes, nagy ikonos, igaz ez szubjektív.

De én sem állhattam ki soha. Windows alatt előbb Total Commanderrel bontogattam, csomagoltam, teszteltem a tömörítvényeket, aztán Double Commanderrel, és leginkább 7z-t használtam formátumnak. Linux alatt Double Commanderrel, most Vifm-mel (igaz a betömörítésre még nem találtam ki kényelmes metódust alatta). Linuxra van unrar és libunrar is, igaz ez egy csomó fent is említett funkciót nem tud (a betömörítésen kívül is), amit a windowsos kereskedelmi változat igen.

De az biztos, hogy az egész formátumnak nem sok létjogosultsága van. Az LZMA jobban tömörít, és sok ingyenes tömörítő pedig erősebb titkosítást tud a rar-nál. Régen menő volt a fájlkezelős része miatt, meg elsők között kezelte a solid tömörítést, titkosítást, stb., de ezeket ma már ingyenes alternatívák is tudják. Már az archívumok szeletelése sem divat. Elment mellette az idő.

Azzal is egyetértek, hogy a WinRAR-t sokan az átlag felhasználók közül csak rossz beidegződés miatt teszik fel. Emlékszek egyszer takarítottam egy felhasználó windowsos telepítését, mert már lassú volt, panaszkodott rá. Persze mielőtt kipusztítottam róla a sallangot, mindegyikről megkérdeztem mire kell neki. A legtöbbről azt sem tudta mi, meg nem is használta, de a WinRAR-nál is csak annyira emlékezett, hogy egyszer kellett neki valamihez, de nem használja. Azért sok értelme volt feltenni.

No keyboard detected... Press F1 to run the SETUP

( hokuszpk | 2019. 02. 21., cs – 19:51 )

winrar konyvtarbol unacev2.dll kiradiroz, problem solved.

--
HUP te Zsiga !

( hunludvig v | 2019. 02. 22., p – 05:57 )

Ezek után azon lepődtem volna meg, ha nincs benne.

( perretz | 2019. 02. 22., p – 07:07 )

A románok nagyon használják még most is. Gyakran kell csatlakozzak TeamViewer-en, román kollégák gépeire, szinte kivétel nélkül mind használják a WinRar-t, főleg zip-ek csomagolására.

Nana, a románokat nem bántani! Ők igenis egy decens nép, ősi latin kultúrával, és jó szomszédaink, akikre méltán lehetünk büszkék :D Nem kell itt semmilyen Tiranont revidiálgatni, oda kéne nekik inkább adni a többit is, Budapest-Győr-Zalaegerszegig végig, hadd csináljanak abból is fain roma-lepra telepeket. A WinRar csak segíthet rajtuk.

No keyboard detected... Press F1 to run the SETUP

( uid_21225 | 2019. 02. 22., p – 08:29 )

Ahogy én látom, Windows alatt a zip, Linux alatt meg a tar.gz (lassan a tar.xz?) a "de facto" sztenderd, a mai sáv széllesség meg tárhely méretek mellett a "hozzáférhetőség" szerintem sokkal fontosabb, mint néhány megtakarított kilobyte.

Sima szöveges fileok (logok...) tömörítésére az xz mindenképpen jobb.
Részlet egy mérés beszámolóból:

[...]
A mérési eredmények a syslog-ng átalakítás projekt doksijából:
-------------------------------------------
== A logok tömörítése legyen effektívebb ==

A jelenlegi "gzip" helyett az "xz" tömörítő program használatával érhető el ez a cél.

A mérések szerint, a tömörítést és az időt is figyelembe véve, a jelenlegi "gzip -9" helyett az "xz -1" használata javasolt.

- - - - - - - - - - - - - - - - - - -
=== gzip és xz mérési jegyzőkönyv ===

- Egy CPU magot használ mindegyik
- A test file mérete 3.923.755.980 byte
- kipróbálásra került egy extrém tömör tömörítési beállítás is, de nem éri meg az elért tömörség az időráfordítás mértékét.

Method Out size % Time Sec Command
gzip -9 310454705 100 1:47 107 gzip -9 -c /logs/testlog.txt > /logs/testlog.gz
xz max 93183256 30.0 189:14 11354 xz -9 -e --lzma2=dict=1536Mi,nice=273 -c /logs/testlog.txt > /logs/testlog_opt.xz
xz -9 145404504 46.8 25:27 1527 xz -9 -c /logs/testlog.txt > /logs/testlog-9.xz
xz -8 144896528 46.6 22:19 1339 xz -8 -c /logs/testlog.txt > /logs/testlog-8.xz
xz -7 143828268 46,3 20:45 1245 xz -7 -c /logs/testlog.txt > /logs/testlog-7.xz
xz -6 142471584 45.8 19:57 1197 xz -6 -c /logs/testlog.txt > /logs/testlog-6.xz
xz -5 152219500 49.0 9:27 567 xz -5 -c /logs/testlog.txt > /logs/testlog-5.xz
xz -4 150609556 48.5 9:16 556 xz -4 -c /logs/testlog.txt > /logs/testlog-4.xz
xz -3 148214596 47.7 9:07 547 xz -3 -c /logs/testlog.txt > /logs/testlog-3.xz
xz -2 144993152 46.7 1:49 109 xz -2 -c /logs/testlog.txt > /logs/testlog-2.xz
xz -1 145222056 46.7 1:31 91 xz -1 -c /logs/testlog.txt > /logs/testlog-1.xz
xz -0 158112176 50.9 1:25 85 xz -0 -c /logs/testlog.txt > /logs/testlog-0.xz

[...]

Magyarán egy cirka 4 gigás text file esetében a gzip -9 tömörítéshez képest az xz -1 picit több mint kétszer olyan jól csomagol és még gyorsabb is.

( szilard_ v | 2019. 02. 22., p – 09:00 )

Engem meglepett itt ez a nagy RAR ellenesség.
Én szinte csak ezt használom, illetve 7-zip porosodik valahol ha mégis kellene tíz évente egyszer.

Maga a RAR egy indokolatlan faszság. Mindenki csak azért tart valami rar-képes tömörítőt, mert
- amúgy minden értelmesebb másikat kezeli
- hátha 10 évente valamelyik pistike úgy teszi fel a sorozatot / filmet ncoremoziba, hogy rarozik egyet rajta

--
arch,ubuntu,windows,android
zbook/elitebook/rpi3/p9_lite

Az nCore-on jó ideje tiltott a tömörített mozi feltétele. Régen is csak eredeti release-eknél volt megengedett, de jó ideje az sem. Pont azért, hogy ne kelljen becsomagolt szemetet tárolnia senkinek a gépen, amit megnézéskor még ki is kell bontogatni.

Amit én még régen nagyon utáltam, azok az mds/mdf/nrg lemezképek, az Alcohol és a Nero formátumai, azok is zárt szarok a standard .iso helyett.

No keyboard detected... Press F1 to run the SETUP

Az mds/mdf/nrg legalabb - bizonyos esetekben - indokolhato. Par kiado azt hasznalta masolasvedelemnek, hogy szandekosan rosszul olvashato reszt tett a CD-re/DVD-re. Ha a futo program nem tudja olvasni, akkor eredeti a lemez, es fut. Ezt az olvashatatlan reszt az Alcohol (es gondolom a Nero) le tudta kezelni, az isoban meg - tudtommal - nincs ilyen tamogatas, ott csak a nyers bitek vannak, ezert is tudod egy sima dd-vel letrehozni.

--
When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin

Nem faszság. Nagyon sokoldalú tömörítőformátum.

Hozzá képest a tar.gz egy faszság, mert mindig ki kell tömörítened a benne lévő tar-t (bloat), hogy egy-egy fájlhoz hozzáférj. Sőt azt sem tudod megmondani, hogy bizonyos fájlokat (jpeg, mp3 stb.) tömörítés nélkül tároljon, hogy ne pocsékold rá el a CPU-t ki- és becsomagoláskor. Fix méretű szeletekre darabolásról (r00, r01 stb.), recovery lehetőségekről nem is beszélve (sérülés esetén).

A Pistikézésből, illetve a torrentezők és az nCore felhasználók sértegetéséből pedig jó lenne visszavenned. Még akkor is, ha mérnök uraságod hűdeatombecsületestámogatomafilmkészítőketjanemcsakapénzéhesstreamingszolgáltatót mámorban ég a jelenleg tomboló, nagy konzumidióta HBO GO - Netflix őrületben.

Mi a bloat a tar-ban? Igazából a tar.gz király, mert két program remek együttműködése. Mindegyik azt tudja, amit neki kell, a tar összefog, a gzip tömörít. És van olyan, amikor pusztán a tar-ra van csak szükség, pl. nemrég futottam bele egy ilyen szalagos mentésbe.

De ez mind egyértelmű lenne neked, ha nem lennél troll.

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

Nincs vele baj, csak nem tud annyit, mint a RAR. Se a tar, se a gzip, se együtt a kettő. Arra való a tar és a gzip is, amire valók, együtt is tudnak működni, de csak alapszinten. Más kérdés, hogy a RAR mindkettőt ki tudja váltani out-of-the-box. Csakhát nem illik bele a FOSS ökoszisztémába, ami meg a proprietary licenc és a zárt forrás miatt érthető.

"The command line utility was first introduced in the seventh edition of unix (v7) in January 1979, replacing the tp program." link
Bloat a 70-es evekbol. Gratulalok.
De egy MFC-s (akkor mar miert is nem GDI+winapis?), temazhato alkalmazas az nem bloat.

--
When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin

Hagyd csak, látszik hogy fingja sincs se a tar-ról se a gzip -ről.
Próbálj meg egy néhány gigás tar.gz-ből (vagy tar.xz-ből, pl. a texlive-texmf forrás) néhány darab fájlt kinyerni. Ehhez először ki kell nyerni a tar-fájlt (azaz kitömöríteni az egészet), amit utána végigolvasgatsz, és kiszeded belőle azt a néhány fájlt, ami kell.
Amennyire tudom (vagy emlékszem még a régi DOS-os időkre), az ilyen művelet rar esetében gyorsabb, mert nem olvassa és tömöríti ki az egészet.

Van olyan tomoritesi eljaras, ami tobbe-kevesbe kulon kezeli a filejaidat, ilyenkor kulon kinyerheto. Van, ami egyben (ez lenne a "solid" modszer), ilyenkor sok hasonlo file-bol joval kisebb eredmenyt kapsz, mert fel tudja hasznalni hozza a tobbit is. Civilizalt tomoritok a ketto kozt egy kapcsoloval tudnak valtani (7zipnel pl. -ms=on). Sokszor a tomorites sebessege/aranya is egy skalan allithato. A .tar.gz a jellegebol (2 program osszekotve) - es korabol - adodoan csak a solidot tudja.

--
When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin

Csakhogy nem a 7Zip vs. RAR volt a téma, hanem a tar.gz vs RAR. Persze, mikor ráeszmél fősodratú mérnök uraságod önnön felsülésére, akkor máris nekiáll csúsztatni.

Más kérdés, hogy nincs igazából olyan tömörítési scenario, amit ne tudnál rarral legalább olyan jól (vagy még jobban) megvalósítani, mint tarral és a gzippel, együtt vagy külön. Tehát, még az sem kifogás, hogy két külön tool.

Tüneményes, amikor egy DOS - Windows guru fikázza a tgz-t. Hát még akkor, amikor igaza is van. :-D
Sajnos a Windows 10-ig nem sikerült olyan rendszert csinálni, ami a fork() hívást támogatja. Így aztán kénytelen vagy ilyen marhaságokra hivatkozni: először ki kell nyerni a tar-fájlt (azaz kitömöríteni az egészet), amit utána végigolvasgatsz, és kiszeded belőle azt a néhány fájlt, ami kell

Szóval döbbenetesen igazad van, mert ezidáig nem készült olyan alkalmazás, amely nem *nix környezetben minden esetben ki tud bontani egy tgz-t. Kívételt képeznek azok az entitások, ahol megírták a fork() emulációját. Pl.: cygwin, Windows 10 - ubuntu shell.

Ugyanitt kölcsönvenném a floppidat. :-D
Ha már a DOS-s időkre hivatkozol.
A mai időkben mag a tgz formátumnak kismillió előnye van, amit a rar sose fog tudni. Mert ugye annak is lehet némi hátránya, hogy mindig a diszkre kell írni, mert csak ott tudsz seekelni!

Szomorúan olvastam a feljebb szólókat. Ha valamit 0,01% méretűre lehet tömöríteni, ott már semminek semmi köze a tömörítőhöz. Inkább adattárolás alkalmatlan formátumban. ;)

Tüneményes, amikor egy DOS - Windows guru fikázza a tgz-t.
Ha rám céloztál, mellélőttél. Nem vagyok se DOS, se Windows-guru, és még a tgz-t sem fikáztam.
Csak Gyuszknak írtam, hogy hajbazer (szerintem) mire gondolt, nem fikáztam se a tgz-t, se a tar-t.
Másrészt linuxos kitömörítésről beszéltem, nem windowsosról.

Ha valamit pontatlanul fogalmaztam, elnézést. Ha annyira pontatlan, hogy az már inkább tévedés, kérlek, javítsd ki. Talán Nyosigomboc hozzászólása jobban használ szakmai fogalmakat.

Bocsi, ha úgy tűnt kipécéztelek. Inkább csak egy "thread alá" hosszászólás akart lenni.
A guru viszont fifti-fifti. Egyrészt szól "feljebb is", de a konkrét oka az pont a kitömörítés volt. Mint írtam, ez a fork() hiánya miatt van. De linux alatt??

Valahogy így kellene előszedni valamit: 

tar xzf tgzfile keresettfile

ami megegyezik a következővel 

gzip -dc tgzfile | tar xf - keresettfile

Ez ugyan kitömöríti, de minimális memória, diszk és cpu felhasználás mellett.

DOS/Windows alatt: 

gzip -dc tgzfile >tarfile
tar xf tarfile keresettfile

Ebben az esetben a tarfile kitömörítve a diszkre íródik, amivel időt és helyet fogyaszt. És mindez azért, mert nincsen fork().

A tar és a gzip is stream-ben képes dolgozni, hiszen a streamer is tape-et tartalmaz. ;) Ez hátrány lehet a seek képes kezeléshez. Kivétel manapság, amikor minden hálózaton van. 

ssh masikgep tar czf - file1 file2 ... >tgzfile

Itt a fentiekhez hasonlóan a másik gépen 0 a felesleges diszkművelet, alacsony memória és hálózat használattal, míg a cpu a tömörítés fokától és a hálózat sebességétől függhet.
Ehhez képest a rar csak lokális műveletet tud végezni.
Csak úgy megemlítem, hogy a tar alapértelmezett eszköze a /dev/rmt (==remote magnetic tape), azaz egyben hálózati archiváló eszköz, ami képes szalagegységgel együttműködni. (Ezért tud blokkolásra vonatkozó dolgokat is.)
Ezeket csak azért írom ide, mert a Hagyd csak, látszik hogy fingja sincs se a tar-ról se a gzip -ről. ellen kampányoltál. ;)
Szerintem a tgz és rar összvetése kb. olyan, mint szidni a helikoptert, amelyik az autó ellenében szarul úszik. :)

Engem megakadályoz az a tény, hogy nem szoktam Windows programokat írni. ;)
Ha biztos vagy a dolgodban, akkor igazán segíthetnél!
Keresem azt a programot, ami
- a tgz fájlt is kibontja egy lépésben,
- (GNU) tar kompatibilis (elegendő a kibontás),
- nem fizetős (ha csak fizetős van, akkor is kíváncsi vagyok),
- nem cygwin és nem ubuntu shell,
- akár lehet gui verzió is, de ez már csak extra funkció.

Kíváncsian várom a megoldást!

Elég gyenge próbálkozás. ;)
A teszt eset (a "-b 1" opció elhagyható): 

dd if=/dev/random of=file1 count=1000
dd if=/dev/random of=file2 count=100
tar -cz -b 1 -f tarfile.tgz file1
tar -cz -b 1 -f tarfile2.tgz file2
cat tarfile2.tgz >>tarfile.tgz
tar xzivf tarfile.tgz
file1
file2

A takarításokat nem kevertem ide. 

7z x -so tarfile.tgz |7z x -si -ttar
7-Zip 9.13 beta  Copyright (c) 1999-2010 Igor Pavlov  2010-04-15
Processing archive: tarfile.tgz
Extracting  tarfile.tar
7-Zip 9.13 beta  Copyright (c) 1999-2010 Igor Pavlov  2010-04-15
Processing archive:
Extracting  file1
Everything is Ok
Size:       512000
Compressed: 0
ERROR: A pipe használata befejeződött.

Mint látszik a file2 sehol sincs és ott egy hibaüzenet. Ugyanígy működik a GUI is, azzal az eltéréssel, hogy a file1 hosszától függően szintén hibát jelezhet. Ebben az esetben a file1 sem kerül elő.
A file1 file2 másként is összerakható lenne. De ez egy nagyobb rendszer apró részlete, és okkal csinálom pont így.
A windowsos fejlesztők meg egyszerűen megtagadták az olyan program használatát, ami nem színes és nem lehet kattintani. A műszaki megoldás: ki kell őket rúgni. :-D

Tehát nem kompatibils, mert nincs opció a teljes kifejtésre.

Csak az egyszerű eseteket kezeli az összes Windows alatt futó megoldás. Sőt a GNU utils statikusan fordított változatából is hiányzik néhány opció, tehát inkompatibilis.
Tipikus vagy sem, opció van hozzá, az rfc-k leírják, tehát a többi inkompatibilis.

Maga az "utólagos összefűzés" teljesen tipikus, hiszen ez egy tape archiver, márpedig a szalagra általában egymás után írogatsz. Ha végetért az adat, akkor a tar egy EOF blokkot ír, ami 20x512 bájtos blokk. Ezt szabályozhatod a -b n opcióval, de n mindig nagyobb, mint 0. Szalagnál pl. a tctl parancsal ugrabugrálhatsz, ilyenkor visszaléphetsz 20 blokkot és onnan lehet nekifutni a további írásnak. Ha nem akarod a szalagot koptatni, akkor ott a -i opció ami ignorálja az EOF-ot és megkeresi a következő ustar headert és folytatja a kifejtést.

Abban a felhasználásban a naaagy adatbázist hozom át hálózaton, közvetlenül a célfájlba. Amíg ez nem sikerült, addig nincs értelme a további műveleteknek. Ha már a diszken van az eredmény, csak akkor jön át a "pótfájl", ami hozzácsapódik a mentéshez - ami így lesz komplett.

Tar esetén ez még rendben is lehetne, bár a tar -r se egyszerű összefűzést csinál. De a gzip stream összefűzhetőségében egyáltalán nem vagyok meggyőződve. Mindenesetre a tar -r nem támogatja. 


$ tar -cvf test1.tar test1.txt
test1.txt
$ tar -cvf test2.tar test2.txt
test2.txt
$ cat test1.tar test2.tar > testcat.tar
$ cp test1.tar testtar.tar
$ tar -rvf testtar.tar test2.txt
test2.txt
$ tar -czvf test1.tgz test1.txt
test1.txt
$ tar -czvf test2.tgz test2.txt
test2.txt
$ cat test1.tgz test2.tgz > testcat.tgz
$ cp test1.tgz testtar.tgz
$ tar -rzvf testtar.tgz test2.txt
tar: Cannot update compressed archives
Try 'tar --help' or 'tar --usage' for more information.
$ ls -l
total 72
-rwxrwxrwx 1 baksa baksa 10240 Feb 28 13:21  test1.tar
-rwxrwxrwx 1 baksa baksa   149 Feb 28 13:39  test1.tgz
-rwxrwxrwx 1 baksa baksa    22 Feb 28 13:20  test1.txt
-rwxrwxrwx 1 baksa baksa 10240 Feb 28 13:22  test2.tar
-rwxrwxrwx 1 baksa baksa   172 Feb 28 13:40  test2.tgz
-rwxrwxrwx 1 baksa baksa    31 Feb 28 13:20  test2.txt
-rwxrwxrwx 1 baksa baksa 20480 Feb 28 13:22  testcat.tar
-rwxrwxrwx 1 baksa baksa   321 Feb 28 13:40  testcat.tgz
-rwxrwxrwx 1 baksa baksa 10240 Feb 28 13:24  testtar.tar
-rwxrwxrwx 1 baksa baksa   149 Feb 28 13:40  testtar.tgz

(A testtar.tgz mérete nyilván megegyezik a test1.tgz méretével.)

A 7zip testcat.tar-ra adott warningja elég egyértelmű: 


WARNINGS:
There are data after the end of archive

Nem is tudná támogatni. A tgz nem más, mint a 

tar cf - file|gzip -c >file.tgz
de
gzip -dc file.tgz|tar r[z]f - file2 .... >file2.tgz
tar: Options `-Aru' are incompatible with `-f -'

Így készül, de a seek csak file típusú ojjektumon működik, a pipe meg nem tudja. Mert az olyan, mint a szalag. ;) Ezt mutatja a hibaüzenet. Ráadásul önmagára sem lehet írni, ezért máris jön a felesleges diszkművelet. De a zip és rar esetében is csak az append az egyszerű - ott a headerek nincsenek tömörítve.

A (t)gz meg azért is írható egymás után, mert az rfc definiálja. 

cat file1.gz file2.gz >file3.gz
és
gzip -dc file1.gz file2.gz == gzip -dc file3.gz

A 7z warningja rendben is lenne. Csak nincs -i opciója, amivel ezen tovább lehetne lépni.
Ezért, amikor hirtelen felindulásból 20 helyett 1 blokknyira vettem az EOF méretét - az is mindegy. Egyik esetben szétszáll (azt hiszi, hogy az EOF szabályos méretű), amásikban meg csak nem olvassa el.

A megoldásom oka az, hogy a tömörített tar már átjött a hálózaton, teszteltem és ezek után nem szeretném kifejteni, majd újratömöríteni. Ahol a szabványos tar működik, ott szabályos.

Ah, most már értem, miért hoztad a Windowst.

Valahogy így kellene előszedni valamit
Igen, tudom, viszont rengeteg idő - ami a mai gépek sebessége miatt néhány megás fájlok esetén nem tűnik fel, de gigás méretben már szembetűnő.

a Hagyd csak, látszik hogy fingja sincs se a tar-ról se a gzip -ről. ellen kampányoltál
Nem. Azért írtam, mert Gyuszk nem értette meg, amit hajbazer írt, csak nem olyan egyszerűen fejeztem ki magam, mint wildy :)

Igen, a magyarul nem tudók ezt PEBKAC-nak hívják. Ha mentesz néhány apró dokumentumot, azt elő tudod szedni egy kattintással. Aztán elvárod, hogy egy nagy cég nagy adatbázisa is egy kattintásra előjöjjön.
Én inkább tervezési hibának, vagy hibás elvárásnak hívnám. A nagymennyiségű adatnak idő kell, még a gyors gépeken is. Ha a rengeteg fájl tárolásánál várakoznod kell, akkor átgondolatlanul tároltad őket. Higgyél nekem, mert van egy (pillanatnyilag) 33M mentést nettó 3TB területen kezelő archiváló rendszerem. Bármit 0 idő alatt előkap - persze a tömörítve 12GB méretű adatbázis előkapásához ott is idő kell. Viszont a 200MB-os konténerekből kattintás után azonnal dől a lekért intervallumból a mentett log. Pedig a konténer gzip formátumban van. ;)
Ez a "melyik a jobb" vita jobbára a "kattintok és ..." szempontokat sorolja, miközben hiányzik a gondolkodás képessége. Nagyképű duma, de nekem működik. ;)

Erre itt egy korrekt válasz.
A másik válasz pedig: Ha logokat mentek, akkor még tar sem kell, elég a gz. Kb. 200MB méretű konténereket használok, amelyekből pontosan 0 idő alatt tudok elővenni bárhonnan bármit. (ojjektumok száma 33M) Ugyanezt más formátummal is meg lehet csinálni. Ha véletlen hozzáférésű tárolóként használsz valamit, azt illik indexelni. Ha ez lehetetlen, akkor ésszerűen darabolni.
Olyan, mintha az adatbáziskezelőt szidnád, mert full table scan esetén nagyon lassú. Pedig van index is.

A tárolást méretezni szokás a méret, hozzáférés gyakorisága, a hozzáférés ideje, stb. alapján.

nagyz ssdivel az par pillanat
Ez csak egy hibás szemléletmód. Az alatt a pár pillanat alatt más elől veszed el a sávszélességet. Így aztán az ésszerűtlen felhasználással drágítod a tárolót - hiszen jó drága volt, de rosszul használod.

A tömörítés szempontjából bloat. Linuxon nem tudsz nem solid archive-ot csinálni a tar és a gzip összetapicskolásával. Az így készült archívumokból nem tudsz egy-egy fájlt kitömöríteni anélkül, hogy az egészet kitömörítenéd. Ez a tömörítés szempontjából értelmezett bloat. A UI egy külön téma. Azt a 7Zip, meg a többi tömörítő grafikus felületéhez kell hasonlítgatni. A tar-t és a gzip-et meg a rar command line binárishoz. Elárulom, a tar és a gzip binárisa együtt nagyobb, mint a raré. És együtt se tudnak annyit, mint a rar egyedül. Ennyit erről.

WinRAR az nem.

Klasszikus MFC alkalmazás, nem dizájnolták túl a felületét és nem is sikerült még elbaszni mindenféle divatos megjelenési trendekkel, pl. a metro vagy a material hulladékok majmolásával. Bármikor válthatok témát, vagy visszaállhatok a régi, klasszikus ikonos témára, ha az új készlet nem tetszene, emellett a UI is elég jól testreszabható, ha esetleg még valami nem tetszene.

OK, és egy tömörítő programot mi a péknek kellene témázni? Vagy a felületét testreszabni? Ezek a funkciók egy ilyen programnál teljesen felesleges dolgok, a te logikád szerint akkor bloat. És akkor még mindig ott tartunk, hogy ezért fizetni is kell, valamint tömörítési arányban sem tud többet, mint egy ingyenes, nyílt forráskódú "kollégája".

+1
Pontosabban TC, csak a rar.exe-t hivja, amit a legegyszerubb a winrar-ral feltenni.
Meg amugy midnen tomor formatumra ez van.
En nem nagyon tomoritek, ha jon valami, nem kell hozza vadasznom, hoyg ezt mi nyitja, winrar nyitni fogja.

--
http://www.micros~1
Rekurzió: lásd rekurzió.

Ez elég szomorú. Linuxon a Double Commandernek a libunrar kell csak opcionális függőségnek. Nyilván ezzel csak kibontani, tesztelni tud .rar archívumokat, frissíteni, betömöríteni nem, de azt nem is kell, mert nem akarunk zárt formátum terjesztésében, népszerűsítésében részt venni. A sima GNU pkzip és 7-zip bőven elég, a sima .zip-et és .7z-t mindenki ki tudja bontani, 7z-hez van TC plugin is.

De lefogadom TC-s sem csak warezzal megy, hanem ha letöltöd kézzel az unrar.exe-t, ami ingyenes, átnevezed rar.exe-re, akkor a TC azt is kezelni tudja, anélkül, hogy szemetet tennél fel a rendszerre. Legalább egy olyan szintig használhatónak kéne lennie, hogy ki tudjál vele tömöríteni.

No keyboard detected... Press F1 to run the SETUP

"mert nem akarunk zárt formátum terjesztésében, népszerűsítésében részt venni."

Jaja. Majd mindig mellekelek a usernek hasznalati utasitast a tar.gz melle.
Meg azt is leirom, ha rar-ban kap tolem valamit, hogyan tudja feltenni es beallitani a tc ala a rar.exe-t

Ugyanmar, egy "unrar x file.rar" a legegyszerubb, ha bontani akarod, de srciptbe is rakhatod (mittomen, hozza letre a rar nevevel megegyezo nevu konytarat es abba bontsa)

Tovabbra sem latom, hogy mi szol a rar _ellen_, leszamitva a lila kodos ideologiakat.

--
http://www.micros~1
Rekurzió: lásd rekurzió.

Nem mondtam, hogy feltétlenül tar.gz-t kell használni helyette, sőt, ha platformfüggetlen terjesztésre lesz, akkor kifejezetten ellenjavalt, mivel Windowson kezdőknek nehéz lesz kibontani, noha kicsit is haladóbbaknak egy gyors google-özés után nem probléma ingyenes szoftvert találni hozzá. A sima zip jobb ilyenkor. Ha meg nem elég a zip (bár nem értem miért ne lenne elég átlagos terjesztéshez, vagy átlag felhasználásra home/irodai usernek), mert valami extra feature kell, vagy nagyobb tömörítési fok, vagy erősebb titkosítás, akkor 7z-t érdemes használni helyette.

Ellenben magad válaszolod meg a saját kérdésed, hogy mi a baj a Rar-ral. Még egy olyan népszerű fájlkezelő, mint a TC is külön exe-t igényel, hogy kezelje, míg a zip-nél nem kell neki ilyen (meg 7z-nél sem kell neki semmilyen exe, elég a 7z plugint letölteni a TC hivatalos oldaláról, ez ingyenes). Ez nem lila ködös ideológa, hanem multiplatformos gondolkodás, túl kell látni a Windowson, nem csak Windows létezik, főleg, mióta a mobileszközök is elterjedtek.

Még Windowson is találni fogsz lila ködös ideológiával elvakított fősodratú usert, aki nem akar fizetős szemetet feltenni a gépre, ha nagyon nem muszáj.

Ugyanígy érdemes kerülni az önkicsomagolós archívumokat, mivel azokban a bináris kód megint csak platformfüggő, meg vírusfertőzésnek is jobban kitett.

De mint írtam, nem csak a Rar-nak vagyunk ellene. Ugyanilyen rossz szokott lenni, mikor mac-es userek valami beépített Apple formátumot használnak, ami nagyon kényelmes nekik, csak PC-n vagy Androidon, stb. ne kelljen megnyitni, mert akkor menni fog a vergődés. Zárt formátumokkal vendor lockinbe hajtod a fejed, és másokat is erre kényszerítesz.

No keyboard detected... Press F1 to run the SETUP

Hmm, voltakeppen mar ott van a gond, ha esetleg normal szoveges filet tomoritesz es kuldesz at.
Ha nem wordben nyitja meg, akkor szopas. Szoval ez a gond megvan a unix-dos-apple vonalon a sorvegekkel.

rar: tc-ben van belso rar kibonto, nem kell felrakni. Csak tomoriteshez kell a rar.exe. Viszont egyszeru, hetkoznapi user eseten sokkal egyszerubb, ha megkeri az ember, hogy rakja fel a winrart. A winzip ocsmany, bar bevallom, 10+ eve lattam utoljara. A winrar meg midnenfele tomoritett formatumot kezelt, a winzip csak a zipet (ismetlem, 10+ evesek az emlekeim)

"Ugyanígy érdemes kerülni az önkicsomagolós archívumokat,"
Azt mindenkeppen, hiszen csak azon az oprendszeren megy, amin cisnaltak.
--
http://www.micros~1
Rekurzió: lásd rekurzió.

Nem Rar ellenesség van, hanem zárt proprietary formátumokkal szembeni ellenségesség van, főleg olyan esetben, ahol a nyílt forráskodú, nyílt (nem licencköteles) szabványú megoldások semmivel nem maradnak el tömörítési fokban, tudásban, feature-ben.

Egyáltalán nem meglepő egy unix portálon, ahol az opensource hírek vannak többségében, és ahol a többség Linuxot használ, azon pl. a WinRar amúgy is ki van lőve.

No keyboard detected... Press F1 to run the SETUP

( carlcolt | 2019. 02. 24., v – 11:51 )

Egy haverom elkezdett dolgozni a winrarnal, aztan lejart a probaideje.

( toMpEr | 2019. 02. 26., k – 16:04 )

"Security researchers at the 360 Threat Intelligence Center (360TIC) just yesterday detected an in-the-wild malspam email campaign that's distributing a malicious RAR archive file that exploits the latest WinRAR vulnerability to install malware on computers running the vulnerable version of the software.

The malware drops a malicious exe file (CMSTray.exe) to the Windows Startup folder, designed to infect the targeted computer with a backdoor."

https://thehackernews.com/2019/02/winrar-hacking-exploit.html