Snow Leopard - Dateikomprimierung

[Vjay]

Hi,

hat schon jemand herausgefunden wie man diese benutzen kann? Bzw. ob man überhaupt manuell das Komprimieren von Dateien anstossen kann? Oder geht dies nur automatisch, wenn ja nach welchen Auswahlkriterien?

Danke.

 

[joGo373]

Sekundärklick -> "Datei XY komprimieren" gibt es nicht mehr? Habe noch kein SL, deswegen diese Frage.

 

[Vjay]

Doch das gibt es noch, das ist aber was anderes. Hier ist nicht das Erstellen von ZIP Archiven gemeint sondern die Komprimierung, die in das Dateisystem eingebaut worden ist.

 

[Vjay]

Bis heute noch immer niemand eine Antwort? Dafür das das eines der "Killer-Features" war, ist es darum aber wirklich leise.

 

[CARN]

Ich denke es geht darum, dass die SYSTEMdateien komprimiert werden. Das und der Umstand, dass ein GB ab sofort nicht mehr 1024 MB sondern 1000 MB sind führt dazu, dass SL so viel Speicher "einspart" bei der Installation.

 

[Unkaputtbar]

Ich denke es geht darum, dass die SYSTEMdateien komprimiert werden. Das und der Umstand, dass ein GB ab sofort nicht mehr 1024 MB sondern 1000 MB sind führt dazu, dass SL so viel Speicher "einspart" bei der Installation.

Und vielleicht auch noch der Grund, dass Apple den PPC-Code rausgeschmissen hat.

Manuel

 

[Vjay]

Naja das würde zumindest erklären, warum ältere HFS Treiber noch funktionieren sollen. Dann wäre die Komprimierung gar nicht in HFS integriert, sondern in einem Layer darüber, der lediglich beim Zugriff auf Systemdateien dekomprimiert und die braucht man unter einem anderen OS (per Fernzugriff) ja nicht.

Das Problem daran ist nur, irgendwie ist das nicht das, was ich als das, was mir verkauft worden ist, ansehen würde. Ich würde auch gerne selten genutzte Programme verkleinern, zur not mit Fremdtools, falls die Interfaces nur in der API vorliegen. Aber wenn es so ist, dann gibt es ja gar kein Zugriff darauf. Dann müsste man ja davon reden, dass OSX nicht Dateikomprimierung beherrscht, sondern sie es geschafft haben (wie auch immer) das System zu verkleinern.

 

[hanebambel]

Die Komprimierung läuft für Dich transparent direkt im Dateisystem:
http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars/3#hfs-hobbyhorse

CU Jan

 

[Bananenbieger]

Ich denke es geht darum, dass die SYSTEMdateien komprimiert werden.

Exakt. Das Feature ist nur für Systemdateien gedacht worden.

In der [tt]ditto[/tt]-Hilfe findet sich folgendes:

--hfsCompression
When copying files or extracting content from an archive,
if the destination is an HFS+ volume that supports compres-
sion, all the content will be compressed if appropriate.
This is only supported on Mac OS X 10.6 or later, and is
only intended to be used in installation and backup scenar-
ios that involve system files. Since files using HFS+ com-
pression are not readable on versions of Mac OS X earlier
than 10.6, this flag should not be used when dealing with
non-system files or other user-generated content.

 

[Rastafari]

Oder geht dies nur automatisch, wenn ja nach welchen Auswahlkriterien?

[SIZE="-2"]man ditto
...
--hfsCompression
                   When copying files or extracting content from an archive,
                   if the destination is an HFS+ volume that supports compres-
                   sion, all the content will be compressed if appropriate.
                   This is only supported on Mac OS X 10.6 or later, and is
                   only intended to be used in installation and backup scenar-
                   ios that involve system files. Since files using HFS+ com-
                   pression are not readable on versions of Mac OS X earlier
                   than 10.6, this flag should not be used when dealing with
                   non-system files or other user-generated content.
...
[/SIZE]

Dateien müssen:
- "nur lesen" Rechte besitzen
- sich innerhalb von digital signierten Paketen befinden
- Teil einer intel-only und 64bit-enabled Komponente sein
- TODO: Incomplete. (even more restrictions may apply)

 

[Vjay]

Hey danke euch dreien, das sind doch schon gute Informationen, das werde ich mir mal alles durchlesen, vielleicht kann man das ja doch für sich nutzen, als Anwender.

 

[Vjay]

Also ich habe es mal mit Ditto versucht. Den Befehl kannte ich noch gar nicht.
ditto ordner1 ordner2 --hfsCompression

Dann habe ich http://osxbook.com/software/hfsdebug/ heruntergeladen und damit die Dateien verglichen. Es scheint wirklich funktioniert zu haben, habe jDownloader komprimiert und was ich als Laie aus der Debugausgabe lese, hat sich die Dateigrösse der plist file halbiert. Und zwar Dateigrösse durch 2 als alternativer Filestream und das Attribut com.apple.decmpfs taucht auf, wie in dem Blog beschrieben.

compression type = 3 (xattr has compressed data)
attrSize = 479 bytes
uncompressed size = 1054 bytes

Danke für die Hilfe, damit kann ich nun loslegen wild umherzukomprimieren. Bei Bedarf wird ja eh bei Schreibzugriffen dekomprimiert - so wie ich das verstanden habe.

Werde ich aber auch eben testen, komprimierte Dateien zu modifizieren.
*EDIT*
Funktioniert perfekt.

 

[Rastafari]

Werde ich aber auch eben testen, komprimierte Dateien zu modifizieren.
*EDIT*
Funktioniert perfekt.

Das solltest du erst durch einen Neustart verifizieren. In einer der letzten Betas war da jedenfalls noch kräftig der Wurm drin und du konntest nur irreführenderweise den BufferCache zurücklesen. Nach dem nächsten Reboot hatte die Datei dann plötzlich Null Bytes... ups.

 

[Vjay]

Das wäre weniger schön. Werde das im Auge behalten, ich komprimiere gerade diverse Applications, Timemachine-Backups sind vorhanden, nur für den Fall, dass da jetzt etwas daneben geht.

 

[Rastafari]

Das wäre weniger schön. Werde das im Auge behalten

Zusätzlich solltest du auch noch was im Hinterkopf behalten:
Das vorsätzliche strippen von (vermeintlich unnötigen) Resourceforks, AppleDouble-Files (._*) und/oder EAs ist ab sofort vollkommen tabu.

 

[Vjay]

Ja das stimmt. Aber das war es für mich vorher schon und da ich einheitlich Snow Leo einsetze sehe ich da überhaupt keine Probleme. Ich werde die Compression auch nur für Systemteile wie Applications einsetzen, niemals die Userdaten anfassen. Ist aber vielleicht für andere interessant.

Ich habe mal ein kleines Script gechrieben:

sh-3.2# cat /usr/sbin//hfscompress
#!/bin/bash
echo Vorher:
du -sk "$1"
ditto "$1" compresstmp --hfsCompression && mv "$1" delmetmp && rm -rf delmetmp && mv compresstmp "$1" && echo done
echo Nachher:
du -sk "$1"

Man muss zum Ausführen Superuser sein. Siehe sudo oder su! Sonst bekommt man für jede Datei eine Fehlermeldung.

Dies komprimiert einen Ordner, falls die Kompression fehlschlägt, bleibt denke ich der Temp-Ordner stehen, ist bisher aber noch nie geschehen.
Aufruf: hfscompress Ordner/Datei/Programm.

 

[Rastafari]

hfscompress Ordner/Datei/Programm.

Es wird dir so aber noch keine verlässlich korrekten Ergebnisse liefern.
Um Fehlmessungen auszuschliessen musst du vor der Kopie (mit "ls" und "lsof") sicherstellen, dass es in dem Ordner weder irgendwelche Hardlinks noch aktuell geöffnete Dateien hat.
Sonst schiesst du dir selber ins Knie. "Originaldatei"+"komprimierte Kopie" kann niemals kleiner werden als das -evtl verlinkte- Original allein. Und offene Dateien kann "rm" nicht wirklich löschen, sondern nur irreversibel zur späteren Löschung delegieren (bleiben persistent bis zum nächsten mount oder fsck-Lauf des Volumes).
Wäre ein sattes Eigentor mit hohem Selbstverwirrungsfaktor. Ist halt doch nicht so sehr für den Endbenutzer gedacht, dieses Feature. Fledermausland.

 

[Vjay]

Und wieder muss ich dir zustimmen

Ich habe das Script mal auf die ersten Erkenntnisse angepasst (oben). Natürlich möchte ich niemanden dazu verführen, sich sein System zu zerschiessen. Das Script ist auch ein erster Wurf, vermutlich wie die Kompression selber. Da irgendetwas zu prüfen, das soll der User selber machen, bin auch nicht so gut im Scripten. Vielleicht möchte jemand das auch weiter entwickeln.
In Zeiten von Terabyteplatten sicher auch nicht nötig, aber als SSD Nutzer blutet einem einfach das Herz, wenn man sieht wie da verschwendet wird.

Beispielvorgang:
sh-3.2# hfscompress Developer/
Vorher:
2074684 Developer/
done
Nachher:
744004 Developer/

Apropos Diablo2 komprimieren lohnt nicht, die Dateien sind bereits komprimiert. Danach geht übrigens der mds hin und indexiert die Ordner neu, nicht wundern, dass die CPUlast ansteigt. Spotlight bekommt nämlich mit, dass die Dateien ausgetauscht worden sind.

Hier noch das hfsUncompress Script, für Fälle, in denen man feststellt, dass die Komprimierung unnötig war (Diablo2 z.B.)

sh-3.2# cat hfsuncompress
#!/bin/bash
echo Vorher:
du -sk "$1"
ditto "$1" compresstmp --nohfsCompression --nopreserveHFSCompression && mv "$1" delmetmp && rm -rf delmetmp && mv compresstmp "$1" && echo done
echo Nachher:
du -sk "$1"

Ausführung:


sh-3.2# hfsuncompress Diablo\ II\ Folder/
Vorher:
2093400 Diablo II Folder/
done
Nachher:
2093744 Diablo II Folder/


Also ich habe jetzt alleine mit Herumspielen 2 Gigabyte mehr frei

 

[Rastafari]

Apropos Diablo2 komprimieren lohnt nicht, die Dateien sind bereits komprimiert.

...und verschlüsselt (wenn auch nur ziemlich deppert )

Von "World of Warcraft" (known), anderen Spielen von Blizzard (hörensagen) sowie einem evtl. vorhandenen "Skype" (known) solltest du übrigens gänzlich die Finger lassen.
Ich bezweifle, dass deren selbst völlig vogelfrei zusammengestümperte Checksummentests mit Kompression auf FS-Ebene kompatibel sind. Resultat wäre wohl: Streik, Programm-Neuinstallation.

 

[Vjay]

Das mag sein, WOW würde ich nicht anfassen, alleine aus Performancegründen, denke eh dass sie da wie Diablo verfahren haben.
Mhh Skype werde ich aber testen. Derweil atmet meine "Kleine" (Platte) gerade richtig auf, mit jeder Last die ihr genommen wird. Das on the fly dekomprimieren funktioniert bisher tadelos. Habe zum Spass ein grosses Eclipse Projekt komprimiert, dann per svn geupdatet (habe fast erwartet dass es ein Desaster wird) aber nichts - svn checkt nur die wirklich modifizierten Files aus und alles funktioniert genau so wie es sollte. Eclipse ebenfalls komprimiert - kein Performance hit, alles funktioniert wunderbar. Irgendwie ist das zu schön gerade, ich rechne daher derweil mit dem Schlimmsten - jederzeit :-D