Hallo,
> Classic kann Dateinamen über 31 Zeichen nicht darstellen, genauso
> verhält es sich bei Windows.
Wie?
Es gibt da einige Limitationen, die man getrennt betrachten sollte:
HFS kann maximal 31 Byte lange Dateinamen darstellen, HFS+ bis zu 255 lange. Somit wäre "eigentlich" seit MacOS 8.1 die 31-Byte Limitation obsolet gewesen, nur wurden die alten Filemanager-APIs nie geändert und insofern kann auch MacOS 9.2.2 (respektive der Finder und die meisten Anwendungen) nur mit 31 Byte max. umgehen.
Bei AFP (also Netzwerkzugriff -- ich nehme mal an, daß niemand so wahnsinnig ist zwischen MacOS X Clients und Server per SMB zu interagieren) hängt es von der Version ab.
AFP 2.2 kennt ebenfalls maximal 31 Bytes, AFP 3.x dann 255.
> Auf dem Server dürfte es IMHO nicht auftauchen, da OS X ja
> bekanntlich mehr als 31 Zeichen darstellen kann und diese
> Eigenschaft auch über das Netzwerk behalten wird.
Wie schon geschrieben: Es kommt drauf an :-)
Wird in der Classic-Umgebung per Auswahl ein Server-Volume gemountet, dann geschieht das per AFP 2.2. Wird ein Volume dagegen in MacOS X direkt per "/Netzwerk" oder "Mit Server verbinden" gemountet, dann geschieht das heutzutage mit AFP 3.1 fähigen Servern auch mit jener höheren Protokoll-Version.
Was passiert nun mit langen Dateinamen?
Wenn der Mount per AFP 2.2 passiert, dann ist es Sache des Servers, die Dateinamen passend umzuwandeln. Apple selbst wählt bei ihrem AppleFileServer die Methode, daß sie den Dateinamen *hinten* abschneiden und die sogenannte CNID (Catalog Node ID) in hexadezimaler Form anhängen. Helios EtherShare mit aktuellen AFP 3.1 Previews hängt die CNID vorne dran. Netatalk wiederum hinten aber nach einem anderen Schema wie MacOS X... Wie es ExtremeZ-IP macht weiß ich nicht.
Wenn der Mount mit AFP 3.1 passiert, dann übersetzt ein VFS-Layer zwischen "Classic" und der Sicht der Dinge, wie sie MacOS X direkt sieht (dito mit HFS+ Volumes unter MacOS X, auf denen lange Dateinamen vorkommen und auf die per Classic zugegriffen wird). Hier greift AFAIK wieder Semantik mit dem Anhängen der CNID abgetrennt durch einen Raute "#".
Was mich bei der Schilderung also verwirrte, war die Aussage, daß dieses numerische Anhängsel vorne an den Dateinamen kommt, da ich das bisher eben nur von Helios kenne.
Ach ja: Die in Windows 2000/2003 eingebauten Fileservives machen es sich besonders simpel und verletzten einfach dreist die AFP-Spezifikationen. Sie sprechen zwar nur AFP 2.2 (also max. 31 Byte) stellen serverseitig vorhandene längere Dateinamen aber einfach dreist gegenüber den Clients ungekürzt dar, was Abstürze gutgläubig programmierter älterer Anwendungen zur Folge haben kann (dank des nicht vorhandenen Speicherschutzes der alten MacOS Versionen muß es dabei auch nicht unbedingt die betreffende Applikation erwischen sondern es kann eine andere Anwendung oder gleich das ganze System ebenfalls treffen)
Gruss,
Thomas
als Antwort auf: [#103706]
