Re: tar: can't translate pathname "..." to UTF-8

From: Oliver Fromme <oliver(at)fromme.com>
Date: Mon, 31 Jul 2017 09:29:52 +0200 (CEST)

Hi,

Marc Santhoff wrote:
> Tag schon wieder,
>
> ich fasse mal zusammen:
>
> 1. Die Warnung von bsdtar ist wirklich nur eine Warnung, die Dateien
> werden unverändert eingepackt.

Was ich nicht verstehe: Wieso sollte tar versuchen, irgendwas
nach UTF-8 zu konvertieren, wenn man das nirgendwo konfiguriert
hat? Das Default-locale ist "C" (d.h. 7bit US-ASCII), *nicht*
UTF-8.

Das korrekte Verhalten wäre daher, mit einer Fehlermeldung
abzubrechen, die besagt, dass die Dateinamen 8-Bit-Zeichen
enthalten, was im aktuellen locale ("C") nicht codiert werden
kann. GNU-tar verhält sich natürlich auch nicht korrekt, wenn
es das locale gleich vollkommen ignoriert.

Offenbar nimmt BSD-tar an, wenn kein locale gesetzt ist, aber
trotzdem 8-Bit-Zeichen in Dateinamen vorkommen, dass diese
in UTF-8 kodiert sind. Das mag zwar inzwischen in vielen
Fällen tatsächlich zutreffen, aber halt nicht in allen (wie
bei Dir). Ich persönlich fände es richtiger, sich an den
Standard zu halten und nicht zu versuchen, zu "raten", was
der Benutzer gemeint haben könnte.

Die Lösung (bzw. Workaround) für Dich wäre natürlich, das
locale korrekt zu setzen, also etwa zu beginn des Skripts
diese Zeile:
    export LC_CTYPE=en_US.ISO8859-15
Oder Du setzt es in der crontab (dann ohne das "export"),
dann gilt es halt gleich für alle cron-Jobs.

Oder Du stellst gleich ganz auf UTF-8 um. ;-)

Gruß
   Olli

PS: Das hilft jetzt nicht direkt, aber weil es zur Sprache kam:
Das mit der Ellipsis war natürlich Unsinn. "..." hat weder als
ASCII-Zeichenfolge noch als UTF8-Ellipsis-Zeichen irgendeine
Sonderbedeutung für das Dateisystem. Wie Harold ganz richtig
schrieb, sind '\0' und '/' die *einzigen* Bytes, die in Datei-
namen nicht erlaubt sind, und darüberhinaus haben "." und ".."
als Dateinamen eine Sonderbedeutung. Der Punkt generell hat
*keine* Sonderbedeutung für das Dateisystem.

Das Schöne an UTF-8 ist ja gerade, dass alle nicht-ASCII-Zeichen
mit Bytes >= 128 kodiert werden. Das bedeutet, dass in einem
UTF-8-Zeichen, das aus mehreren Bytes besteht, niemals '\0'
oder '/' vorkommen können. Daher kann man UTF-8 vollkommen
problemlos für UNIX-Dateinamen verwenden (im Gegensatz zu
anderen Kodierungen wie z.B. UCS / UTF-16).

Was cron-Jobs betrifft: In /etc/login.conf gibt es auch den
Abschnitt "daemon". Er wird von init(8) verwendet und von
/etc/rc aufgegriffen und daher auch von cron(8) geerbt (und
allen anderen daemons, die beim Booten gestartet werden).
Allerdings glaube ich, dass dabei keine Umgebungsvariablen
gesetzt werden. Davon abgesehen wäre es ohnehin keine gute
Idee, an dieser Stelle ein locale zu definieren, weil es ja
global gilt und zu diversen Nebenwirkungen führen kann. Dann
schon eher in der jeweiligen crontab setzten, dann gilt das
locale zumindest nur für diese crontab.

In Skripten würde ich auch dazu raten, *nicht* LANG oder LC_ALL
zu setzen, wenn es nur um die Zeichencodierung geht. Dafür ist
LC_CTYPE zuständig. Anderenfalls kann es passieren, dass z.B.
ls(1), date(1) und andere Tools plötzlich ihre Ausgabe anders
formatieren (oder gar auf Deutsch machen), was zu Problemen
führen kann, wenn Skripte versuchen, deren Ausgaben zu parsen.

Man sollte auch bedenken, dass auf einem Multiuser-System
durchaus mehrere User unterschiedliche locales verwenden können
und dementsprechend unterschiedliche Codierungen von Umlauten
in Dateinamen haben können. Das kann dazu führen, dass man
z.B. unter /home/anna Dateinamen mit ISO8859-Kodierung und
unter /home/brit Dateinamen mit UTF-8 hat. Das macht es dem
Admin nicht gerade einfacher -- In dem Fall könnte man sich
überlegen, kurzerhand unter /usr/share/locale nur noch die
UTF-8-locales zu behalten und alle anderen zu entsorgen.
Dann müssen die User, die noch ISO8859 verwenden, einmal bei
sich umstellen, aber danach gibt's keine Probleme mehr.

-- 
Oliver Fromme, München   --   FreeBSD + DragonFly BSD
``We are all but compressed light'' - Albert Einstein
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Mon 31 Jul 2017 - 09:29:56 CEST

search this site