Windows "kompatibles" ZIP erstellen ...

[skywalker]

Was muss man denn da bitte "bashen"?
Wirf mal einen Blick in ein Windows System und finde dich zurecht. Viel Spass.
Das *ist* nun mal ein völlig planloser Saustall, der jegliche erkennbare logische Strukturierung vermissen lässt. Da wirst du mit Schönfärberei nichts dran ändern können.

komm mal runter von deiner tour.....
ich finde mich schon zurecht.
zudem ging es nicht um ein os sondern um dateien in einem verzeichnis.....

 

[Bonobo]

GraaaAAH! Liebe Leute, koennen wir uns da nicht einigen und entgegenkommen? Ich schaetze Euer Beider Beitraege sehr und sehe hier eher, dass Ihr aneinander vorbeiredet.

Vorschlaege fuer einige Aussagen, auf welche man sich vielleicht einigen kann:

1. Windows-bashing ist IMMER gerechtfertigt! :-D

2. Es sind leider noch nicht alle Computerbenutzer zur hellen Seite der Macht geswitcht.

Darum sind 3. natuerlich einige von uns immer noch darauf angewiesen, mit Windows-(OK, gleich wieder Mund ausspuelen)-Benutzern Geschaefte zu machen.

Also muessen wir 4. nett zu denen sein, die uns bezahlen.

Und ausserdem bashen wir ja 5. Windows und nicht seine Benutzer, die armen Geiseln von Redmond, oder?

Und 6. siehe 1.


Waer' das was?

<Asbestunterwaescheanzieh>

Uebertemperierter Gruss

Tom

p.s.: Ich empfehle allen, sich (mal wieder) das Hoehlengleichnis von Platon zu verinnerlichen.

 

[skywalker]

empfehle den thread nach "windows auf dem mac" zu verschieben, dann lassen uns die fundis hier in ruhe...

 

[Syncron]

Mei, ward ihr wieder bös zueinander. :-[

Windows ist klasse!

N.e.s.T

C R E K O S

 

[Hilarious]

Unabhängig aller philosophischer Gedanken über das grundsätzliche Vorhandensein von Moral in Betriebssystemen (ist das Unrechtsbewußtsein bei Windows-Benutzern angeboren oder nicht?), würde ich gern die Frage in den Raum werfen, ob nicht gzip eine "resourcenschonende" Alternative wäre. Dies hätte zwar eine andere Dateiendung, die eventuell nicht sofort als ZIP-Datei identifiziert würde, aber jeder (PK)ZIP-Anwender unter Windows könnte es öffnen und bei OS X natürlich schon "dabei".

Sachliche Meinungen?

 

[Bonobo]

Ach kommt, ich war diesmal echt lieb!

Ich bin leider immer wieder mal gezwungen, auf Windows zu unterrichten. Ich brauche manche Sachen inzwischen nur noch anzutippen, da checken die's schon, immerhin ist das Bewusstsein ueber die Gefahren und allgemein die Minderwertigkeit des Betriebssystems ihrer Wahl (bzw. halt "Vorbestimmung") anscheinend gewachsen. Wenn ich (woertlich!) die zwei Strafen des Himmels erwaehne, Internet Explorer und Outlook Express, fassen die sich meist schon von selber an den Kopf und erzaehlen mir eifrig, dass es da ja den Firefox gaebe und Thunderbird. Das ist doch schon mal was. Und ich setze dann gleich fort: "und diese beiden hervorragenden Programme gibt's natuerlich auch fuer den Mac, wie eigentlich jedes gute Programm, bloss ziehen die meisten Benutzer Safari und Mail diesen Programmen noch vor."

Meistens gebe ich hinterher zu, dass alles noch viel schlimmer ist und der Himmel viele Strafen fuer uns hat, dass Windows die allererste ist ...



Und irgendetwas scheine ich richtig zu machen: Es switchen immer wieder Ex-Schueler von mir zum Apfel -- erfreulicherweise oft gerade diejenigen, die vorher die groessten Windows-Apologeten waren. This gives me warm and fuzzy feelings inside :-D

 

[pete]

würde ich gern die Frage in den Raum werfen, ob nicht gzip eine "resourcenschonende" Alternative wäre. Dies hätte zwar eine andere Dateiendung, die eventuell nicht sofort als ZIP-Datei identifiziert würde, aber jeder (PK)ZIP-Anwender unter Windows könnte es öffnen und bei OS X natürlich schon "dabei".

Inwiefern ist gzip resourceschonender? Ich habe ein wenig in den man-pages gelesen, habe aber nichts entdeckt, was mir das verständlicher machen würde.

Das Problem sehe ich übrigens tatsächlich im Suffix. Eine Datei mit "zip" als Suffix wird von jedem Anwender klar als das erkannt, was es ist. Ich spreche aus der Sicht eines Datenversenders, dessen Adressaten nicht unbedingt etwas von den Systemen oder Daten verstehen, mit denen Sie umgehen, und sich z.B. über entpackte eps-Daten beschweren, weil die nicht per Doppelklick in Windows zu öffnen seien.

----

Übrigens muss ich leider meinen "ditto"-Beitrag vom Anfang des Threads korrigieren. Das Kommando funktioniert wie beschrieben, und es lässt auf Wunsch auch Resourcen und HFS Meta-Daten weg, aber es lässt, so, wie ich es angegeben habe, leider nicht nicht die ".DS_Store"-Dateien weg. Aber genau das war ja der Wunsch.

Das gilt übrigens auch für Die Anregung von KayHH, das "zip"-Kommando zu verwenden. Dabei werden, wie er sagte, Resourcen und HFS Metadaten standardmäßig ignoriert, aber die ".DS_Store"-Dateien nicht.

 

[pete]

-df: Nur Data-Fork hinzufügen.
-r: auch Dateien deren Name mit „.“ beginnt hinzufügen.

Diesen Beitrag hatte ich überlesen, sorry!

-r ist beim zip-Kommando unbedingt notwendig, um rekursiv Unterverzeichnisse zu verpacken. Dabei werden dann "leider" auch Dateien berücksichtigt, die mit Punkt beginnen.

-df funktioniert bei mir nicht! Habe das neueste OS X!

 

[Hilarious]

Inwiefern ist gzip resourceschonender? Ich habe ein wenig in den man-pages gelesen, habe aber nichts entdeckt, was mir das verständlicher machen würde.

Ich bezog »resourcen-schonend« auch mehr auf das (automatische) weglassen der Resource-Forks/.DS_Store-Komponenten beim Zusammenfassen und Komprimieren. Man verzeihe mir das platte Wortspiel...

 

[pete]

Ich bezog »resourcen-schonend« auch mehr auf das (automatische) weglassen der Resource-Forks/.DS_Store-Komponenten beim Zusammenfassen und Komprimieren. Man verzeihe mir das platte Wortspiel...

Ah, OK, versteh versteh. :-D

Ich kann den ursprünglichen Anwendungswunsch trotzdem gut nachvollziehen. Ich könnte auch so ein Tool gut gebrauchen, welches mir nur das ins Archiv packt, was auch auf dem "anderen" System brauchbar ist.

 

[Rastafari]

-df funktioniert bei mir nicht!

Selbstverständlich funktioniert es - nur kannst du es auch weglassen, weil das ausschliesslich die MacOS-Classic-Variante des Programms betrifft und unter X ohnehin 'Default' ist. Dort läuft nämlich die Unix-Version, nicht die obsolete MacOS-Variante von InfoZip.

Ausserdem: "man zip" sagt:
-df [MacOS] Include only data-fork of files zipped into the archive. Good for exporting files to foreign operating-systems. Resource-forks will be ignored at all.

Richtig gelesen. Ignoriert, nicht hinzugefügt. Das genaue Teilgegen also.

Die korrekte zusätzliche Option zum weglassen von .DS_Store Dateien wäre: -x .DS_Store
Das funktioniert aber nur bei direkter Angabe von zu packenden Dateien, beim rekursiven durchforsten von Unterordnern klappt das auch nicht. (In meinen Augen ein Bug...)

Die korrekte Option zum Hinzufügen von Resourceforks in ZIPs gibt es nicht. Der Grund dafür ist, dass das Format ZIP einfach keine Multifork-Dateien beherrscht. Um diesen Trick dennoch hinzubekommen, verwendet der Finder eine bestimmte Namenskonvention beim Anlegen von zusätzlichen Unterordnern innerhalb des Archivs, in diesen zusätzlichen Ordnern werden die vorher von der Datei abgespaltenen Resourceforks dann abgelegt - analog zu ihren zugehörigen Datenzweigen. Beim Entpacken werden diese Namensstrukturen erkannt und die Dateien wieder zusammengefügt (durch FixUpResourceForks).

(Die Resourceforks werden dabei in ._* AppleDouble-kodierte Dateien umgesetzt, genau so wie das auch auf Volumes geschieht, die keine Resourceforks können, zB FAT-Volumes. Der Unterschied ist im ZIP nur, dass diese separat innerhalb von einheitlich mit "__MACOSX" benannten Ordnern landen und nicht direkt neben dem Datenzweig der Datei.)

Das Terminalkommando zip kann das aber nicht alleine. Wollte man diesen Effekt erreichen, wäre es nötig, 'zip' zB durch ein (nicht gerade banales) Skript zu subtituieren, welches die entsprechenden Vorgänge transparent vornimmt, das Resultat schliesslich an das Originalprogramm zip weiterreicht und dem Benutzer dann das Ergebnis präsentiert.
Sowas zu schreiben ist unnötig - 'ditto' hat genau sowas schon eingebaut. Wer Resourceforks im ZIP braucht, soll einfach ditto einsetzen. Das ist übrigens so clever, auch noch weitere Mac-spezifische Metadaten wie Zeitstempel oder bestimmte wichtige HFS-Flags mit einzupacken (Bundle-Bit, Custom-Icon Bit, Template Bit, Finder-Labels usw...).
ditto kann das wahlweise mit ZIP (genauer: PKZip) oder aber auch GNU-ZIP (*.gz) Archiven als Ausgabeformat erledigen.

Leider besitzt ditto keine Option zum weglassen bestimmter Dateien nach Name.
Wenn man sowas haben möchte, sich aber die UNIX-Fossile und hochkomplexen Packsysteme 'pax', 'cpio' oder den deFacto-Standard 'tar' nicht antun will, muss man eben die Namensfilterung mittels der Shell selbst durchführen (zB mit 'find') und das Resultat über eine Pipe zu ditto schicken.

Wem das nichts sagt, dem sei *dringend* empfohlen, auf eins der vielen GUI-Frontends zurückzugreifen, die sowas auch für Otto N. Ormalverbraucher (ohne Unix-Grundkenntnisse) auf bequeme Weise anbieten.

(Dann klappts auch mit Aliasen, symbolischen Links und ähnlichen Fussangeln, die schon so manches ZIP unbrauchbar gemacht haben...)

Anm: Die Programme aus der StuffIt-Linie können das latürnich auch. Kostet halt.

 

[pete]

Omm.

Danke, Rastafari! Jetzt verstehe ich einiges besser.