hallo.

bei mir kommt es immer wieder vor, allerdings häufig mit xpress-dateien, dass die dateinamen - die etwas länger sind - später vom finder umbenannt werden. dabei wird die letzte "hälfte" mit #3566 oder ähnlichem ersetzt. was kann ich dagegen machen?

danke.

Hallo,

> dabei wird die letzte "hälfte" mit #3566 oder ähnlichem ersetzt.

Das "riecht" nach Dateinamen-Mangling. Gehe ich recht in der Annahme, daß die "längeren" Dateinamen unter MacOS X erzeugt wurden und das Problem dann unter MacOS 9 (bzw. in der Classic-Umgebung) auftritt?

Lokal oder auf einem Server? Falls letzteres: Welche Serversoftware?

Gruss,

Thomas

Hat mit OS9 glaube ich nichts zu tun,
tritt bei mir neuerdings auch bei längeren
Namen auf, unter plain Panther 10.3.5...

Gruß
Dirk

[Adobe GoLive Tipps & Tricks]
http://www.gltipps.de

hallo,

das problem tritt tatsächlich mit server daten auf. auch schon unter älterer 10.3 version. es hat aber - meines wissens - nichts mit classic zu tun.

gruß und danke.

der "server" läuft unter mac os 10.3

"Hat mit OS9 glaube ich nichts zu tun"

Doch! Classic kann Dateinamen über 31 Zeichen nicht darstellen, genauso verhält es sich bei Windows.

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.

Taucht das Problem nur mit XPress auf?

Greez, Idefix

Das Problem tritt bei bestimmten Namen
mit allen Anwendungen auf, auch auf
Systemebene X werden die Dateinnamen
so verkürzt...

Gruß
Dirk

[Adobe GoLive Tipps & Tricks]
http://www.gltipps.de

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

Hallo nochmal,

> 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.

Tja, wer lesen kann, ist klar im Vorteil :-)

Das Anhängsel kam ja hinten dran, also isses der normale Mangling-Mechanismus in MacOS X, der zum Tragen kommt. Warum auch immer ;-)

Gruss,

Thomas

Check ich nicht... Warum tritt das Problem auch mit OS X Server auf, der ebenfalls AFP 3.1 kann? Kriegt das Apple nicht hin?