OSX/HFS+ Fragen... (Dateibenennung & Restriktionen?)

W

whitegrey

Aktives Mitglied
Thread Starter
Dabei seit
17.08.2004
Beiträge
213
Reaktionspunkte
0
Da ich inzwischen genug von meinem Windows-Mainsystem habe, vor allem was die Datensicherheit anbelangt, möchte ich samt komplettem Datenbestand (etwa 1.4 TB Multimediafiles) auf OSX switchen... Single G5 1.8 ist vorhanden, die externen Firewiregehäuse sind unterwegs, dann kann es eigentlich losgehen :)

Die HDD's übernehme ich natürlich aus der Windose (Neukauf würde mich ruinieren ;)), es handelt sich um mehrere Platten (1x400, 1x300, 2x200, 2x120 - alles Seagate Cudas PATA, +1x80 WD PATA) jeweils NTFS formatiert. Firewireplätze wurden nachgerüstet - sind also ausreichen vorhanden...

ich nehme mal an von NTFS auf HFS+ wird ohne Datenverlust nicht ohne weiteres möglich sein, ich habe jedoch eine Backup-HDD zum Auslagern also ist auf HFS+ neu formatieren absolut kein Problem...

zur eigentlichen Frage bzw. zum eigentlichen Problem:
welche Restriktionen gibt es zu beachten was Dateinamen anbelangt (OS ist 10.4.2), unter Panther hatte ich bei vielen Dateien das Problem, dass im Dateinamen Zeichen vorhanden waren die OSX anscheinend nicht mochte - Kopieren von Win auf Mac übers Netzwerk war bei diesen Files nicht möglich - wird mir ja beim manuell rüber spielen genauso gehen nehm ich mal an. Ich habe seinerzeit eine Liste der "verbotenen" Zeichen gesehen - allerdings k.A mehr wo.

zusätzlich sind viele (v.A mp3-)Dateien in Shift-JIS (Japan) kodiert - sollte eigentlich keine Probleme machen, aber wenn mir da Dateinamen verloren gehen ist es mühsam den ursprünglichen Zustand wieder herzustellen...

Ich vermute mal um das Umbenennen vieler Files komme ich nicht herum - damit rechne ich schon fix, zumindest eine Liste mit Zeichen die unter OSX bei Dateinamen nicht erlaubt sind würde mir da schon sehr helfen...

tia :)
 
hmm, ein Doppelpunkt kommt dann doch zu selten vor in den Dateinamen - nämlich gar nicht (ist ja bei NTFS /FAT32 unter Win schon nicht zulässig wenn ich mich recht entsinne). Ich glaube also nicht, dass es rein daran gelegen hat... Sachen wie ".Punkt", "!Rufzeichen", "|Trennstrich", "~Rund", "'Apostroph" usw. kommen da schon eher vor, da würde es mich nicht so wundern.

hab jetzt mal selbst kurz getestet - und zumindest bei Dateien die unter OSX erstellt wurden scheint alles zu funktionieren, das damals hab ich mir aber nicht eingebeildet *drop* Werd's dann wohl in der Praxis testen müssen und etwaige Ergebnisse posten...

in 1-2 Fällen war die Länge des Namens schuld, aber eben nicht immer...

Nachtrag: als die Übertragungsfehler auftraten war 10.2 installiert - könnte auch eine Rolle spielen. Nacher hab ich es eigentlich nicht mehr wirklich getestet...
 
Zuletzt bearbeitet:
Die Länge des Namens kann nicht sein, denn die ist unter Mac OS X / HFS+ deutlich länger. Mac OS X erlaubt 255 Zeichen pro Objekt, Windows jedoch nur 256 Zeichen für den gesamten Pfad (incl. der Backsalshes und des Laufwerksbuchstabens).

Für HFS+ ist der Doppelpunkt das einzige verbotene Zeichen. Es kann aber sein, dass beim Übertragen über das Netzwerk die Restriktionen von SMB da noch reinpfuschen oder auch, dass der Samba-Client als UNIX-Dienst keinen Schrägstrich (/) mag.
 
Zuletzt bearbeitet von einem Moderator:
@ avalon
Das ließe sich auch leicht per Automator oder AppleScript regeln. Die Dateien müssen hier aber eh unter Windows umbenannt werden.
 
._ut schrieb:
Es kann aber sein, dass beim Übertragen über das Netzwerk die Restriktionen von SMB da noch reinpfuschen
Zum Vergrößern anklicken....
das klingt schon mal sehr plausibel :)
bei Wechseldatenträgern sind mir bisher keine Fehler untergekommen (USB-Stick, iPod [FAT32]), da habe ich zwar weit nicht so viel transferiert aber es untermauert trotzdem die Theorie mit SMB - es waren zudem Netzwerk-Errors (Fehler 36 o.Ä)...

thx vorerst!
 
das problem steht eher in der unterschiedlichen zeichen kodierungs einstellungen der samba server...
der hfs+ will unicode...
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben Unten