FHEM Forum

FHEM - Entwicklung => FHEM Development => Thema gestartet von: Markus Bloch am 29 März 2015, 14:13:55

Titel: [PATCH] - 98_update.pm - Benutzung von copy anstatt move für restoreDir
Beitrag von: Markus Bloch am 29 März 2015, 14:13:55
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
Titel: Antw:[PATCH] - 98_update.pm - Benutzung von copy anstatt move für restoreDir
Beitrag von: justme1968 am 29 März 2015, 14:44:17
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
Titel: Antw:[PATCH] - 98_update.pm - Benutzung von copy anstatt move für restoreDir
Beitrag von: rudolfkoenig am 29 März 2015, 15:49:55
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.
Titel: Antw:[PATCH] - 98_update.pm - Benutzung von copy anstatt move für restoreDir
Beitrag von: justme1968 am 29 März 2015, 15:52:50
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?
Titel: Antw:[PATCH] - 98_update.pm - Benutzung von copy anstatt move für restoreDir
Beitrag von: rudolfkoenig am 29 März 2015, 16:04:17
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.


Titel: Antw:[PATCH] - 98_update.pm - Benutzung von copy anstatt move für restoreDir
Beitrag von: Markus Bloch am 29 März 2015, 16:09:23
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.
Titel: Antw:[PATCH] - 98_update.pm - Benutzung von copy anstatt move für restoreDir
Beitrag von: justme1968 am 29 März 2015, 16:14:08
das move aus File::Copy verwendet intern automatisch copy&delete wenn es quelle und ziel auf unterschiedlichen filesystemen liegen.
Titel: Antw:[PATCH] - 98_update.pm - Benutzung von copy anstatt move für restoreDir
Beitrag von: rudolfkoenig am 29 März 2015, 17:44:39
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.
Titel: Antw:[PATCH] - 98_update.pm - Benutzung von copy anstatt move für restoreDir
Beitrag von: justme1968 am 29 März 2015, 17:47:58
Zitat
Ich werde den Eindruck nicht los, dass ich plattgelabert wurde
niemals. du hast dich nur von den voreilen überzeugen lassen.

Zitat
@justme1968: ich habe mov mit regexp eingebaut, damit man "MOV www/pgm2/.*dark.* www/pgm2/darkstyle" machen kann.
das finde ich sehr gut :)
Titel: Antw:[PATCH] - 98_update.pm - Benutzung von copy anstatt move für restoreDir
Beitrag von: rudolfkoenig am 14 April 2015, 20:18:02
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?
Titel: Antw:[PATCH] - 98_update.pm - Benutzung von copy anstatt move für restoreDir
Beitrag von: justme1968 am 14 April 2015, 23:38:05
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?
Titel: Antw:[PATCH] - 98_update.pm - Benutzung von copy anstatt move für restoreDir
Beitrag von: rudolfkoenig am 15 April 2015, 07:37:20
Zitat
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.