Nach SuSE 10.0-Update: Probleme mit Schreibrecht auf gemounteter vfat-Partition

[johnfrum]

Liebe Leute,

seit einem kürzlich per Yast-Online-Update (you) vollzogenen Update meines SuSE-10.0-Systems stehe ich vor dem Problem, dass ein vfat-Dateisystem nicht mehr einwandfrei eingebunden wird: Obwohl der Eintrag in der Datei /etc/fstab m. E. korrekt ist

/dev/hdb6 /windows/D vfat rw,user,gid=users,uid=roland,umask=000,utf8=true 0 0

habe ich auf der vfat-Partition keine dauerhafte (!) Schreibberechtigung mehr - genauer: Man kann zwar unmittelbar nach dem Start des Systems auf diese Partition schreiben, d. h. z. B. aus der Kommandozeile eine neue Datei anlegen per

ls -l > temp.out

Ediere ich nun aber eine bereits vorhandene Datei per Emacs und versuche, diese auf der vfat-Partition zu speichern, erhalte ich merkwürdigerweise eine Fehlermeldung der Art "auf das Dateisystem kann nicht geschrieben werden". Noch merkwürdiger: Im Anschluss an diese versuchte Emacs-Dateispeicherung klappt nun auch das Anlegen einer neuen Datei aus der Kommandozeile nicht mehr, d. h.

ls -l > temp2.out

führt nunmehr auch zu einer Fehlermeldung a la "read-only filesystem". (Genauer Wortlaut der Fehlermeldungen auf Anfrage.)

Reichlich seltsam, nicht? Ich habe bereits mehrere Stunden erfolglos herumprobiert - u. A. mit den unterschiedlichen Optionen in der fstab-Zeile. Merkwürdig erscheint mir daran v. A.: dieses "Vergessen" der anfangs offenbar einwandfrei erkannten Schreibberechtigung, das erst dann in Erscheinung tritt, wenn ich per Emacs (oder vermutlich auch einem anderen Anwendungsprogramm) auf die Partition schreiben möchte, im Anschluss daran jedoch auch einfache Schreiboperationen aus der Kommandozeile heraus betrifft.

An den "rw"-, umask- und uid-/gid-Einstellungen liegt es ja wohl augenscheinlich nicht, und es macht auch keinen Unterschied, wenn ich unter root versuche, auf diese Partition zu schreiben. Auch hier tritt der oben beschriebene Fehler auf.

Hat jemand von euch evtl. eine Idee, woran dieses Problem liegen könnte bzw. was man in diesem Zusammenhang noch versuchen könnte? Ich hatte zunächst auch die Einstellung zur Zeichencodierung der Datei- und Verzeichnisnamen (siehe fstab: "utf-8") unter Verdacht und dass hier evtl. eine Inkompatibilität zu den MULE-Einstellungen von Emacs bestehen könnte, aber dies erklärt nicht die merkwürdigen Interdependenzen mit dem Dateischreiben aus der Kommandozeile - deswegen sollte das Problem doch wohl eher tiefer liegen.

Vielen Dank und Gruß

Roland

[klopskuchen]

Was sagt ein "mount |grep/dev/hdb6" vor und nach der Änderung der unentschlossenen Berechtigung?

ps.

/windows/D

Filedeskriptoren (Dateien, Verzeichnisse, Netlinks...) sollten aus mind. drei Zeichen bestehen. Im worst case setzt irgendein Programm eine Umgebungsvariable D, welche vom Kommandointerpreter ersetzt wird. Dann ists vorbei mit /windows/D.


MfG, Klopskuchen

[Janka]

/windows/D

Filedeskriptoren (Dateien, Verzeichnisse, Netlinks...) sollten aus mind. drei Zeichen bestehen. Im worst case setzt irgendein Programm eine Umgebungsvariable D, welche vom Kommandointerpreter ersetzt wird. Dann ists vorbei mit /windows/D.

Solange man nicht /windows/$D schreibt wird ja wohl keine Variable eingesetzt.

Außerdem sind das keine Filedeskriptoren, sonderm Dateinamen, bzw. Pfade. Filedeskriptoren sind ein Konstrukt aus POSIX-libc.

Janka

[klopskuchen]

Außerdem sind das keine Filedeskriptoren, sonderm Dateinamen, bzw. Pfade. Filedeskriptoren sind ein Konstrukt aus POSIX-libc.

Ob der Kern erst die Inodennummer für windows rauskramt, unter der nach D guckt, dessen Inodennummer nimmt um endlich an den begehrten Bytesalat zu kommen, interessiert mich in den meisten Fällen weniger (es sei denn es hakelt).
Den Gebrauch des ursprünglichen "Ritchie-Integers" als Metabegriff hab ich übrigens nicht erfunden.Der wird seit Jahrzehnten von Dozenten zum besseren Verständnis, bei der Einführung in die Funktionsweise von Betriebssystemen praktiziert. Pragmatisch aber plausibel. Denn was ist besser als ein "Zeiger auf eine Datei". (Es sei denn es sind C-Programmierer in der Nähe, dann gibts Krach. )

Solange man nicht /windows/$D schreibt wird ja wohl keine Variable eingesetzt.

Jepp, voll erwischt. Auf die Schnelle keine Quelle, im Ergebnis falsche Begründung. Ich hoffe ich habe es in irgendeinem Standard gelesen, sonst mach ich mich zweimal zum Obst und der OP schlägt die Hände über dem Kopf zusammen.


MfG, Klopskuchen

[killerhippy]

Ich tippe mal auf ein nicht konsistentes Dateisystem oder eine kaputte Platte, wodurch die Partition automatisch bei Dateisystemfehlern ro gemountet wird.

Mal ein Windows-scandisk drueber laufen lassen oder fsck.vfat und ggfs. ein badblocks im ro-Mode.