Re: linux und windows teilen sich eine vfat partition...
Andreas Pakulat schrieb:
Reinhold Plew wrote:
Andreas Pakulat schrieb:
Reinhold Plew wrote:
Andreas Pakulat schrieb:
Reinhold Plew wrote:
[...]
Naja, jaein, ich wuerde sagen dass kommt auf die Implementierung
des Suspend-To-Disk an, denn wenn der Wiederherstellt koennte er
ja mal fix die FAT neu einlesen.
Welches BS macht das so?
Ich kenne leider nur Win, Linux als Admin - Solaris und AIX hab ich
nur als Student genutzt. Und bzgl. Linux bin ich mir nicht ganz
sicher, kann das auch grad nicht testen.
Waere aber bei 2. Betrachtung vielleicht schon etwas problematisch:
Was ist wenn du ne Datei editiert hast und dann suspend machst.
Dann aenderst du die Datei mit nem anderen BS. Jetzt muss beim
REsume versucht werden die Aenderungen zusammenzubringen, was aber
oft nicht geht, oder einfach mit der Version aus dem Speicher
gearbeitet werden, was die Aenderungen (asu dem anderen BS) wieder
zerstoert....
das Prob hast Du ja auch schon ohne Suspend, bei Datenbanken wird
das über Locking-Mechanismen gelöst.
Ich denke, das mit entsprechenden Checksummen das Problem des
Editierens gelöst werden könnte: Du öffnest eine Datei zum Editieren
($editor merkt sich die Checksum), gehst in den Suspend, änderst die
Datei über einen anderen Weg, machst ein Resume und versuchst, Deine
Änderungen zu speichern; Nun stellt $editor fest, das sich die
Checksum geändert hat und gibt einfach eine Warnung aus.
Mal schauen wie der Vim das macht, der hat ja eh seine .swp Datei...
Vim kriegt das nciht mit. Aber Aenderungen an Dateien wuerde ich eh
immer erst schreiben bevor ich Suspende...
aber nun denke mal im Multiuser! Was ist denn dann?
Naja, im Multiuser macht nicht mal fix einer nen Suspend oder? Ich meine
ein echo 4 > /proc/acpi/sleep geht eh nur mit root Rechten und an ein
Multiusersystem kommen die User normalerweise nicht gleichzeitig ran, so
dass auch keiner den Powerknopf druecken kann.
Interessanter wäre aber eine Lösung, mit der ein System, welches aus
dem Suspend kommt, feststellen könnte, dass sich etwas an den
Partitionen/Daten geändert hat und zwar, _bevor_ es darauf zugreift.
Ich denke da an redundante Server, würde die Startzeit vermutlich
verringern.
Naja bei FAT ist das Ziemlich egal, da kannste mal fix die FAT neu
einlesen.
Manuell? M$ tut das ja nicht, ausser Du nimmst F5
Na Linux Kernel macht das sobald man auf die Partition zugreift :-)
Schaetze ich mal. Kann das nicht pruefen und kenne auch den Quellcode
nicht vom Kernel.
Bei ext2 bin ich mir grad nicht ganz sicher wie das dort mit neuen
Dateien laeuft, aber im Prinzip sollte ext2 kein Problem darstellen -
mal abgesehen von geoeffnet Files.
und genau um die geht es doch, wenn Du ein System hast, wo sich nach
dem resume $user einlogged, bekommt er bein vi[m] die vorher geöffnete
Datei (*.swp) wieder angeboten. Was aber, wenn das Original auf einer
Partition liegt, welche von anderen Systemen während des Supends
geändert wurde oder auch die Datei selbst?
Also ich hab noch keine verteilte Umgebung gesehen in der $User einfach
mal nen Softwaresuspend machen konnte. Ok, wenn ich meinen Schleppi
nehme und damit arbeite und der in den Suspend geht... Ich komme wieder
und jemand hat an den Dateien geschrieben ... Pech gehabt. Aber bei
siehst, da hat die/der Andere mal einfach die Datei geändert, welche
Du selbst bearbeitest und vi[m] merkt es nicht :-(
Und da denke ich, wäre es schön, wenn diese Änderung doch auffallen
würde.
Systemen wo viele Nutzer gmeinsam genutzte Dateien haben braucht man eh
passende Verwaltungssoftware, da reicht ne Windowsfreigabe nicht mehr
aus - das gibt schon Aerger ohne Suspend.
ich denke hier etwas abstrakt, ohne Bezug auf spezielle BSe
Eine Anwendung sollte in der Lage sein,
1. festzustellen, das eine Datei verändert wurde, welche sie
eigentlich selbst bearbeitet
2. festzustellen, das sie aus einem Suspend erwacht
(mächtig schwierig, weil der Suspend müsste den
laufenden Anwendungen ja mitteilen können, das er
aktiv wird)
Andreas
Reinhold
Reinhold
Reply to: