[PATCH] - 98_update.pm - Benutzung von copy anstatt move für restoreDir

[Markus Bloch]

Hallo zusammen,

momentan ist es so, dass bei einem update alle betroffenen Dateien in das restoreDir verschoben werden mit move() und anschließend die neue Version geschrieben wird. Das Problem dabei ist allerdings, das sämtliche Dateirechte (owner, group und Rechte) dabei verloren gehen und neu mit dem Usernamen unter dem fhem.pl läuft angelegt werden.

Ist in meinem Fall jedoch suboptimal, da FHEM mit root-Rechten auf meinem NAS läuft (ja, es geht nicht anders). Um jedoch Änderungen (als Entwickler) durchführen zu können via SMB/NFS, müssen die Dateien einem anderen User/Group gehören.

Nach jedem update muss ich also alle geupdateten Dateien wieder gerade biegen, weil sie mit mv immer gemoved werden. Wenn man dafür jedoch copy nimmt, bleiben die Rechte in takt, die Datei wird mit der neuen Version überschrieben, aber die Rechte stimmen weiterhin.

Ich habe daher einen Patch gemacht, der für dir restoreDir-Operationen copy() verwendet. Für den "MOV"-Befehl im Controlfile ist move() natürlich so geblieben.

Ich habe probehalber ein "update force" gemacht und siehe da, die Dateirechte stimmen noch alle.

Würde mich freuen, wenn das mit aufgenommen werden kann, weil es mir lästige Arbeit nach jedem update erspart.

Vielen Dank

Gruß
Markus

[justme1968]

da gab es vor einiger zeit schon mal einen thread zu da durch das move z.b. auch das executable flag für fhem.pl jedes mal verloren geht. damals war rudi dagegen.

leider finde ich gerade den thread und die begründung nicht mehr.

ich bin auch für ein copy statt einem move.

gruss
  andre

[rudolfkoenig]

Wenn ich mich an meine Begruendung recht erinnere: wenn ein move klappt, dann klappt wahrscheinlich auch ein move-back, das kann man aber fuer copy nicht sagen. Ich befuerchte, dass bei vollgelaufenen Festplatten damit eher ein Problem gibt, und das wuerde ich gerne vermeiden.

[justme1968]

wenn das copy fehl schlägt ist aber das original noch in ordnung. gilt das auf jeder plattform und in jedem fall auch für den move fall?

[rudolfkoenig]

Naja, "jeder plattform und in jedem fall" kann ich natuerlich nicht zusichern, aber nach meinem (zugegebenermassen alten) Stand wird bei einem move in einem Verzeichnis-Datei ein Eintrag hinzugefuegt, und in einem anderen eins entfernt. Beides "atomar" vom Kernel. Falls wir copy nehmen wuerden, mache ich mir keine Sorgen bei der Kopie, sondern erst, wenn update die "original" Datei nicht schreiben, und danach auch die Kopie nicht zurueckholen kann. Als Kompromiss koennte copy zur Sicherung, und move zur Wiederherstellung genommen werden, allerdings kann man copy cross-device machen, und dann klappt move nie.

[Markus Bloch]

Wenn aber ein copy in das restoreDir gemacht wird und update anschließend die neue Datei nicht schreiben kann (aufgrund von Rechten oder Speicherplatzmangel), dann ist die alte Datei doch noch immer da und muss nicht zurück kopiert werden. Ich sehe da jetzt kein Problem.

[justme1968]

das move aus File::Copy verwendet intern automatisch copy&delete wenn es quelle und ziel auf unterschiedlichen filesystemen liegen.

[rudolfkoenig]

Ich werde den Eindruck nicht los, dass ich plattgelabert wurde: ich habe jetzt den Patch eingespielt.

@Markus: das Problem ist da, ob es nur theoretisch oder auch praktisch vorkommt, das werden wir sehen.

@justme1968: ich habe mov mit regexp eingebaut, damit man "MOV www/pgm2/.*dark.* www/pgm2/darkstyle" machen kann.

[justme1968]

Ich werde den Eindruck nicht los, dass ich plattgelabert wurde

niemals. du hast dich nur von den voreilen überzeugen lassen.

@justme1968: ich habe mov mit regexp eingebaut, damit man "MOV www/pgm2/.*dark.* www/pgm2/darkstyle" machen kann.

das finde ich sehr gut

[rudolfkoenig]

Problem: Falls FHEM@FritzBox auf einem USB-Stick installiert ist, was wiederum mit FAT formatiert ist, dann geht copy schief: chmod als fhem user liefert EPERM. Vorschlaege fuer einen Ausweg? move?

[justme1968]

eigentlich wäre es komisch wenn das  move geht und das copy nicht. sobald das ziel nicht auf dem gleichen filesystem liegt wird intern doch auch nur ein copy und remove gemacht.

könnte es an etwas anderem liegen? umask zum beispiel? 

oder habe ich das problem nicht richtig verstanden?

[rudolfkoenig]

könnte es an etwas anderem liegen? umask zum beispiel? 

umask 0 hat das Problem behoben, das ist vmtl. die einfachste Loesung, falls jemand mit diesem Problem um die Ecke kommt. Und restoreDir per Symlink auf einem FAT-FS wird nicht unterstuetzt.