Zusammenhang von HAL-Mountproblemen mit charset?

C

cabriofahrer

Well-Known Member
Ich nutze FreeBSD mit Gnome2 und HAL. Beim Einstecken von CD's, Sticks und externen Festplatten werden die Medien jeweils automatisch gemountet und erscheinen als Symbole in Nautilus mit entsprechender Bezeichnung. So weit, so gut. Doch manchmal kann es bei bestimmten USB-Sticks passieren, dass diese nicht korrekt gemountet werden, und sogar alle anderen Symbole für bereits gemountete Medien verschwinden, bzw. andere Medien ab diesem Moment des "Zusammenbruchs" nicht mehr gemountet werden. Möglicherweise ereignet sich dieses Phänomen, nachdem der Stick im Windowsbetrieb war.
Navigiert man jedoch in das Verzeichnis /media, ist der problematische Stick vorhanden und läßt sich öffnen.
Dabei fällt auf, dass der Name eines Verzeichnisses ein Fragezeichensymbol mit einer schwarzen Raute enthält und in Klammern "invalid encoding" dahinter steht. Nimmt man ein Rename des Verzeichnisses vor, ersetzt das Fragezeichen also durch einen Buchstaben, entfernt die Klammern und loggt man sich aus gnome aus und wieder ein, wird der Stick korrekt gemountet.

Es scheint also ein Zusammenhang zwischen HAL-Mount und dem charset zu bestehen?
Kann mir das mal jemand genauer erklären? Hat das etwas mit /etc/login.conf oder mit .login_conf im Userverzeichnis zu tun?
Wie konfiguriert man sein Sytem optimal, damit so etwas nicht passieren kann?
 
am Besten googelst du dich da mal durch. Das ist besser, als wenn ich das machen muss :)
Weil es so sehr kompliziert ist, müsste ich das aber machen, um genau und umfassend zu antworten.

Erst mal ohne HAL.
Dann kannst du ein DOS-Dateisystem mounten und die benötigte codepage als Option mitgeben. Dazu solltest du dann wissen, wie die Dateien auf deinem DOS-System überhaupt behandelt werden. ich kenne es nur von älteren Windows und da war das die codepage=850
Neuere Windows können sicher UTF-8
Jedenfalls muss dein eigenes System diesen Zeichensatz jeweils auch können, sonst kann es damit nichts anfangen.
Dazu kannst vielleicht mal dies lesen: http://wiki.ubuntuusers.de/Windows-Partitionen_einbinden

Wenn HAL läuft, dann nutzt der eine ganze Reihe von Konfigurationsdateien.
Diese Dateien können vielleicht auch besser als Aktion-Dateien beschrieben werden.
Im Allgemeinen erkennt HAL bestimmte Sachen und benennt zugehörige Ereignisse. Diesen werden dann Aktionen zugeordnet. Das passiert in den Konfigurationsdateien
Das Treiben von HAL kann man beobachten, dazu dient der Befehl lshal.
lshal -l listet etwa, was derzeit erkannt wird.
lshal -m ist viel lustiger: da sieht man die aktuellen Ereignisse, also etwa, was da passiert, wenn ein Stick eingesteckt wird.
/usr/local/share/hal hat fdi und darunter zahlreiche solche Konfigurationsdateien, die von HAL genutzt werden.
Hier kannst du was verändern, oder neue hinzuschreiben. Dazu solltest du dich erst schlau machen und das ist sehr umständlich. Außerdem werden Änderungen womöglich bei einer Aktualisierung wieder überschrieben.
Hier ändern auch andere eine Menge, etwa dann, wenn du KDE oder GNOME installierst, dann können da schon vor-angepasste Konfigurationen eingebaut werden und natürlich gibt es auch speziell welche für FreeBSD selbst, ich glaube, die sind als Abhängigkeit in den Ports zu finden.
Ein gutes Beispiel dafür, was du nun machen könntest, nachdem du alles untersucht und herausgefunden hast, wie es denn funktioniert, zeigt /usr/local/share/hal/fdi/policy/20thirdparty/large_fat.fdi:
<?xml version="1.0" encoding="UTF-8"?> <!-- -*- SGML -*- -->

<deviceinfo version="0.2">
<device>
<match key="volume.fstype" string="vfat">
<append key="volume.mount.valid_options" type="strlist">large</append>
</match>
</device>
</deviceinfo

Irgendwann wurde in mount(8) die Option large für große Dateisysteme eingeführt. Dann funktionierte HAL bei solchen Systemen nicht mehr. Diese Konfigurationsdatei fügt nun die Option large als strlist Eintrag zu den volume.mount.valid_options hinzu, wenn der key volume.fstype den string vfat erkennt.
Also, mit lshal -m solltest du das verfolgen können, wenn der String vfat gesehen wird und was dann passiert.
Hier sähe ich eine Möglichkeit, für dein Dateisystem eine eigene Regel zu erstellen und die passende codepage zu setzen.

Allerdings kann es auch sein, dass so etwas von GNOME oder irgendjemand anders schon gemacht wurde und etwas anderes nun schief geht. Manchmal werden Begriffe umbenannt oder es fehlen irgendwelche Rechte oder was in der Art.

Jedenfalls ist der Umgang damit und mit all den unterschiedlichen Konfigurationsdateien zum Erbrechen und kann sich sehr leicht in Details verlaufen.
Empfehlenswerter ist sicher, gleiche Codepages auf allen Geräten einzusetzen und wenn das nicht so einfach möglich ist, die falschen Beschriftungen wo immer dies geht einfach zu ignorieren, eventuell in solch speziellen Fällen einfach ganz auf Automagie verzichten und manuell mit passender Codepage mounten.

Wobei mir gerade auch einfällt, dass deine Programme dies dann auch noch richtig darstellen müssen und was ich zum Beispiel mit GTK2 installiert habe, kann gar kein UTF-8 und da wäre ich also immer aufgeschmissen, wenn ich mich auf UTF-8 auf allen Dateisystemen festlege (was ich gemacht habe) und das dann von einer GUI mit GTK2 gar nicht korrekt dargestellt werden kann.

Noch ein Tip nebenbei, falls eine Umbenennung mal ansteht: iconv(1)
 
pit234a schrieb:
Wobei mir gerade auch einfällt, dass deine Programme dies dann auch noch richtig darstellen müssen und was ich zum Beispiel mit GTK2 installiert habe, kann gar kein UTF-8 und da wäre ich also immer aufgeschmissen, wenn ich mich auf UTF-8 auf allen Dateisystemen festlege (was ich gemacht habe) und das dann von einer GUI mit GTK2 gar nicht korrekt dargestellt werden kann.
Zum Vergrößern anklicken....
Ich kann mich an eine Meldung auf irgendeiner GTK-Entwicklermailingliste erinnern, wo gesagt wurde, daß GTK (und folglich GNOME) ab sofort nur noch UTF-8-Locales unterstützen. Ein System mit einer 8-bit-Locale wird als "buggy" betrachtet und ausdrücklich nicht unterstützt. Damit sind dann auch Einstellungen wie G_BROKEN_FILENAMES obsolet geworden und werden ignoriert.
Freilich sind die Programme, welche GTK- oder GNOME-Libraries verwenden, teilweise anders aufgelegt, aber sie müssen sich dann eigenständig darum kümmern.

Edit: Ach ja, hier war's: https://bugzilla.redhat.com/show_bug.cgi?id=708536
GLIB2, nicht GTK. Zitat: "non-utf8-locales can be considered not to exist"
 
Zuletzt bearbeitet:
Ahja, das erinnert mich daran: auf meinem PC laufen viele alte Anwendungen und jedenfalls kein GTK3 oder GNOME3. Mit alt meine ich auch, dass ich seit einiger Zeit keine Aktualisierungen mehr fahre. Man kann vielleicht sagen, dass ich mit meinem System auf Hold oder Freeze stehe und das hat dann den Stand 8.4 und etwa Mai dieses Jahres aus den Ports. Neuerungen seither fließen nicht ein und zuvor hatte ich GTK-Anwendungen nur als Beiwerk installiert und hauptsächlich QT(3) benutzt (es zumindest hauptsächlich versucht). Dass UTF-8 in manchen GTK-Anwendungen nicht sauber dargestellt wird, ist mir erst kürzlich aufgefallen und es hat mich nicht sonderlich belastet.

Es ist aber klar, wenn ich nun eine Anwendung derartige Probleme hat manche Codepages ignoriert, dann nutzt auch die mount-Option nichts.
nautilus habe ich offenbar installiert und eben mal aufgerufen. der macht ja auch einen Desktop?, jedenfalls stellt der bei mir UTF-8 sauber dar.

Was ich noch vergessen hatte und was natürlich auch ein guter Gedanke ist: Umlaute und Co in Dateinamen vermeiden. Das gilt für mich immer noch.
 
Rakor schrieb:
Oh wie toll... "Was interessiert mich mein Geschwätz von gestern?" Tolle Einstellung...
Zum Vergrößern anklicken....
Es ist halt die typische Einstellung im Gnome-Lager: "Wir werden uns diese verdammten User schon richtig™ erziehen!"
(Soll ich sagen, welchen Desktop ich besser finde? Soll ich? :))
 
Vielen Dank erstmal für diese ausführliche Antwort und die weiteren Antworten! Um den Fehler jetzt genau einzugrenzen und reproduzieren zu können, brauche ich noch ein paar Tips. Wie kann ich denn zunächst herausfinden, ob mein System (FreeBSD) auf UTF-8 gesetzt ist oder nicht, bzw. was überhaupt (wo) eingestellt ist? Gibt es da einen Befehl der das anzeigt? Ist es 'locale' ohne weitere Argumente? Was bedeutet das, wenn die Ausgabe von 'locale' für alles "C" ist? Ich weiß, dass man es systemweit in der /etc/login.conf oder in der /etc/rc.conf eintragen kann. Was ist besser, es in der login.conf oder in der rc.conf einzutragen? Gibt es eine Möglichkeit herauszufinden, mit welchem charset ein Verzeichnis oder eine Datei erstellt wurde?
Das Verzeichnis "/usr/local/share/hal/fdi/policy/20thirdparty/" ist bei mir leer. Brauche ist das überhaupt, wenn ich UTF-8 systemweit einstellen sollte? Welchen Standard verwendet denn WinXP?
 
nur kurz, mir fehlt die Zeit, denn das ist eine größere Sache.
Es ist ja nicht nur FreeBSD, also dein System darunter, es sind ja auch allerhand Anwendungen, die locale-Einstellungen nutzen.
Angefangen mit X, über ein Desktop-Environment bis hin zu Anwendungen, die unterschiedliche Bibliotheken nutzen und damit jeweils auch auf andere Settings zurückgreifen.
Einige Einstellungen werden dabei automatisch übernommen, andere müssen explizit angepasst werden.
Zum Beispiel funktionierte KDE3 default immer auf US-Englisch, ganz egal, wie das System eingestellt war oder was in X gesetzt wurde. Es hatte eigene Einstellungen und eigene Sprachpakete.
Daraus wird klar, dass nicht nur ein Befehl hilft. Vorausgesetzt, es soll alles möglichst gleich eingestellt werden.

Sodann gibt es grundsätzlich zwei oder mehr unterschiedliche Einstellungen, nämlich die codepage und die Sprache an sich.
Angenommen, du willst € und ÜÄÖ haben und nutzt deshalb ISO8859-15, hast aber als Sprache Englisch, dann kennt deine Sprache die ÖÄÜ gar nicht und du kannst die dann gar nicht anwenden. Meistens will man alles gleich haben.

Das Thema haben wir schon behandelt. Such mal nach "alles in Deutsch", vielleicht findet sich noch was.
UTF-8 ist bei meinem 8.4 noch immer nicht ganz unproblematisch.
 
Ich hab' mal numeriert:
cabriofahrer schrieb:
1. Was bedeutet das, wenn die Ausgabe von 'locale' für alles "C" ist?
2. Ich weiß, dass man es systemweit in der /etc/login.conf oder in der /etc/rc.conf eintragen kann. Was ist besser, es in der login.conf oder in der rc.conf einzutragen?
3. Gibt es eine Möglichkeit herauszufinden, mit welchem charset ein Verzeichnis oder eine Datei erstellt wurde?
4. Das Verzeichnis "/usr/local/share/hal/fdi/policy/20thirdparty/" ist bei mir leer. Brauche ist das überhaupt, wenn ich UTF-8 systemweit einstellen sollte?
5. Welchen Standard verwendet denn WinXP?
Zum Vergrößern anklicken....
  1. "C" ist ein Fallback, so eine Art Minimal-Locale. Es bedeutet halt, daß nichts gesetzt wurde.
  2. Wie es in der "rc.conf" geht, weiß ich nicht. In der login.conf fährt man damit wohl ganz gut, weil man auch variieren kann. Ich habe z. B. eine deutsche für meine Wenigkeit, aber den root auf "C" gelassen.
  3. Nicht i. a., nur manchmal können intelligente Programme einen "educated guess" hinlegen, z. B. der "file"-Befehl für eine Datei.
  4. Laß besser erst mal die Finger davon und schau, ob's systemweit hinreicht.
  5. Nur vom Hörensagen: UTF-8 und für manche internen Sachen UTF-16. Ältere Dateisysteme werden aber wohl "transparent" eingebunden, also nicht konvertiert.
Hier habe ich mal gepostet, wie man das für die Loginklasse "german" macht.
 
In Westeuropa verwendet Windows in der Regel cp1252 (das kann man iconv so mitgeben). Das wäre bei smbfs zum Beispeil mit dem Parameter -E=UTF-8:cp1252.

Bei msdosfs gebe ich nur ein -L=en_GB.UTF-8 mit, dass scheint dann schon das richtige zu verwenden, genauso bei fuse-smbnetfs, das bekommt ein -o local_charset=UTF-8 mit.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben