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

Begonnen von Markus Bloch, 29 März 2015, 14:13:55

Vorheriges Thema - Nächstes Thema

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
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

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
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

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?
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

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.
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

justme1968

das move aus File::Copy verwendet intern automatisch copy&delete wenn es quelle und ziel auf unterschiedlichen filesystemen liegen.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

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

ZitatIch 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 :)
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

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?
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

rudolfkoenig

Zitatkö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.