updatefhem backup Problem

Begonnen von erwin, 24 Dezember 2011, 02:11:13

Vorheriges Thema - Nächstes Thema

erwin

                                                   

Hi,

ich hatte ein Problem mit der backup Funktion:

updatefhem backup style.css
  Undefined subroutine &main::copy called at /opt/lib/FHEM/99_updatefhem.pm
line 70.

es funktioniert bei mir, wenn ich in die 99_updatefhem.pm folgendes
Statement einbaue:
   use File::Copy;

Frage: liegt das an meinem Setup (QNAP419P) oder Perl?? (V 5.10.0)

l.g. erwin

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
FHEM aktuell auf RaspberryPI Mdl 1-4
Maintainer: 00_KNXIO.pm 10_KNX.pm
User: CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT, 1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,..,MQTT2, KNX, SONOFF, mySENSORS,....
Hardware:  Busware ROT, Weinzierl IP731, 1-Wire GW,...

Guest

Originally posted by: <email address deleted>

Hi Erwin,

habe heute zum ersten Mal "updatefhem backup" als Befehl versucht um ein
FullBackup vor dem update durchzuführen.
Mit dem gleichen Ergebnis wie bei dir.

Ich bekomme die Fehlermeldung:  
" Undefined subroutine &main::copy called at /usr/share/fhem/FHEM/
99_updatefhem.pm line 64. "

Sieht für mich ziemlichen Laien so aus, als wenn da in perl ein Modul
nachinstalliert werden muss.
Aber vielleicht kann sich da ein erfahrener Leser hier mal zu äußern, das
würde uns sicher weiter bringen...

Ciao,
Jörn

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

Guest

Originally posted by: <email address deleted>

Also Leute, Erwin hatte die Lösung ja schon bekanntgegeben:

>   es funktioniert bei mir, wenn ich in die 99_updatefhem.pm folgendes
Statement einbaue:
>   use File::Copy;

>Frage: liegt das an meinem Setup (QNAP419P) oder Perl?? (V 5.10.0)

Antwort: Nein es ist einfach schlampig programmiert

Im Übrigen führt "updatefhem backup" auf der Fritz!Box zum Absturz von
fhem, im (telnet) Log steht anschließend:

Use of uninitialized value $commandchain[1] in string eq at
./FHEM/99_updatefhem
Undefined subroutine &main::copy called at ./FHEM/99_updatefhem.pm line 64.

Ergänzt man 99_updatefhem um das, von Erwin vorgeschlagene Statement "use
File::Copy;", stürzt fhem zwar nicht mehr ab, macht aber auch sonst nichts,
außer
Use of uninitialized value $commandchain[1] in string eq at
./FHEM/99_updatefhem

Es stellt sich heraus, daß updatefhem backup einen weiteren Parameter haben
möchte, das Fehlen dieses Parameters wird nicht abgefangen.

Gibt man "updatefhem backup abc" ein, wird ein Verzeichnis /tmp/FHEM_Backup
erstellt, das einfach eine Kopie von /fhem/FHEM darstellt, also keineswegs
die Kriterien für einen vollwertigen Backup erfüllt.

Im Übrigen ist es denkbar unschlau auf der Fritz!Box einen "Backup" nach
/tmp/ zu schreiben, da dieses Verzeichnis bei einem reboot der Fritz!Box
gelöscht und von der Firmware neu erstellt wird.

Was auch noch fehlt an updatefhem, ist eine definitive Rückmeldung, ob und
was es gemacht hat. Also etwa Dateien bla, bla, bla ersetzt, oder keine
Aktion notwendig oder sonst irgendein hilfreicher Kommentar, der dem
Anwender das Ergebnis der Aktion meldet.

@RueBe: Zurück auf los, Hasuaufgaben machen und _brauchbaren_ Code
erstellen.

@Rudi: Nicht jeden unkontrolliert im SVN herumtoben lassen. Bitte eine
Freigabeprozedur vorschalten.

Ignisquivir

Fritz!Box 7390 (84.05.07-21400 ), Fhem 5.2 – 7390 SVN, 2xCUL V 1.44 CUL868,
2xHM-LC-Sw4-SM, 1xHM-LCSw1-FM, KS300



--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

Guest

Originally posted by: <email address deleted>

Außer dem fehlenden "use File::Copy;", wie bereits vom Erstposter erwähnt,
ist in Zeile 57

"if($commandchain[1] eq "") {        "

zu lesen, das ist natürlich krass, Da das Element $commandchain[1] nur
erzeugt wird, wenn an der Stelle etwas in der Befehlszeile steht, hat es
wenig Sinn das Teil auf Vorhandensein ohne Inhalt zu prüfen:

"if(!$commandchain[1]) { "

ist an diese Stelle hilfreich. Ich habe die reparierte 99_updatefhem.pm
angehängt, wer sich berufen fühlt, mag sie im SVN einchecken.

An dem festeingestellten Backupverzeichnis "/tmp/FHEM_Backup" habe ich
nichts verändert, empfehle aber denen, die diese Form des Backup auf der
Fritz!Box nutzen wollen, in der fhem.cfg "attr global backupdir
/var/InternerSpeicher/FHEM_Backup" einzutragen.

Für fhem/commandref.html#updatefhem empfehle ich:

"updatefhem updatefhem [backup] [filename]

Update the fhem modules and documentation from a nightly SVN checkout. For
this purpose fhem contacts http://fhem.de/fhemupdate, compares the stored
timestamps of the local files with the file list on the server, and
downloads the files changed on the server. For all downloaded modules a
reload will be scheduled if the corresponding module is loaded.

If an explicit filename is given, then only this file will be downloaded.

Note: if the main program (fhem.pl) is changed, a manual restart of fhem
will be necessary to apply the changes.

If backup is specified, then the old files are saved before overwriting
them. They are copied to the folder given in fhem.cfg as "attr global
backupdir mybackupdir"  or, by  default, to /tmp/FHEM_Backup. Please check
if the fhem user has the rights to create the desired folder for backup.

Attributes

    backupdir
    A folder where updatefhem will store all files from modpath before
executing the update. Please check if the fhem user has the rights to
create this folder.

    Note: this is a global attribute, set in fhem.cfg, e.g.
        attr global backupdir /Volumes/BigHD"
*
*Man beachte: Es können entweder _alle_ oder _eine_ Datei aktualisiert und
gesichert werden, etwas wie "up(datefhem) backup *.pm" funktioniert,
mindestens auf meiner Fritz!Box, nicht.*

*Zusätzlich wäre zu überlegen, anstelle der Ausgabe einer
Handlungsaufforderung

"if($f eq "fhem.pl") {
      $ret .= "updated fhem.pl, restart of fhem is required\n";"

gleich programmatisch einen Neustart mit "shutdown restart" zu veranlassen.*

*Ignisquivir

Fritz!Box 7390 (84.05.07-21400 ), Fhem 5.2 – 7390 SVN, 2xCUL V 1.44 CUL868,
2xHM-LC-Sw4-SM, 1xHM-LCSw1-FM, KS300, 1xEUL, 2x HOPPE Fenstergriff
SecuSignal*

**
*
   
   
     
     
     
     
     

       

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

rudolfkoenig

                                                   

> Ich habe die reparierte 99_updatefhem.pm angehängt, wer sich berufen fühlt,
> mag sie im SVN einchecken.

Da von RueBE eine Weile lang nix kam, habe ich mich ploetzlich zustaendig
gefuehlt :) Und weil update mit backup auf meinem perl mangels copy()
abgestuerzt ist, habe ich mich entschlossen das Problem anders zu loesen:

  If backup is specified, then the complete FHEM directory (containing the
  modules and .gplot files) will be saved into a .tar.gz file with a timestamp
  in the modpath/FHEM.backup directory or to a directory specified by the
  backupdir global attribute. Note: tar and gzip must be installed to use this
  feature.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

Guest

Originally posted by: <email address deleted>

> Da von RueBE eine Weile lang nix kam, habe ich mich ploetzlich zustaendig
> gefuehlt :) Und weil update mit backup auf meinem perl mangels copy()
> abgestuerzt ist, habe ich mich entschlossen das Problem anders zu loesen:

Das ist ganz in meinem Sinn :-)

>   If backup is specified, then the complete FHEM directory (containing the
>   modules and .gplot files) will be saved into a .tar.gz file with a
timestamp
>   in the modpath/FHEM.backup directory or to a directory specified by the
>   backupdir global attribute. Note: tar and gzip must be installed to use
this
>   feature.

Wäre es an der Stelle nicht sinnvoll gleich die aufwändigen
Backupmöglichkeiten pro einzelnem Device-Log zu eliminieren ? Das schafft
Klarheit.


Ignisquivir

Fritz!Box 7390 (84.05.07-21400 ), Fhem 5.2 – 7390 SVN, 2xCUL V 1.44 CUL868,
2xHM-LC-Sw4-SM, 1xHM-LCSw1-FM, KS300, 1xEUL, 2x HOPPE Fenstergriff
SecuSignal





--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com