> 1) Welche Verwaltungsinfos? Wozu?
Beispiele habe ich doch schon geliefert! Wenn Du etwas ausprobieren möchtest, kannst Du ja mal ein "tune2fs -l /dev/<i>device-mit-ext3-oder-ext2</i>" eingeben. Da findest Du beispielsweise das letzte Mount-Verzeichnis, letzten Mount-Zeitpunkt u.ä. Das Gleiche gilt auch für Dateien: Auch, wenn Du nur eine Datei "anschaust" (ein "cat datei >/dev/null" reicht), wird ein Zeitstempel für "letzter Zugriff auf den Inhalt dieser Datei" gesetzt (die "atime" (access time)),- immer vorausgesetzt, das Dateisystem ist read-write gemountet.
> ext2/3 sind die Festplatten-Dateisysteme. Wir sprechen hier aber von den Wechselmedien, im speziellen vom physikalisch nicht (be)schreibbaren DVD-ROM.
Jepp. Daher kann ein Dateisystem von diesem Medium nur read-only gemountet werden. Das garantiert wiederum, dass kein Bit des Datenträgers verändert wird, egal, ob das physikalisch überhaupt geht oder nicht.
> Jenes der harddisk, oder nicht?!
Um genau zu sein: Bei jedem Dateisystem, dessen Typ diese Zeitstempel unterstützt und welches read-write gemountet wurde.
> >Diese Bits liegen übrigens im sog. "Superblock", welcher die zentrale Verwaltungsstruktur des Dateisystems ist.
> "Des" Dateisystems? singular? Hat nicht jedes Speichermedium sein eigenes? Wenn ja, hat dann jedes seines eigenen "Superblock"?
Sorry, "eines Dateisystems". Ja, jedes hat seinen eigenen Superblock, wenn dieser je nach Dateisystemtyp auch sehr unterschiedlich aussehen kann.
> Wenn das so ist, wäre auch meine, oben erwähnte Fehlermeldung bei MANCHEN floppys EINERSEITS verständlich:
Exakt.
> > Sollte dieser kaputt sein, hast Du kein Dateisystem mehr, sondern nur noch eine Ansammlung von Bits...
> Und wie wird der kaputt? Ist das eine (un)heilbare Katastrophe?
Gerade Floppies sind notorisch unzuverlässige Medien (Ausnahmen bestätigen nur die Regel). Entweder der Datenträger versagt an der Stelle, wo das Formatier-Tool (mke2fs, mkreiserfs, mkdosfs, ...) den Superblock untergebracht hat, oder beim Schreiben des Superblocks wird die Floppy fälschlicherweise ausgeworfen, oder der Strom vfiel beim Schreiben aus, oder das Dateisystem wurde auf einem anderen, leicht dejustierten Laufwerk erzeugt, so dass das eigene gute Laufwerk damit nicht klar kommt usw. usf. Murphy kennt 1000e Wege. <img src="
http://www.pl-forum.de/UltraBoard/Images/Happy.gif" border="0" align="middle">
> Na eben nicht! Es hat NICHT ro gemountet.Mit der Frischling-unverständlichen "schreibgeschützt"-Ansage wars vorbei!
<i>*ratlos schau*</i> Keine Ahnung, was da schiefgelaufen sein mag. Da Du später schreibst, dass es mit einigen Floppies klappt, mit anderen dagegen nicht: Schmeiss die, mit denen es nicht geht, weg. Sorry, besseren Rat habe ich da nicht mehr parat.
> 2) Sollte es nicht von sich aus das drive, um das es geht, erkennen? A la:"Aha, meine userin will das DVD-ROM gemountet haben. In, mit diesem Gerät is nix mit schreiben, also häng ich's "ro" ein, obwohl das nicht explizit in der fstab steht"
> Bzw, wie bereits erwähnt, wieso ist nicht "ro" die default-Konfig fürs DVD-ROM ?
Hm. Hier prallen unterschiedliche Ideologien aufeinander, wie Betriebssysteme oder Software im Allgemeinen zu funktionieren haben.
<li>Die eine Richtung möchte, dass das Betriebssystem versucht, den Anwender zu unterstützen, in dem es die Eingaben der Anwenderin interpretiert und ggf. auch stillschweigend Angaben korrigiert. Die Windows-Betriebssysteme sind dafür bekannt. In überspitzter Manier könnte man sagen, der Rechner sollte nur einen grossen roten Knopf haben. Wenn man den drückt, macht der Rechner direkt, was man möchte. <img src="
http://www.pl-forum.de/UltraBoard/Images/Happy.gif" border="0" align="middle"> Oder man denke an Textverarbeiteungen, die automatisiert jeden Buchstaben nach ". " gross schreiben, weil sie davon ausgehen, dass ein neuer Satz begonnen hat und jeder Satz mit einem Grossbuchstaben anzufangen hat.
<li>Die andere Richtung geht davon aus, dass der Rechner in erster Linie ein Werkzeug ist, dass exakt das macht, was der Anwender damit machen möchte. Die Anwenderin wird als mündig genug erachtet, dass die weiss, was sinnvoll ist und was nicht. Sollte eine geforderte Aktion nicht durchführbar sein, wird mit einer Fehlermeldung abgebrochen. UNIX dürfte das eingängigste Beispiel für diese Philosophie sein. Oder man denke an einen Compiler (der menschenlesbaren Programmcode in ausführbare Programme übersetzt). Natürlich könnte der versuchen, einfache Syntaxfehler selbst zu beheben, aber da er nicht "wissen" kann, ob er die gewollte Programmlogik damit nicht verfälscht, schreibt er nur eine Fehlermeldung und erwartet, dass die Programmiererin den Fehler behebt.
Ich will nicht abstreiten, dass hier eine Automatik praktisch sein könnte. Aber traditionell ist Mounten/Unmounten Administratorinnen-Tätigkeit. UNIX geht davon aus, dass a) diese weiss, was sie tut und b) das die Administratorin auch schon mal Sachen machen können muss, die sonstige Userinnen nicht dürfen. Aus b) folgt, dass sie sich beispielsweise auch über die Zugriffsrechte von Dateien hinwegsetzen darf und aus a), dass <i>immer</i> versucht wird, das zu tun, was die Administratorin verlangt. Ein simples Betriebssystem sollte sich schliesslich nicht anmassen, besser als die Administratorin zu wissen, was sinnvoll ist und was nicht.
Dieses Thema reicht für mindestens 5 weitere vollgeschriebene Threads <img src="
http://www.pl-forum.de/UltraBoard/Images/Happy.gif" border="0" align="middle">. Ich persönlich halte es eher mit der UNIX-Philosphie (keine Überraschung, was?). Man denke beispielsweise mal an Medien, die sowohl beschreibbar als auch schreibgeschützt sein können, so wie Floppies. Wenn ich aus Versehen den Schreibschutz aktiviert lasse, erhalte ich direkt beim Mounten eine Fehlermeldung und nicht erst etwas über "Zugriff verboten/Permission denied", wenn ich eine Datei schon bearbeitet habe und dann endlich speichern will...
Jochen
)
