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

Polytropon wrote:
> On Mon, 31 Jul 2017 09:29:52 +0200 (CEST), Oliver Fromme wrote:
> > 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.
>
> Vielleicht is im System aber durch irgend etwas UTF-8 als
> Locale gesetzt worden? Also an einer Stelle, wo es sich auch
> auf cron-Jobs auswirken kann?

Ob der cron-daemon eine LC_*-Variable oder LANG im seinem
Environment mitbekommen hat (z.B. von init(8) bzw. /etc/rc),
lässt sich recht einfach mit folgendem Kommando ermitteln:

ps -eww $(pgrep cron)

(Man muss es als root ausführen; normale Benutzer dürfen das
Environment von fremden Prozessen normalerweise nicht sehen.)

Wenn dort nichts von LC_* oder LANG zu sehen ist, kann es
nur noch in der jeweiligen crontab selbst gesetzt sein.
Wenn auch das nicht der Fall ist, dann werden die cron-Jobs
mit dem Default-locale aufgerufen, also "C" bzw. US-ASCII.
Es bleibt dann dem jeweiligen Skript selbst überlassen,
beispielsweise LC_CTYPE zu setzen.

> > 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 Fehlermeldung gibt leider wenig Ansatzfläche her. :-(

Ja, in der Tat. Man müsste das im Source von bsdtar(1)
und/oder libarchive(3) nachschauen.

> [...]
> > Oder Du stellst gleich ganz auf UTF-8 um. ;-)
>
> Ist das denn mittlerweile "der Standard"?

Darüber kann man streiten.

Wenn Du mit „Standard“ meinst, ob es standardisiert (normiert)
ist: Ja, selbstverständlich ist es das, sogar schon seit
langer Zeit. Unicode ist ein Industriestandard, dessen erste
Ausgabe (1.0) auf das Jahr 1991 datiert, ist also bereits mehr
als ein Vierteljahrhundert alt. Die entsprechende ISO-/IEC-Norm
10646 gibt es immerhin seit 1993. Die IETF hat UTF-8 erstmals
in RFC 2044 aus dem Jahr 1996 spezifiziert.

Umgangssprachlich meint man dagegen mit „Standard“ häufig, ob
etwas weit verbreitet ist bzw. von der Mehrheit benutzt wird
und es somit „quasi standard“ ist. Dazu nur ein paar Anhalts-
punkte: Bei Windows wird bereits seit Windows NT Unicode als
interne Darstellung verwendet. Auch etliche Programmiersprachen
verwenden intern Unicode für Strings (z.B. Java und Python).
Laut w3techs.com verwenden aktuell 90% aller Websites UTF-8.
Praktisch alle moderneren Dateisysteme verwenden Unicode, u.a.
NTFS, UDF, ExFAT, HFS+, ISO9660 (mit Joliet-Extensions).

Zahlreiche Zeichen, die in Dokumenten verwendet werden und
die typographisch wichtig sind, existieren nicht in ISO8859.
Dazu gehören die deutschen Anführungszeichen (habe ich oben
absichtlich mal verwendet), die veschiedenen Striche (u.a.
Gedankenstrich, von-bis-Strich), die bereits erwähnte Ellipse,
das große scharfe S, und vieles mehr.

> > 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.
>
> Richtig, denn sowohl "..." als auch "…" sind gültige Dateinamen
> und sollten problemlos in tar-Archiven erzeugt werden können.
> Auch beim Auspacken findet beim Dateianlegen keine Interpreta-
> tion statt - die 2 Byte für "…" werden im Dateisystem als Datei-
> name hinterlegt, und ob man dann bei "ls" nun "…" sieht oder
> "A-Tilde ein Viertel umgedrehtes Fragezeichen" oder "Klotz",
> ist ja nicht Sache von tar.

Nunja, tar hat insofern doch damit zu tun, als es automatisch
zwischen Kodierungen beim Ein- und Auspacken übersetzt. Sprich:
Wenn Du ein tar-Archiv mit einem ISO8859-locale erzeugst und es
dann mit einem UTF-8-locale auspackst, dann werden eventuelle
Umlaute in den Dateinamen automatisch umgesetzt, so dass sie
auf dem Ziel-locale wieder richtig herauskommen.

Das funktioniert natürlich nur, wenn die locales sowohl beim
Ein- als auch beim Auspacken korrekt gesetzt sind.
Wobei ‒ wie bereits erwähnt ‒ das Problem darin besteht, dass
tar fälschlicherweise UTF-8 als Default annimmt, wenn gar kein
locale gesetzt ist.

Diese automatische Umsetzfunktion von bsdtar ist natürlich nur
ein Workaround, der deswegen notwendig ist, weil das klassische
UNIX-Filesystem UFS keine Zeichencodierung definiert und daher
Dateinamen in Abhängigkeit vom locale interpretiert werden.

Gruß
   Olli

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