Mailinglist Archive: opensuse-de (2762 mails)

[LKA364@xxxxxxxxxxx (Thomas Schwarze)]

Nochmals hallo,

da ich von einigen wohl falsch verstanden wurde, will ich den Grund
meiner
Frage erklären.

Wir haben bei uns im Labor ständig verschiedene fremde Rechner mit allen
möglichen Betriebssystemen, angefangen von MS-DOS über Windows XX,
Novell
und Macintosh bis zu neuerdings häufiger auch Linux/Unix Systemen.

Von den Festplatten müssen wir Datensicherungen anfertigen, die aus
Gründen
der Sicherheit von uns auf CD-ROM gebrannt werden. Die physikalischen
Sicherungen machen uns keine Probleme mehr (dank verschiedener Tips aus
der
Liste läuft das z.B. mit "split -b650m /dev/..." hervorragend). Die
logischen Sicherungen der Dateien machen uns Kopfzerbrechen. Starten wir
unsere Laborrechner z.B. mit Windows NT, um eine NTFS Partition zu
sichern,
schreibt NT sofort auf der Platte rum, da es seinen Papierkorb anlegen
will.
Also bietet sich Linux an, da Linux mit den meisten Filesystemen
(zumindest
lesend) umgehen kann und wir die fremden Festplatten schreibgeschützt
auslesen können. (Ich will die Vorteile von Linux hier beenden, da die
Liste
sonst zu lang wird :-)).

Von daher können wir aber weder die Dateien umbenennen (wir haben eh
schon
das Problem mit Joliet und nur 32 Zeichen lange Namen) noch ist es ein
Problem von mtools. mtools nutzen wir sonst überhaupt nicht. Ich hatte
es in
dem von mir vorgeschlagenen Test nur aufgeführt, weil ich damit direkt
unter
Linux die Auswirkung der Umlaute demonstrieren kann, da mdir sich genau
so
verhält, wie MS-DOS und Windows XX.

Nun müssen nach der logischen Sicherung aber alle Dateien auch dem
Urzustand
entsprechen und lesbar sein. Das klappt aber nicht, wenn in dem
originalen
Dateinamen Umlaute waren. Und dieses Problem hat nichts mit MSDOS, FAT
oder
VFAT zu tun, sondern liegt an Linux. Daher meine Anfrage.

Noch ein paar Hinweise zu den technischen Einzelheiten:

Der Buchstabe "Ä" wird auf einem FAT16-System mit dem Dezimalwert 142
bzw.
Hexwert 8E im Dateinamen gespeichert. Dieses ändert sich auch auf VFAT-
bzw.
VFAT32-Systemen nicht. Dort wird nur _zusätzlich_ ein "langer" Dateiname
erzeugt, in dem die Codierung nach dem Unicode erfolgt, also 16-Bit pro
Buchstabe lang ist, so daß das "Ä" im langen Dateinamen mit dem
Dezimalwert
196 bzw. Hexwert 00C4 gespeichert wird.

In allen von uns durchgeführten Versuchen macht Linux jetzt aber den
Fehler,
diesen Unicode-Wert für das "Ä" nicht nur im "langen" Dateinamen sondern
auch im kurzen 8.3 Dateinamen zu verwenden. Das führt dazu, daß unter
Umständen Windows XX den Dateinamen richtig anzeigt (z.B. -RGER.TXT
statt
ÄRGER.TXT). Wenn aber auf die Datei zugegriffen werden soll (z.B. lesen
oder
löschen), dann wird der 8.3 Dateiname verwendet, und der beinhaltet
einen
illegalen Wert nämlich Dezimalwert 196, der von MS-DOS als Grafikzeichen
verwendet wurde und genauso wie Leerzeichen, Doppelpunkt usw. im
Dateinamen
verboten ist (unter MS-DOS/Windows).

Meine Fragen sind daher:

1. Haben wir hier einen (Installations-) Fehler gemacht und funktioniert
es
bei anderen "richtig"?

2. Wenn nicht, welche Lösung (unter Linux) gibt es? Wie bringen wir
Linux
bei, die Unicodes nur in langen Dateinamen und nicht in den kurzen zu
verwenden? Oder wer kennt sonst eine Lösung?

3. Gibt es als Symptom-Behandlung eine Möglichkeit, beim Kopieren z.B.
mit
cp oder tar oder bei der Erstellung einer Image-Datei mit mkisofs "on
the
fly" Umlaute in Dateinamen zu ändern (Ä => AE) ? Dazu wäre dann aber
eine
Messages-Datei notwendig, damit z.B. hinterher ein sonst nicht mehr
lauffähiges Buchhaltungsprogramm wieder richtig hergestellt werden kann.

Das geschilderte Problem tritt übrigens nicht nur unter xFAT auf sondern
auch beim Speichern auf Novell, beim Erzeugen einer Image-Datei mit
mkisofs,
beim Schreiben in eine tar-Datei, beim Gebrauch von cpio usw. usf..

Gruß

Thomas

--
Um aus der Liste ausgetragen zu werden, eine Mail an majordomo@xxxxxxxx
schicken, mit dem Text: unsubscribe suse-linux