Re: konkurrierende Dateizugriffe

Marc Santhoff <M.Santhoff(at)t-online.de> wrote:
> was passiert eigentlich, wenn ein Prozeß ein Verzeichnis anlegt und dort
> Dateien reinschreibt und ein anderer Prozeß dieses Verzeichnis
> gleichzeitig mit "rm -r" löscht?

»rm -r« löscht sowohl Dateien (genauer gesagt deren Hard-
links) als auch Verzeichnisse. Dateien, die gerade ein
anderer Prozeß geöffnet hat, befinden sich weiterhin im
Zugriff des betreffenden Prozesses, auch wenn sie keinen
Namen (= Hardlink) mehr im Dateisystem haben.

Wenn ein Prozeß dagegen versucht, eine Datei in einem Ver-
zeichnis zu öffnen (oder anzulegen), das es nicht mehr
gibt, dann ist das natürlich ein Fehler (»No such file or
directory«).

Kannst Du trivial testen: Mach drei Terminal-Fenster auf,
im ersten tipp »tee foo« ein, im zweiten »tail -f foo«.
Jetzt gib mal testweise im ersten Fenster irgendwelchen
Blödsinn ein -- er wird im zweiten wieder ausgegeben (und
im ersten zusätzlich ge-echo't).

Jetzt such mal im dritten Fenster den inode der foo-Datei
heraus: »ls -i foo«. Nehmen wir mal an, es ist 1234567.
Jetzt suchen wir die Prozesse und deren Filedeskriptoren:
»fstat | grep 1234567« (Du mußt natürlich die richtige
inode-Nummer angeben). Das sollte jetzt genau zwei Zeilen
ausgeben (eine für's tee-Kommando und eine für's tail-
Kommando).

Und jetzt lösch einfach mal die Datei (im dritten Fenster):
»rm foo«. Mit »ls« kannst Du Dich überzeugen, daß der
Eintrag im Verzeichnis (der Name der Datei) wirklich weg
ist. Nichtsdestotrotz haben tee und tail die Datei immer
noch geöffnet, wovon Du Dich mit obigen fstat-Kommando
überzeugen kannst. Und Du kannst weiterhin irgendwas in
das erste Fenster (wo das tee-Kommando läuft) eingeben,
und Du kriegst es im zweiten Fenster ausgegeben.

Du kannst sogar das Verzeichnis löschen, in dem sich der
foo-Dateiname befand. Das stört überhaupt nicht. Sobald
ein Prozeß eine Datei geöffnet hat, ist der Filedeskriptor
direkt mit dem inode (d.h. sozusagen mit dem Speicherplatz
auf der Festplatte) verbunden. Der Dateiname und das Ver-
zeichnis, das zum Öffnen der Datei verwendet wurde, ist
nicht mehr von Belang.

> Der schreibende Prozeß schert sich i.d.F. nicht um das Vorhandensein von
> Verzeichnissen, wenn sie fehlen legt er sie neu an.

Dann gibt's natürlich keine Fehlermeldung. :-)

> Kann es dadurch gefährliche Situationen bzw. ein inkonsistentes
> Dateisystem geben?

Es gibt keine regulären Userland-Funktionen, die ein in-
konsistentes Dateisystem herbeiführen können (abgesehen
natürlich von Kernel-Bugs).

UNIX ist ein Multitasking- und Multiuser-System. Es ist
darauf ausgelegt, daß mehreren Benutzer und mehrere Pro-
zesse auf dieselben Dateisysteme, dieselben Verzeichnisse
und dieselben Dateien zugreifen (sofern es die Zugriffs-
rechte erlauben). Daher darf _keine_ Kombination von Da-
teioperationen zu Inkonsistenzen des Dateisystems führen.

Ganz früher (in historischen UNIX-Versionen) konnte man
durch gewisse Dinge Probleme verursachen. Zum Beispiel
war es möglich, Hardlinks auf Verzeichnisse zu legen.
Das geht in heutigen Systemen aber nicht mehr.

Natürlich kann man durch direkten Zugriff auf das Device
das Dateisystem kaputtmachen (z.B. mit fsdb). Aber das
passiert nicht »versehentlich«, erfordert root-Rechte
(und einen entsprechenden Secure-Level), und wenn man
sowas benutzt, weiß man eh, was man tut (oder sollte es
zumindest wissen).

Gruß
   Olli

-- 
Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.
"And believe me, as a C++ programmer, I don't hesitate to question
the decisions of language designers.  After a decent amount of C++
exposure, Python's flaws seem ridiculously small." -- Ville Vainio
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message