Die größten Probleme in Mac OS X Panther

[halessa]

Das leidige Suffix-Problem: Beim Aktivieren "alle Suffixe zeigen" in den Finder-Einstellungen ändert das OS alle Begriffe in Englisch um. Das ganze ist dann so ein Mix-Klon aus deutsch und englisch, was etwas nervig ist.

 

[abgemeldeter Benutzer]

1) Der Finder legt auf externen Datenträgern Resource Files an (.DS_*)

Das sind keine Resourcen-Dateien.

Die ._-Dateien sind die Resourcen (+ die Metadaten). Das wird sich bei Tiger ganz sicher nicht ändern, weil dann nämlich die Dateien zerstört würden.

.DS_Store sind Fenstereinstellungs-Dateien des Finders.

@ sgmelin
Desktop.ini und Thumps.db. Haben aber einen andere Funktion.

 

[sgmelin]

@ sgmelin
Desktop.ini und Thumps.db. Haben aber einen andere Funktion.

Trotzdem nerven sie. Und ich denke darum gings ursprünglich. Aber in Desktop.ini stehen die Daten des Fensters und dessen Icons. Die Thumbs.db enthält den Cache für die Grafikvorschau.

 

[ratti]

Macht Windows auch. Heisst dort halt anders.

Wen interessiert Windows? Es gibt immer einen, der es noch schlechter macht, aber der taugt nicht zum Vorbild.

Mal abgesehen von dieser Allgemeinphilosophischen Betrachtung: Ich wüsste nicht, daß Windows das tut - jedenfalls nicht in jedem Ordner...

Die diversen Mac-Files (.DS*, Icon^M) liegen wie Ziegelsteine in unserem CVS rum - bei den Icondateien kommt dann erschwerend dazu, daß sie Dank eines Linefeeds im Dateinamen auch etliches anderes bröseln (z.B. .cvsignore-Files)...

Gut, wenn Tiger das jetzt kickt.

Gruß, Ratti

 

[ratti]

Die ._-Dateien sind die Resourcen (+ die Metadaten). Das wird sich bei Tiger ganz sicher nicht ändern, weil dann nämlich die Dateien zerstört würden.

Meines Wissens empfiehlt Apple aber bereits seit längerer Zeit, daß Programme ihre Daten so anlegen sollten, daß sie auch ohne Ressourceforks auskommen.

Ich nehme mal an, daß man langfristig Cross-Platform-kompatibler werden will (Wobei ich dann allerdings wieder nicht verstehe, wieso für Software und Mails dann wieder Pakete benutzt werden - hat man denn aus diesen Sch.... Suitcases nix gelernt?)

Na, jedenfalls: Ich arbeite nur mit Sachen, wo die Ressourcefork überflüssig ist (genauer gesagt: Wir löschen regelmässig alle Ressourceforks auf unserem Linux-Server). Das trifft natürlich nicht auf jeden zu, aber /ich/ wäre sehr froh, wenn man die Macs davon abhalten könnte, irgendwas "Mac-spezifisches" auf externe Filesysteme zu schreiben.

Gruß, Ratti

 

[c.shell]

hallo.

wie gesagt ich habe den aktuellen tiger build auf diese daten getestet.
es wird auf externen festplatten, samba mounts, etc keine .DS* datei mehr gespeichert.

mfg

 

[ratti]

hallo.

wie gesagt ich habe den aktuellen tiger build auf diese daten getestet.
es wird auf externen festplatten, samba mounts, etc keine .DS* datei mehr gespeichert.

mfg

Sorry, wenn ich nerve: Hast du zufällig ein aktuelles ( Version >=2.0rc1 ) netatalk in Reichweite und könntest es dort auch noch mal checken?

Gruß, Ratti

 

[abgemeldeter Benutzer]

Meines Wissens empfiehlt Apple aber bereits seit längerer Zeit, daß Programme ihre Daten so anlegen sollten, daß sie auch ohne Ressourceforks auskommen.

Anfangs mag das so gewesen sein, mittlerweile sind die Prioritäten aber korrigiert worden. Im Bezug auf die Metadaten (welche ja auch auf flachen Dateisystemen in den ._-Dateien gespeichert werden) wurde in der PB und auch noch in 10.0 nur auf die Suffixe zur Erkennung des Dateityps gesetzt. Spätestens seit Jaguar stehen die Type/Creator-Codes wieder in der Priorität vor dem Suffix.

Ich nehme mal an, daß man langfristig Cross-Platform-kompatibler werden will (Wobei ich dann allerdings wieder nicht verstehe, wieso für Software und Mails dann wieder Pakete benutzt werden - hat man denn aus diesen Sch.... Suitcases nix gelernt?)

Für andere Plattformen sind Pakete doch einfach nur Ordner mit Suffix. Die darin enthaltenen Dateien liegen komplett im Datenzweig.

Na, jedenfalls: Ich arbeite nur mit Sachen, wo die Ressourcefork überflüssig ist (genauer gesagt: Wir löschen regelmässig alle Ressourceforks auf unserem Linux-Server). Das trifft natürlich nicht auf jeden zu, aber /ich/ wäre sehr froh, wenn man die Macs davon abhalten könnte, irgendwas "Mac-spezifisches" auf externe Filesysteme zu schreiben.

Ich halte die Trennung von Daten und Resourcen für eine gute Erfindung. Die Idee mit den Resourcen hat sich ja auch mittlerweile rumgesprochen, nur werden die halt mit den Daten gemischt (z.B. EXIF-Daten in JPEGs oder ID3-Tags in MP3s). Leider machen die anderen (die flachen Dateisysteme) den kleinsten Nenner. (Oder noch schlimmer, die, die ein mehrschichtiges Dateisystem, NTFS, besitzen, es aber nur flach nutzen.)

 

[bassermann]

die nervigste angelegenheit für mich ist immernoch die SCHRIFTVERWALTUNG, die mir als die ultimative lösung verkauft wurde...
jetzt lädt man mal eine 'helvtica neue' und schon laufen systemprogramme nicht mehr... das problem besteht seit 10.3.0 und wurde in 5 updates nicht korrigiert...
(ich weiß suitcase und so) ich würde mir wünschen, daß man dem system wirklich die schriften zuordnen kann... mit dem tinkertool geht das nur bedingt...

 

[Lynhirr]

Ja das habe ich bereits vor Monaten schon gemacht. Bisher immernoch ohne Reaktion.

Naja kleine Fehler ignoriert man aber was soll man mit Mac OS X machen wenn man z.B. sein eigenes SSL Zertifikat in Safari überprüfen muss?

Nun, Apple schreibt dir nicht zurück, das wäre wohl ein imenser Aufwand, aber sie nehmen das zur Kenntnis, und bemühen sich ...


Hm, ich musste noch nie ein Zertifikat überprüfen, und bin von Anfang an im WorldWideWeb. Wann braucht man das?

Lynhirr

 

[lundehundt]

die Loesung zu Punkt # 3 (SSL Zertifikate von anderen 'Trustcentern importieren) ist hier:


Cheers,
Lunde

 

[kaboo_ki]

Wann braucht man das?

Lynhirr

z.B beim Onlinebanking...habe auf der Postbankseite Hinweise auf Fake-Seiten gelesen die aussehen wie die Originalseite der Post... auf dieser werden aber deine Kontodaten und der PIN ausspioniert. Daher macht es also Sinn sich mal das Zertifikat anzusehen bevor man persönliche Daten angibt.

Gruß
kaboo_ki

 

[Lynhirr]

z.B beim Onlinebanking...habe auf der Postbankseite Hinweise auf Fake-Seiten gelesen die aussehen wie die Originalseite der Post... auf dieser werden aber deine Kontodaten und der PIN ausspioniert. Daher macht es also Sinn sich mal das Zertifikat anzusehen bevor man persönliche Daten angibt.

Gruß
kaboo_ki

Ich habe mich da informiert: Diese Seiten funktionieren nur, wenn man von einem fremden Link dorthi geleitet wird (E-Mail oder anderes). So lange man die Bankseite manuell eingibt, oder per persönlichen Bookmarks, gibt es keine Probleme.
Somit sind die Zertifikate weiterhin für mich uninteressant.

Lynhirr

 

[ChrisOnSki]

Hallo zusammen,

mich nerven vielmehr die plattformübergreifenden Kopiervorgänge. Ich wollte gestern Daten auf meinen WinXP Rechner (Fileserver) auslagern und bin an Dateinamen mit Umlauten bzw. Sonderzeichen gescheitert. Das Blöde daran ist, dass der Finder meldet das er die Datei nicht kopieren kann und anstatt die Datei einfach zu überspringen bricht er den Kopiervorgang einfach ab. Super! Da soll noch einer herausfinden was kopiert wurde und was nicht...
Hat einer von Euch eine Lösung für solche Probleme?

ciao
Chris

 

[abgemeldeter Benutzer]

@ ChrisOnSki
Damit wirst Du Dich wohl an M$ wenden müssen.
Redmond we have a Problem.

 

[bassermann]

mal wieder typisch ._ut ;o)
warum sollte sich redmond um die 4% macUser kümmern?
das rechnet sich für die einfach nicht...

 

[abgemeldeter Benutzer]

@ bassermann
Die hatten aber auch Zeit, wahllos Zeichen herauszusuchen, um sie für Dateinamen zu verbieten. Meinst Du das rechnet sich für die?

 

[93noddy]

äh also andersrum hab ich das problem auch...die lösung ist da wie folgt: Apple als netzlaufwerk verbinden und mit xcopy arbeiten. Ich denke andersrum geht es ähnlich: Mounten, cp

 

[ratti]

Anfangs mag das so gewesen sein, mittlerweile sind die Prioritäten aber korrigiert worden. Im Bezug auf die Metadaten (welche ja auch auf flachen Dateisystemen in den ._-Dateien gespeichert werden) wurde in der PB und auch noch in 10.0 nur auf die Suffixe zur Erkennung des Dateityps gesetzt. Spätestens seit Jaguar stehen die Type/Creator-Codes wieder in der Priorität vor dem Suffix.

Verdammt.
Ich hatte gehofft, man würde den Kram langfristig endlich los.

Für andere Plattformen sind Pakete doch einfach nur Ordner mit Suffix. Die darin enthaltenen Dateien liegen komplett im Datenzweig.
Ich halte die Trennung von Daten und Resourcen für eine gute Erfindung. Die Idee mit den Resourcen hat sich ja auch mittlerweile rumgesprochen, nur werden die halt mit den Daten gemischt (z.B. EXIF-Daten in JPEGs oder ID3-Tags in MP3s). Leider machen die anderen (die flachen Dateisysteme) den kleinsten Nenner. (Oder noch schlimmer, die, die ein mehrschichtiges Dateisystem, NTFS, besitzen, es aber nur flach nutzen.)

Schonmal versucht, unter einem anderen OS einen Koffer zu öffnen, weil du an die Metriken eines Fonts dranwolltest? Selbst wenn du die Ressource-Fork rüberkriegst, hast du irgendein proprietäres Dateiformat namens "Koffer".

Warum ist ein Postfach in Mail ein Package, welches eine mbox und eine Indexdatei einthält - warum hat man nicht einfach die flache mbox und ein .idx-Datei? Es steht außer Zweifel, daß es lokal funktioniert, aber /warum/?

Warum bekommen EPSe eine pict-Preview in der Ressource-Datei, vorbei an allen von Adobe definierten Standards, statt eine Cross-Platform-kompatiblen Tiff-Preview in der Data-Fork?

Der ganze Ärger - nur, damit Dateien kleine Bildchen und ein buntes Etikett bekommen können... Immer diese Extrawürste. Ich lege alle meine Datenstrukturen so an, daß sie auf allen Plattformen rennen. Das heisst:
- Alle Files bekommen eine Extensions
- Keine Leerzeichen, Umlaute, Sonderzeichen in Dateinamen.
- Kurze Dateinamen
- "Creator", wo nötig, in den Filnamen, z.B. "logo.fh8.eps" für Freehand

Glücklicherweise rudert da immer mehr Software zurück. Moderne Fonts sind eine "normale" Datei, die CreativeSuite schreibt eigentlich nur mit TIFF-Preview in der Datafork brauchbare EPSe und eigentlich alle Programme hängen inzwischen eine Extension an.

Gruß, Ratti

 

[sgmelin]

Das heisst:
- Alle Files bekommen eine Extensions
- Keine Leerzeichen, Umlaute, Sonderzeichen in Dateinamen.
- Kurze Dateinamen
- "Creator", wo nötig, in den Filnamen, z.B. "logo.fh8.eps" für Freehand

Wieso denn das??? Gib mir mal einen triftigen Grund, warum eine Datei eine extension haben sollte. Gerade als Linux Verfechter, der Du ja bist sind ext. ja quatsch. Die Appl. soll gefälligst in das File reingucken und nicht auf die ext. Dann ist auch Schluss mit Script-Viren.
Gut, Sonderzeichen kann ich verstehen. Leerzeichen sind aber doch kein Problem. Sie sind vielleicht für uns humanoide schlecht zu handeln, weil wir sie immer in Anführungszeichen setzen müssen, aber das ist doch auch nur eine kleine Unannehmlichkeit.
Kurze Dateinamen????? Wieso um alles in der Welt darf ich meinen Brief nicht "Brief an Oma wegen Danksagung für Weihnachten" nennen??? Ich will bereits am Namen erkennen können was mich erwartet. Gut, 255 Zeichen sind vielleicht etwas viel, aber so um die 50 Zeichn sollten es schon sein. Die 31 auf meinem Amiga waren schon oft zu kurz.
Creator wo nötig? Wieso denn? Ich muss sagen, wenn ich in der Datei den Creator erfasse reicht das doch. Wenn im Header Freehand drinsteht soll sich das System darum kümmern woher es kommt....
Also manchmal überraschst Du mich doch stark.