NTFS-Partition irreparabel beschaedigt?
-
-
nman schrieb:
ja, aber was ist da der vorteil?
mir scheint das ganze "system" eher als nachteil, weil wenn da irgendwas in diesem einen block beschädigt ist, dann kann ich das ganze archiv in die tonne treten, weil sich nichts irgendwie wiederherstellen lässt?
-
vorteil/nachteil? schrieb:
nman schrieb:
ja, aber was ist da der vorteil?
Steht doch hier: http://en.wikipedia.org/wiki/Solid_compression#Benefits
-
vorteil/nachteil? schrieb:
nman schrieb:
ja, aber was ist da der vorteil?
Je nach Dateien unter anderem ganz erheblich viel bessere Kompression.
Bei herkömmlichem zip wird jede Datei einzeln komprimiert. Dadurch kann eine folgende Datei nicht davon profitieren, was der Kompressor so schon alles gelernt hat.
Bei solid archives (bei rar mit -s) stopft er alle Dateien erstmal zusammen und komprimiert dann erst. Optimalerweise sogar nach Dateiendungen sortiert, damit gleichartige Sachen nah beieinanderkommen (bei rar mit sogar anhand einer Datei rarfiles.lst mit
... *.txt *.htm *.html *.shtml *.css *.xsl *.xml *.js *.php *.lst *.log *.ini *.bat *.cmd *.h *.hpp *.c *.cpp *.asm *.bas *.bak ..., wo sich jemand die Mühe gemacht hat, übliche Dateiendungen zusammenzustellen in einer Liste, so daß ähnliche Dateitypen recht gut beieinanderstehen.)
Abgesehen vom Sortieren, macht tar.gz das aber eh schon ewig.
vorteil/nachteil? schrieb:
mir scheint das ganze "system" eher als nachteil, weil wenn da irgendwas in diesem einen block beschädigt ist, dann kann ich das ganze archiv in die tonne treten, weil sich nichts irgendwie wiederherstellen lässt?
Defekte Archive? Sowas kenne ich gar nicht mehr, seitdem ich keine Disketten mehr benutze. Wie lang ist das her?
(rar kann auch nach N Dateien, nach Dateiendungswechsel, und mit -rr5% kann man 5% Reparaturchecksummenzeugs dazuspeichern, das dürfte effektiver vor defekten Sektoren schützen, fürchte ich.)
-
also kann man sagen, dass solid compression in der heutigen zeit vorteilhaft ist.
wäre es dann nicht am besten, dateien, bevor man sie zippt oder 7zippt, mit tar zu packen?
-
also doch tar schrieb:
also kann man sagen, dass solid compression in der heutigen zeit vorteilhaft ist.
wäre es dann nicht am besten, dateien, bevor man sie zippt oder 7zippt, mit tar zu packen?
7zip kann kein solid compression?
Falls nein, ist tar davor natürlich besser für so Sachen wie mein Source-Code-Verzeichnis. Für meine ...videosammlung... bringt es nix.
-
volkard schrieb:
also doch tar schrieb:
also kann man sagen, dass solid compression in der heutigen zeit vorteilhaft ist.
wäre es dann nicht am besten, dateien, bevor man sie zippt oder 7zippt, mit tar zu packen?
7zip kann kein solid compression?
Falls nein, ist tar davor natürlich besser für so Sachen wie mein Source-Code-Verzeichnis. Für meine Pornosammlung bringt es nix.doch, 7z unterstützt solid (höchter wert: 64gb).
warum bringts für die ...videosammlung... nichts?
-
hä warum schrieb:
warum bringts für die ...videosammlung... nichts?
Weil die schon roh komprimiert vorliegen.
-
Natürlich kann .7z auch solid compression.
Der Punkt ist dass .tgz *nur* solid compression kann, und das nichtmal sonderlich schlau.
Schlau wäre z.B. wenn man die ganzen File-Headers am Anfang der Datei ablegt, und danach nur mehr die Daten. Dann geht es recht schnell das Archiv aufzumachen/aufzulisten..tar macht das aber nicht, sondern speichert immer nur eine File-Header, dann den Inhalt des Files, dann die nächste File-Header usw.
Soll heissen: .tgz ist mittlerweile total sinnfrei geworden. 7z ist einfach immer besser, egal was man braucht.
-
So what? Wer hat denn in der Praxis schon riesige Tarballs herumliegen (und will da auch einzelne Files rausklauben)? Tarballs verwendet man eben genau dann, wenn man typischerweise alles oder nichts entpackt. tar, gzip und bzip2 sind außerdem auf jeder Unix-Maschine vorhanden, genauso wie auf jeder Windows-Maschine zip vorhanden ist. Ergo sind weder Tarballs noch Zip-Archive "total sinnfrei".
7zip braucht außerdem auch unheimlich viel Speicher; für kleine Geräte à la Router oä. kann das ein echtes KO-Kriterium sein.
-
nman schrieb:
7zip braucht außerdem auch unheimlich viel Speicher; für kleine Geräte à la Router oä. kann das ein echtes KO-Kriterium sein.
das ganze ist aber abhängig von der verwendeten wörterbuchgröße.
der standardmäßig angewählte komprimierungsalgorithmus, lzma heißt er (wird übrigens schon von grub benutzt), kann auch bei relativ kleinen wörterbüchern gute ergebnisse bringen.
der niedrigste wert, den man in 7zip als wörterbuchgröße angeben kann, ist 64KB, da steht "Speicherbedarf beim Komprimieren: 38 MB".ich bin sicher, es würden auch noch kleinere wörterbuchgrößen gehen.
aber du hast im grunde recht, gzip braucht auf höchster stufe am wenigsten speicher. das liegt aber daran, dass die wörterbuchgröße auf dieser stufe 32kb ist.
--> würde man bei 7zip eine wörterbuchgröße von 32kb für eine 7z datei anwählen können, wäre der speicherplatz vielleicht noch kleiner.
das könnte man vielleicht über den dreisatz ausrechnen:
46KB / 38MB = 32KB / x
aber vielleicht noch vorher die einheiten richtigrechnen.
-
46KB / 38MB = 32KB / x
aber vielleicht noch vorher die einheiten richtigrechnen.es muss natürlich
64KB / 38MB = 32KB / x
heißen
-
wörterbuch schrieb:
das ganze ist aber abhängig von der verwendeten wörterbuchgröße.
Das stimmt natürlich, aber unterm Strich ist eben 7zip defaultmäßig bzw. bei halbwegs vergleichbaren Einstellungen eine Spur ressourcenhungriger als gzip und auch als bzip2. Auf Desktops tut das natürlich nicht weh, aber in vielen anderen Anwendungsfällen schon.
Ich persönlich verstehe ja auch nicht, warum das CLI von 7zip so unheimlich mies sein muss. Das wäre eine wirklich bequeme Möglichkeit gewesen, mehr Verbreitung gegenüber tar/gzip zu gewinnen; das CLI von tar ist ja auch gruselig. Wenn man: 7z(1) benutzerfreundlicher wäre, dann hätte das dem Verbreitungsgrad sicher geholfen.
-
nman schrieb:
wörterbuch schrieb:
das ganze ist aber abhängig von der verwendeten wörterbuchgröße.
Das stimmt natürlich, aber unterm Strich ist eben 7zip defaultmäßig bzw. bei halbwegs vergleichbaren Einstellungen eine Spur ressourcenhungriger als gzip und auch als bzip2. Auf Desktops tut das natürlich nicht weh, aber in vielen anderen Anwendungsfällen schon.
Ich persönlich verstehe ja auch nicht, warum das CLI von 7zip so unheimlich mies sein muss. Das wäre eine wirklich bequeme Möglichkeit gewesen, mehr Verbreitung gegenüber tar/gzip zu gewinnen; das CLI von tar ist ja auch gruselig. Wenn man: 7z(1) benutzerfreundlicher wäre, dann hätte das dem Verbreitungsgrad sicher geholfen.
naja, glaubst du wirklich, dass das an dem cli liegt?
ich würde eher sagen, dass viele menschen noch das rar-hirngespinst im kopf haben.
außerdem verstehe ich nicht ganz, warum sich das 7zip-projekt so sehr auf windows konzentriert. es gibt zwar eine linux cmd-version "p7zip", aber ich glaub, das kommt nicht offiziell vom projekt. erschließt sich mir nciht ganz.
würde windows ab version 9 7z, und nicht mehr zip unterstützen, dann würde das wohl einen gewaltigen schritt für den bekanntheitsgrad von 7z bedeuten.
aber soweit wirds nicht kommen... open-source ist ja für windows wie ein krebsgeschwür (und NEIN, das ist NICHT meine formulierung: http://www.heise.de/newsticker/meldung/Microsoft-Chef-Ballmer-bezeichnet-Linux-als-Krebsgeschwuer-38381.html)
-
8zip schrieb:
naja, glaubst du wirklich, dass das an dem cli liegt?
Dass der Verbreitungsgrad so niedrig ist? Nein, ich meinte nicht, dass das ein besonders wichtiger Grund ist. Aber es wäre so leicht gewesen, ein gutes 7zip-CLI zu basteln und die Chance wurde komplett verschenkt. Und direkt _geschadet_ hätte das der Verbreitung nun auch nicht.
Außerdem holt 7zip technisch ja wirklich erst die letzten Jahre so richtig groß auf. Gab ja auch auf Coding Horror diverse Posts dazu.
außerdem verstehe ich nicht ganz, warum sich das 7zip-projekt so sehr auf windows konzentriert. es gibt zwar eine linux cmd-version "p7zip", aber ich glaub, das kommt nicht offiziell vom projekt. erschließt sich mir nciht ganz.
Wundert mich auch, aber war vmtl. keine bewusste Entscheidung. Wenn die Hauptentwickler primär Windows verwenden, dann wird eben auch vor allem dafür entwickelt.
würde windows ab version 9 7z, und nicht mehr zip unterstützen, dann würde das wohl einen gewaltigen schritt für den bekanntheitsgrad von 7z bedeuten.
Klar, wobei Zip ja auch vor WinXP schon extrem verbreitet war.
Naja, das ist jetzt auch schon wieder 12 Jahre her. Und das glaubte der damals so ja selbst auch nicht.
edit: Was natürlich nicht heißt, dass Microsoft demnächst anfangen wird, 7zip-Support bereitzustellen; dazu haben sie einfach keine echte Motivation.
-
Was micht wundert ist dass WinRAR immer noch so verbreitet ist.
Natürlich kauft das Ding auch keiner, aber die ganzen Idioten verwenden lieber nen nicht lizensierten WinRAR als den freien 7Zip.
Kann mir einer erklären wieso?
Ist das wirklich nur die Macht der Gewohnheit?
-
hustbaer schrieb:
Was micht wundert ist dass WinRAR immer noch so verbreitet ist.
Bei den Warez wohl, weil es so verbreitet war. Wegen Solid Archives, Recovery-Records, Multipart und Encryption alles in einem. Sowas ändert sich eben nicht so fix.
hustbaer schrieb:
Natürlich kauft das Ding auch keiner, aber die ganzen Idioten verwenden lieber nen nicht lizensierten WinRAR als den freien 7Zip.
Ich Idiot verwende rar, Du Idiot. Die rar.exe für die Kommandozeile taugt was und darf kostenlos benutzt werden (so war es wenigstens die Jahre immer). Die Klickibuntioberfläche brauche ich weder bei WinRar noch bei 7Zip.
hustbaer schrieb:
Kann mir einer erklären wieso?
Ist das wirklich nur die Macht der Gewohnheit?Weil die Kommandozeilenparameter so reichhaltig sind.
http://pastebin.de/32782
Es gibt für Win wohl keine Alternative, wenn man produktiv arbeiten will und auch mal spontan eine neue Überlegung in einen Ablauf einfließen lassen will.Auch gerade verwende ich es. Ich schubse damit zu compilierenden Sourcecode nach Linux. Ich brauche dort nur einen Account, wo ich per ssh reinkomme, keine zusätzlichen Server, Netzwerkfreigaben, rsync-daemons oder pi pa po.
rar a -r -s -ac -ao -ts- send.rar *.cpp *.hpp makefile type send.rar | plink compile@192.168.0.16 -pw 1234 "cat > send.rar && \ /opt/bin/rar x -y -ts- send.rar && make"Beim Packen:
a: add files to archive
-s: solid
-ac: clear archive attribute
-ao: Add files with Archive attribute set
-ts-: timestamp ganz niedrig speichern, weil hier irrelevantBeim Auspacken in der VM:
Hier ist der Witz das -ts-, wodurch die geschriebenen Dateien den Timestamp nicht aus dem Archiv kriegen, sondern einfach die Zeit des Erzeugens in Linux. Weil nämlich die Uhr gelegentlich um Stunden oder Tage falsch geht, aber so brauche ich micht nicht darum zu kümmern, die ganzen clock-skew-detected-Warnungen sind weg.rar kann's einfach, was ich mag.
-
@volkard
Nochmal lesen bitte, und dann Entrüstung zurückschrauben.Ich rede von WinRAR, nicht von der CLI Version.
Ich rede von Leuten die nichtmal wissen dass RAR überhaupt ein CLI Interface hat. Oder was CLI überhaupt bedeutet.
Und wenn man einfach nur ein Archivtool mit netter Explorer-Integration möchte, dann sehe ich keinen Grund WinRAR zu klauen, wenn man statt dessen 7zip ganz offiziell gratis verwenden kann.p.S.: da
http://www.rarlab.com/download.htm
steht überall "Trial", auch bei den nur CLI Versionen für Linux/BSD/Mac. Wäre jetzt komisch wenn das bei der Windows-Version anders wäre.
-
WinRar kann außerdem nur in das hauseigene RAR und in das ZIP format packen.
7zip kann: 7z, bz2, xz, zip, tar usw.
also ich nutze 7zip nicht nur, weils kostenlos ist, sondern weils unterm strich mehr kann als (Win)rar.
Außerdem habe ich persönlich die erfahrung gemacht, dass 7z archive im vergleich zu rar archiven meist noch kleiner sind.
(Win)Rar hat ausgedient. mag sein, dass es noch für.... verwendet wird.
alle andern benutzen es, weil sie nicht wissen, dass es etwas besseres gibt.
-
hustbaer schrieb:
Was micht wundert ist dass WinRAR immer noch so verbreitet ist.
*schulterzuck* Auf der TU Wien gab es vor zwei Jahren noch WinZip-Campuslizenzen, die sich höchster Beliebtheit erfreuten.
edit: Gibt es immer noch: https://iu.zid.tuwien.ac.at/851269.asHTML
