Originally posted by: <email address deleted>
updatefhem backup erzeugt Archiv mit Dateinamen die z.B. so aussehen:
FHEM.2012-05-22_22:21:29.tar.gz
Ein *tar tvfz FHEM.2012-05-22_21\:21\:29.tar.gz* ergibt bei mir (unter
Ubuntu 12.04):
tar (child): Kann nicht mit FHEM.2012-05-22_21 verbinden: Auflösung
fehlgeschlagen
gzip: stdin: unexpected end of file
tar: Child returned status 128
tar: Error is not recoverable: exiting now
*tar tvfz /usr/local/lib/FHEM.backup/FHEM.2012-05-22_21\:38\:25.tgz*funktioniert komischerweise ?!....
Unter den Linux Filesystemen sind wohl alle verwendeten Zeichen erlaubt.
Keine Ahnung warum sich tar im 1. Beispiel verschluckt.
Allerdings glaube ich zu wissen, daß der ":" unter NTFS "suboptimal" ist.
Ich verwende FHEM nicht unter Windows, aber geht das da nicht schief?
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
hallo peter,
Am Dienstag, 22. Mai 2012, 14:30:28 schrieb PanTau:
> updatefhem backup erzeugt Archiv mit Dateinamen die z.B. so aussehen:
> FHEM.2012-05-22_22:21:29.tar.gz
>
> [...]
da gebe ich dir absolut recht.. der filename ist etwas, sagen wir mal,
unglücklich gewählt.. ich hatte das so aus dem script übernommen und lediglich
von .tgz auf .tar.gz umgestellt.
ich habe gerade 99_updatefhem in dieser hinsicht geändert. der filename sieht
nun so aus:
FHEM-20120524_092616.tar.gz
im laufe des tages werde ich die änderungen einchecken, ist dann ab morgen
über updatefhem zu aktualisieren.
gruss martin
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hallo Martin,
die Änderung bzgl. Datum/Zeit macht Sinn und ist notwendig.
Warum hast Du aber .tgz in .tar.gz geändert?
Persönlich finde ich tgz viel schöner, aber wichtiger ist, daß ich (und
evtl. auch andere) Scripte habe, die die Backups
"weiterverarbeiten". Die muß ich nun anpassen (die suchen nach *.tgz), geht
schnell, kein großes Problem, aber warum?
tgz ist etabliert, kurz, nicht unüblich, verstößt gegen keine Standards und
funktioniert auf allen Platformen.
Ich finde Abwärtskompatibiltät wichtig und würde die nur aus wichtigem
Grund verletzen:
Bugfix, Featureerweiterung, Kompatibilität zu mehr/neuen Platformen (aber
auch das kann man eigentlich immer abwärtskompatibel gestalten)
Zwar kann der Modulowner machen was im besser gefällt, aber "lohnt" sich
das?
Vermutlich habe ich einen anderen wichtigen Grund übersehen?
Wenn nicht würde ich ähnlich bei FHEM.backup vs. backup argumentieren...
Zusätzlich aber noch das man einen default nicht ändern muß, wems nicht
paßt der soll attr global nehmen, wems egal ist der hat auch
bei einer imkompatiblen Änderung Probleme...
Aber ich lenke vom Thema (tar) ab ....
Gruß
Peter
Am Donnerstag, 24. Mai 2012 09:29:44 UTC+2 schrieb Martin Fischer:
>
> hallo peter,
>
> Am Dienstag, 22. Mai 2012, 14:30:28 schrieb PanTau:
> > updatefhem backup erzeugt Archiv mit Dateinamen die z.B. so aussehen:
> > FHEM.2012-05-22_22:21:29.tar.gz
> >
> > [...]
>
> da gebe ich dir absolut recht.. der filename ist etwas, sagen wir mal,
> unglücklich gewählt.. ich hatte das so aus dem script übernommen und
> lediglich
> von .tgz auf .tar.gz umgestellt.
>
> ich habe gerade 99_updatefhem in dieser hinsicht geändert. der filename
> sieht
> nun so aus:
>
> FHEM-20120524_092616.tar.gz
>
> im laufe des tages werde ich die änderungen einchecken, ist dann ab morgen
> über updatefhem zu aktualisieren.
>
> gruss martin
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Hallo Peter,
Am Donnerstag, 24. Mai 2012, 13:07:25 schrieb PanTau:
> [...]
> Warum hast Du aber .tgz in .tar.gz geändert?
> Persönlich finde ich tgz viel schöner, aber wichtiger ist, daß ich (und
> evtl. auch andere) Scripte habe, die die Backups
> "weiterverarbeiten". Die muß ich nun anpassen (die suchen nach *.tgz), geht
> schnell, kein großes Problem, aber warum?
es war mehr intuition als konkret ein grund. so wie du es schon schreibst,
könnte man hieraus wunderbar eine diskussion ableiten. ich könnte nun
argumentieren, das im *nix umfeld .tar.gz weitaus präsenter ist als .tgz.
vielleicht hat mich das dazu motiviert und mich dabei davon ablenken lassen,
das evtl. jemand ein script laufen lässt.
nimm es mir nicht übel aber einen wechsel zu .tgz würde ich jetzt nicht
nochmal vornehmen wollen, da es jetzt schon ausgerollt ist / wird. das würde
nun noch mehr verwirren. mea culpa ;-)
aber letztlich hängt das auch mit dem ganzen aufräumen in fhem zusammen. fhem
soll etwas mehr konformer werden. deshalb auch:
> [..]
> Wenn nicht würde ich ähnlich bei FHEM.backup vs. backup argumentieren...
per default wird fhem in (siehe Makefile) "/usr/share/fhem" installiert. die
module (und bisher auch pgm2) in FHEM. das backup landete in FHEM.backup.
die verzeichnisnamen sollen etwas "sprechender" werden, wenn man das so
ausdrücken mag. eine doppelnennung von fhem in form von /usr/share/fhem/FHEM
oder /usr/share/fhem/FHEM.backup ist einfach überflüssig bzw. verwirrend.
in irgendeinem thread habe ich ja schon mal die diskussion diesbezgl. in fhem-
devel erwähnt. sinnvoll wäre nämlich z.b. FHEM in modules oder lib
umzubenennen, damit auch jedem klar ist, das dort die Fhem-Module liegen und
im backup halt das backup von Fhem (was heute noch nicht alles beinhaltet,
also config, logs, module, etc.).
so oder so... es werden dort sicherlich noch ein paar änderungen kommen. mir
(uns) ist dabei klar, das wir immer irgend einen tot sterben müssen und
wahrscheinlich auch nicht immer _alle_ dabei abholen bzw. _alles_
abwärtskompatibel gestalten können. das ist nun mal die krux bei einer
umstellung. aber ich denke uns allen ist dabei bewusst, das wir die eine oder
andere unwegsamkeit dann auch einfach mal in kauf nehmen müssen. wir betreiben
ja fhem auch produktiv und sind demnach genauso wie die community von den
änderungen "betroffen". ausgangspunkt von strukturellen änderungen sollten
meiner meinung nach immer "attr global modpath" sein, so das der benutzer
diesen ggf. frei wählen kann und die entwickler diesen als pfad vorgegeben
bekommen. dann sollte auch künftig nichts schief gehen. nur halt jetzt in der
übergangszeit ;-)
nicht das ich jetzt die diskussion an dieser stelle abwürgen möchte. nein,
denn ich halte sie auch für wichtig um noch den einen oder anderen
"fallstrick" bei verschiedenen installationen kennen zu lernen und ggf. zu
berücksichtigen. allerdings würde ich, bevor es jetzt hier zu sehr ins detail
geht interessierte bitten, die diskussion auf fhem-devel mit zu verfolgen bzw.
sich dort zu beteiligen.
gruss martin
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com