Re: konkurrierende Dateizugriffe

On Mon, Mar 07, 2005 at 05:18:47PM +0100, Marc Santhoff wrote:
> Am Mo, den 07.03.2005 schrieb Oliver Fromme um 16:33:
> [...]
> > > > [...]
> > > > Gerade vorhin hatte ich eine tar-Datei mit einem Hex-Editor
> > > > geöffnet, an deren Ende das tar-Kommando immer noch munter
> > > > seine Daten anhängte. Wieso sollte das nicht gehen? Wieso
> > > > sollte tar (oder die meisten anderen Kommandos) seine Da-
> > > > teien locken? Das schränkt doch nur unnötig die Möglich-
> > > > keiten ein, die man hat.
> > >
> > > Das mein' ich doch: adäquat heißt hier, schreiben verboten, lesen für
> > > andere Prozesse möglich.
> >
> > Nein, natürlich dürfen auch andere Prozesse schreiben. In
> > obigem konkreten Beispiel haben _beide_ Prozesse schreibend
> > auf die Datei zugegriffen: Ich hatte den Header der tar-
> > Datei mit einem Hex-Editor verändert, während (gleichzei-
> > tig) der tar-Prozeß noch in die Datei reinschrieb. Es gab
> > keinen Grund, darauf zu warten, bis der fertig ist.
> >
> > Daß man beim Arbeiten durch unnötige Mechanismen behindert
> > wird, ist ja auch eher eine Windows-Domäne. ;-)
>
> Wahrscheinlich ist das auch der Grund für die unterschiedlichen
> Auffassungen: Windows ist für einen grundlegend anderen Zweck geschaffen
> als das Basissystem von FreeBSD.

Ja - Windows wurde zum Zweck geschaffen Geld zu verdienen.
Aber abgesehen davon ist das unter Windows eine aufgesetzte
Limitierung aus Kompatibilität zum alten Krempel.
Der NT Kernel kann das eigendlich auch.
Aber Windowsprogrammierer erwarten halt sorglosen Umgang mit Daten.

> Bei den üblichen binären proprietären Formaten vieler Programme aus der
> Anwendungsdomäne (das übliche halt, alles was mit "Office" gemeint ist -
> nicht nur von Microsoft sondern auch alle anderen auf Windows, Corel,
> Autodesk, usw.) ist es normalerweise ein Problem, wenn mehrere Instanzen
> des Programms auf eine Datei gleichzeitig schreibend zugreifen.

Eigendlich nicht - eine Anwendung muss das nur ordendlich designen.

> Allerdings muß das vom Dateisystem abhängen, denn der Inhalt von
> tar-Archiven ist ja auch nicht immer nur Text.

Ein File ist letzlich eine Ansammlung von Bytes - das ist es dann aber
auch schon.
Das Spielchen funktioniert natürlich auch mit msdosfs.

> Unter FreeBSD wird das anders gehandhabt, das finde ich ziemlich
> interessant. Da ich aus Zeitmangel die Grundlagen aber noch nicht
> gelesen habe, kann ich nur spekulieren: UFS/FFS fängt konkurrierende
> Zugriffe auf die selbe Zuordnungseinheit sicher ab? Es macht den
> Eindruck ...

Nein - du musst wissen was du tust.
Der Kernel führt nur Aktionen aus die es bekommt - von welchem Prozess
ist dabei egal.
Wenn zwei Prozesse gleichzeitig in einer Datei schreiben muss dass
schon irgendwie koordiniert passieren - der Oliver hat mit seinem
Hexeditor auch nur den Bereich verändert, von der er wusste, dass der
tar bereits damit fertig ist.

> Du sagst also, den Fall der Dateikorruption durch gleichzeitige
> schreibende Zugriffe kann es auf FreeBSD nicht geben?

Natürlich kann das passieren.
Wenn der Olivers hexeditor sein tar am Anfang mit nullen gefüllt hätte
wärs ja auch nachher platt gewesen.

-- 
B.Walter                   BWCT                http://www.bwct.de
bernd(at)bwct.de                                  info(at)bwct.de
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message