ds-mod "cp" anders als AVM "cp"? Box "verliert" u.U. Einstellungen.

[MaxMuster]

Moin zusammen,

auf meiner Eumex hatte ich ein interessantes Problem/Phänomen:

Die Einstellungen, die ich im Telefonie-Bereich gemacht hatte (eigene Rufnummer, Telefone) waren nach jedem Neustart weg. Das hat mich, da ich den Part eher selten nutze (außer zum "Fritz-Faxen") nicht so sehr gestört, aber dann doch neugierig gemacht.
Folgenden fand ich heraus:
Beim Booten prüft das rc.S Skript, ob in den gerade erzeugten Nodes im Flash was drin ist, wenn nicht, werden die defaults geladen ("copy_telefonie_defaults fx_conf ${OEM} ${Country} ${OEM_DEFAULT_INDEX"). Dabei geht das Skript so vor, dass die Defaults per "cp" dorthin kopiert werden. Mit dem Resultat, dass die Specila-Devicces "verschwinden" und "normale" Dateien erstellt werden. Alle Änderungen gehen so natürlich verloren.

Beim Hochfahren sieht das dann so aus:

mknod: /var/flash/ar7.cfg: File exists
Loading /var/flash/ds_mod...done.
Loading passwords...done.
Loading hosts...done.
Loading config...done.
Loading modules...done.
checkempty: : No such file or directory
cp /etc/default.049/telefon_misc.default /var/flash/telefon_misc
checkempty: : No such file or directory
cp /etc/default.049/fx_lcr.default /var/flash/fx_lcr
checkempty: : No such file or directory
cp /etc/default.049/fx_conf.default /var/flash/fx_conf
checkempty: : No such file or directory
cp /etc/default.049/fx_moh.default /var/flash/fx_moh
cp /etc/default.049/fx_moh.default /var/fx_moh
attempting to load DSL Firmware '/lib/modules/ar0700xx.bin'

Das konnte ich nun umgehen, indem ich die Datei gelöscht habe, mit mknod das Device angelegt habe, mit "cat" die defaults hineingeschreiben habe (was ja eigentlich auch "richtiger" wäre als cp, oder?!?) und, siehe da, die Änderungen waren "resetfest".

Soweit, so schlecht. Meine Frage war: WARUM ?!?
Ich habe festgestellt, mit der originalen 04.33-er Firmware geht es mit "cp" beim 2.6-er nicht. Kann das jemand nachvollziehen??

/var/flash $ rm fx_conf
/var/flash $ mknod /var/flash/fx_conf c 240 $((0x81))
/var/flash $ ls -l
[...snip...]
crw-r--r--    1 root     root     240, 129 Jun 20 12:03 fx_conf
crw-r--r--    1 root     root     240,  99 Jan  1  2000 fx_def
-rwxr-xr-x    1 root     root         6356 Jan  1  2000 fx_lcr
-rwxr-xr-x    1 root     root        32768 Jan  1  2000 fx_moh
[...snip...]
/var/flash $ cp /etc/default.049/fx_conf.default fx_conf
/var/flash $ ls -l
[...snip...]
-rwxr-xr-x    1 root     root        20072 Jun 20 12:04 fx_conf
crw-r--r--    1 root     root     240,  99 Jan  1  2000 fx_def
-rwxr-xr-x    1 root     root         6356 Jan  1  2000 fx_lcr
-rwxr-xr-x    1 root     root        32768 Jan  1  2000 fx_moh
[...snip...]
/var/flash $ rm fx_conf
/var/flash $ mknod /var/flash/fx_conf c 240 $((0x81))
/var/flash $ cat /etc/default.049/fx_conf.default > fx_conf
/var/flash $ ls -l
[...snip...]
crw-r--r--    1 root     root     240, 129 Jun 20 12:04 fx_conf
crw-r--r--    1 root     root     240,  99 Jan  1  2000 fx_def
-rwxr-xr-x    1 root     root         6356 Jan  1  2000 fx_lcr
-rwxr-xr-x    1 root     root        32768 Jan  1  2000 fx_moh
[...snip...]
/var/flash $

Mit einer "originalen" Firmware geht es, es scheint also am "ds-mod Busybox cp" zu liegen???

# ls -l
[...snip...]
crw-r--r--    1 0        0        240, 132 Jan  1  2000 fx_cg
crw-r--r--    1 0        0        240, 131 Jan  1  2000 fx_moh
crw-r--r--    1 0        0        240, 130 Jan  1  2000 fx_lcr
crw-r--r--    1 0        0        240, 129 Jan  1  2000 fx_conf
[...snip...]
#
# cp /etc/default.049/fx_conf.default fx_conf
#
# ls -l
[...snip...]
crw-r--r--    1 0        0        240, 132 Jan  1  2000 fx_cg
crw-r--r--    1 0        0        240, 131 Jan  1  2000 fx_moh
crw-r--r--    1 0        0        240, 130 Jan  1  2000 fx_lcr
crw-r--r--    1 0        0        240, 129 Jan  1  2000 fx_conf
[...snip...]
#

Der ultimative Test (AVM-cp auf dem ds-mod) geht leider nicht, da der Befehl mit einem "Segmentation fault" abbricht...

/var/flash $ /tmp/cp
BusyBox v1.1.2 (2007.03.12-13:19+0000) multi-call binary

Usage: cp [OPTION]... SOURCE DEST

Copies SOURCE to DEST, or multiple SOURCE(s) to DIRECTORY.

        -a      Same as -dpR
        -d,-P   Preserves links
        -H,-L   Dereference all symlinks (implied by default)
        -p      Preserves file attributes if possible
        -f      force (implied; ignored) - always set
        -i      interactive, prompt before overwrite
        -R,-r   Copies directories recursively

/var/flash $ /tmp/cp /etc/default.049/fx_conf.default fx_conf
Segmentation fault
/var/flash $

Was macht den das cp der ds-Busybox nun "anders"? Im menuconfig konnte ich nichts weiter dazu finden. Sollte man sicherheitshalber das rc.S so umschreiben, dass es "cat" statt cp benutzt, oder bin ich der einzige, bei dem das so ist?

Jörg

[olistudent]

Vorher:

/var/flash $ ls -l
crw-r--r--    1 root     root     240, 113 Jan  1 01:54 ar7.cfg
crw-r--r--    1 root     root     240, 141 Jan  1 01:00 calllog
crw-r--r--    1 root     root     240,  98 Jan  1 01:00 debug.cfg
crw-r--r--    1 root     root     240,  60 Jan  1 01:00 ds_mod
crw-r--r--    1 root     root     240, 132 Jan  1 01:00 fx_cg
-rwxr-xr-x    1 root     root        16556 Jan  1 01:00 fx_conf
crw-r--r--    1 root     root     240,  99 Jan  1 01:00 fx_def
-rwxr-xr-x    1 root     root         6440 Jan  1 01:00 fx_lcr
-rwxr-xr-x    1 root     root        32768 Jan  1 01:00 fx_moh
crw-r--r--    1 root     root     240, 112 Jan  1 01:00 multid.leases
crw-r--r--    1 root     root     240, 117 Jan  1 01:00 net.update
crw-r--r--    1 root     root     240,  74 Jan  1 01:59 stat.cfg
-rwxr-xr-x    1 root     root         2469 Jan  1 01:00 telefon_misc
crw-r--r--    1 root     root     240, 119 Jan  1 01:31 tr069.cfg
crw-r--r--    1 root     root     240, 114 Jan  1 01:31 voip.cfg
crw-r--r--    1 root     root     240, 118 Jan  1 01:00 vpn.cfg
crw-r--r--    1 root     root     240, 115 Jan  1 01:00 wlan.cfg

Patch:

--- rc.S        2007-09-10 16:43:15.000000000 +0200
+++ rc.S.cat    2007-09-10 14:29:47.000000000 +0200
@@ -23,22 +23,22 @@
  if /usr/bin/checkempty /var/flash/${tmp_file_name}; then
  if [ -f /etc/default.${tmp_country}/${tmp_file_name}.${tmp_oem}.${tmp_index} ] ; then
  echo "cp /etc/default.${tmp_country}/${tmp_file_name}.${tmp_oem}.${tmp_index} /var/flash/${tmp_file_name}"
- cp /etc/default.${tmp_country}/${tmp_file_name}.${tmp_oem}.${tmp_index} /var/flash/${tmp_file_name}
+ cat /etc/default.${tmp_country}/${tmp_file_name}.${tmp_oem}.${tmp_index} > /var/flash/${tmp_file_name}
  return
  fi
  if [ -f /etc/default.${tmp_country}/${tmp_file_name}.${tmp_oem} ] ; then
  echo "cp /etc/default.${tmp_country}/${tmp_file_name}.${tmp_oem} /var/flash/${tmp_file_name}"
- cp /etc/default.${tmp_country}/${tmp_file_name}.${tmp_oem} /var/flash/${tmp_file_name}
+ cat /etc/default.${tmp_country}/${tmp_file_name}.${tmp_oem} > /var/flash/${tmp_file_name}
  return
  fi
  if [ -f /etc/default.${tmp_country}/${tmp_file_name}.default.${tmp_index} ] ; then
  echo "cp /etc/default.${tmp_country}/${tmp_file_name}.default.${tmp_index} /var/flash/${tmp_file_name}"
- cp /etc/default.${tmp_country}/${tmp_file_name}.default.${tmp_index} /var/flash/${tmp_file_name}
+ cat /etc/default.${tmp_country}/${tmp_file_name}.default.${tmp_index} > /var/flash/${tmp_file_name}
  return
  fi
  if [ -f /etc/default.${tmp_country}/${tmp_file_name}.default ] ; then
  echo "cp /etc/default.${tmp_country}/${tmp_file_name}.default /var/flash/${tmp_file_name}"
- cp /etc/default.${tmp_country}/${tmp_file_name}.default > /var/flash/${tmp_file_name}
+ cat /etc/default.${tmp_country}/${tmp_file_name}.default /var/flash/${tmp_file_name}
  return
  fi
  fi

nachher:

/var/flash $ ls -l
crw-r--r--    1 root     root     240, 113 Jan  1 01:03 ar7.cfg
crw-r--r--    1 root     root     240, 141 Jan  1 01:00 calllog
crw-r--r--    1 root     root     240,  98 Jan  1 01:00 debug.cfg
crw-r--r--    1 root     root     240,  60 Jan  1 01:00 ds_mod
crw-r--r--    1 root     root     240, 132 Jan  1 01:00 fx_cg
crw-r--r--    1 root     root     240, 129 Jan  1 01:00 fx_conf
crw-r--r--    1 root     root     240,  99 Jan  1 01:00 fx_def
crw-r--r--    1 root     root     240, 130 Jan  1 01:00 fx_lcr
crw-r--r--    1 root     root     240, 131 Jan  1 01:00 fx_moh
crw-r--r--    1 root     root     240, 112 Jan  1 01:00 multid.leases
crw-r--r--    1 root     root     240, 117 Jan  1 01:00 net.update
crw-r--r--    1 root     root     240, 116 Jan  1 01:00 stat.cfg
crw-r--r--    1 root     root     240, 133 Jan  1 01:00 telefon_misc
crw-r--r--    1 root     root     240, 119 Jan  1 01:00 tr069.cfg
crw-r--r--    1 root     root     240, 114 Jan  1 01:00 voip.cfg
crw-r--r--    1 root     root     240, 118 Jan  1 01:00 vpn.cfg
crw-r--r--    1 root     root     240, 115 Jan  1 01:00 wlan.cfg

Und wiedereinmal frage ich mich warum das vorher keinem aufgefallen ist. Das sollte mit jeder dsmod-Firmware nach "Auf Werkseinstellungen zurücksetzen" passieren.

MfG Oliver

[RalfFriedl]

Die AVM Firmwares verwenden die Busybox v1.1.2, Der ds-mod verwendet v1.5.1.

In der v1.5.1 wird die Ziel-Datei erst gelöscht, bevor sie angelegt wird, bei der v1.1.2 war das anders.

@olistudent
Man kann also davon ausgehen, daß beim Zurücksetzen auf Werkseinstellungen die /etc/init.d/rc.S nicht von Bedeutung ist. Vermutlich werden dort mit cat oder auf vergleichbare Art die Default-Dateien kopiert.

[MaxMuster]

... nicht nur in den neuen passiert das. Ich hatte erst den 2.6-er Kernel im Verdacht und es mit einer 2.4-er Box (04.27) getestet. Die "cp't" das auch schon, aber eben nicht "überschreibend"....
Also die 1.2.1-er BB ist in der 06.04.33 noch drin.
@Ralf: Wenn du die 29.04.29 da hast: Wie macht es da das rc.S?!?

Man kann also davon ausgehen, daß beim Zurücksetzen auf Werkseinstellungen die /etc/init.d/rc.S nicht von Bedeutung ist. Vermutlich werden dort mit cat oder auf vergleichbare Art die Default-Dateien kopiert.

Doch, denke ich schon, denn dann ist der node "leer", ein checkempty ist nicht true und der "cp" schlägt zu und erstellt "normale" Dateien. Änderungen geschehen dann in dieser Datei (und nicht im tfs), und nach dem nächsten Reboot ist die mit mknod erzeugte Datei wieder "leer" und die Einstellungen "weg".
Ich wundere mich, wie Oliver, warum nicht schon so viele anderen dran verzweifelt sind.

Und übrigens wieder mal danke an die Anstrengungen mit dem qemu, da meine Eumex keine serielle Konsole hat und der Part mit dem "Überschreiben" nicht im dmesg auftauchte, hätte ich sonst wohl viel länger gesucht...

Jörg

[olistudent]

So wie ich das oben gepostet habe sah es auf meiner Box aus. Also nehme ich an, dass das schon ein "reales" Problem ist.

MfG Oliver

[MaxMuster]

Hast du denn deine Box irgendwann mal restartet oder traust dich, das zu tun? Nur um zu sehen, ob die Einstallungen dann bei dir auch weg sind.
Wenn du die Dateien vorher wegsicherst, kannst du sie ja danach mit cat "richtig" zurückspielen.
Oder ziehe die Box in eine qemu Session, dann siehst du beim Booten, ob er die defaults "drüberkopiert"
Jörg

[olistudent]

Ich habs doch oben gepostet. Ob er die Einstellungen aus dem Webinterface speichert kann ich nicht probieren, weil geht grad net. Aber wenn die Files keine Character Devices sind, dann werden wohl auch die Einstellungen nicht gespeichert. Nachdem ich dann den cp in cat umgewandelt hab und nach Neustart waren es dann auch Character Devices.

MfG Oliver

[RalfFriedl]

Die 29.04.29 und 29.04.37 sind, was die default-Dateien in /etc/init.d/rc.S betrifft, genau gleich.
Daher meine Schlußfolgerung, daß diese Stellen nicht übermäßig von Bedeutung sein können, sonst gäbe es viel mehr Probleme in dieser Richtung.

Insbesondere muß man davon ausgehen, daß die Boxen nicht mit leeren Flash-Dateien ausgeliefert werden, und daß "Rücksetzen auf Werkseinstellungen" die Flash-Dateien auch nicht leer macht, sondern sie initialisiert.

Oder zumindest, daß beim Abspeichern von Einstellungen über die Web-Oberfläche zuerst die Geräte-Dateien wiederhergestellt werden.

Wenn dem nicht so wäre, könnte niemand in eine neue Box oder nach Zurücksetzen neue Einstellungen speichern.

Es kann natürlich sein, daß dies der Grund dafür ist, daß es manchmal Probleme beim Speicher der Einstellungen gibt, die verschwinden, sobald man etwas über die Web-Oberfläche geändert hat.

Ich habe bei mir mal die Geräte-Datei durch eine normale Datei gleichen Inhalts ersetzt. Nachdem ich eine Änderung der Konfiguration abgespeichert habe, ist dort wieder eine Geräte-Datei. Also wird erst die Datei gelöscht und eine Geräte-Datei erstellt, bevor die Änderungen gespeichert werden.

Problematisch kann es also nur werden, wenn auf anderem Weg Änderungen gemacht werden und man davon ausgeht, daß diese dauerhaft sind, obwohl nur die normale Datei geändert wurde.

[MaxMuster]

Ich habe bei mir mal die Geräte-Datei durch eine normale Datei gleichen Inhalts ersetzt. Nachdem ich eine Änderung der Konfiguration abgespeichert habe, ist dort wieder eine Geräte-Datei. Also wird erst die Datei gelöscht und eine Geräte-Datei erstellt, bevor die Änderungen gespeichert werden.

Problematisch kann es also nur werden, wenn auf anderem Weg Änderungen gemacht werden und man davon ausgeht, daß diese dauerhaft sind, obwohl nur die normale Datei geändert wurde.

Das ist bei mir auf einer Freumex (06.04.33) definitiv anders:

/var/tmp $ ls -l /var/flash/fx_conf
crw-r--r--    1 root     root     240, 129 Jan  1  2000 fx_conf
/var/tmp $ cat /var/flash/fx_conf > fx_conf
/var/tmp $ ls -l /var/flash/fx_conf
crw-r--r--    1 root     root     240, 129 Jan  1  2000 /var/flash/fx_conf
/var/tmp $ cp fx_conf  /var/flash/fx_conf
/var/tmp $ ls -l /var/flash/fx_conf
-rw-r--r--    1 root     root        20072 Sep 10 17:57 /var/flash/fx_conf
/var/tmp $ echo "hier ändere ich was in der GUI (eine zusätzliche ISDN-Nummer)"
hier ändere ich was in der GUI (eine zusätzliche ISDN-Nummer)
/var/tmp $
/var/tmp $ ls -l /var/flash/fx_conf
-rw-r--r--    1 root     root        20072 Sep 10 17:59 /var/flash/fx_conf
/var/tmp $ cmp /var/flash/fx_conf fx_conf
/var/flash/fx_conf fx_conf differ: char 47, line 1
/var/tmp $

Die "normale" Datei bleibt vorhanden! Die Änderung wäre "weg"! Nach einem Reboot ist aber zumindest der "alte Stand" von vor dem "cp" und dem Ändern in der GUI wieder da, die "normale" Datei hat am tfs nix verändert.
Wenn nach dem Werksreset also die Datei "leer" wäre, wird man nie etwas auf Dauer eintragen können...

Jörg

[RalfFriedl]

Ich habe es mit der ar7.cfg auf einem W900V ausprobiert. Es kann sein, daß verschiedene Teile im Web-Interface das anders handhaben.

Allerdings bedeutet Dein Beobachtung, daß die Datei im Auslieferungszustand und nach einem Reset nicht leer sein kann, sonst könnte niemand hier dauerhafte Änderungen vornehmen, und das wäre längst jemandem aufgefallen.

[olistudent]

Das Problem tritt ja auch nur auf, wenn der dsmod installiert ist. Und der ist im Auslieferungszustand nicht drauf.
Bei mir waren die 4 Dateien nach einem "Factory Reset" leer, sonst hätten sie ja ein "c" gehabt.

MfG Oliver

[RalfFriedl]

Ok, Korrektur:
Die AVM Firmware verwendet die Busybox v1.1.2, die Speedports die v1.1.0. Ich hatte direkt cp aus der AVM Firmware aufgerufen, aber das ist ein Link auf /bin/busybox und damit auf die vom ds-mod.

Das cp aus der neuen busybox löscht erst die Datei, bevor es sie anlegt, das cp aus der alten Busybox überschreibt einfach die Datei und schreibt daher auch auf eine vorhandene Gerätedatei.

Das cp aus einem normalen Linux löscht übrigens auch nicht die Datei, die es überschreibt, daher wäre es sinnvoll, das cp der busybox zu ändern.

Dies erklärt auch die Beobachtung, daß es manchmal Probleme gibt, wenn eine Box auf Werkseinstellungen gesetzt wird, bevor der ds-mod installiert wird.

[heini66]

ich hab von oli nen patch erhalten.
damit hat auf meinem 900 das vergessen der nebenstelleneinstellungen ENDLICH ein ende!!!

EIN FETTES DANKE MAL WIEDER AN OLISTUDENT !!!

[olistudent]

@Ralf
Hat diese Änderung vielleicht auch unerwünschte Auswirkungen? Falls nicht, machst du einen Patch und checkst ihn ein?

MfG Oliver

[RalfFriedl]

Da die Version von AVM es genau so macht, glaube ich nicht, daß es unerwünschte Auswirkungen geben sollte.

Wie bereits beschrieben, verhält sich das normale cp bei meinem Linux System genau so wie das cp der älteren Busybox Version. Es gibt eine spezielle Option --remove-destination, mit der man das Löschen der Zieldatei erzwingen kann, von daher scheint es korrekt und beabsichtigt zu sein, die Zieldatei nicht zu löschen.

Die einzige Auswirkung, die mir einfällt und die vielleicht unerwünscht wäre, ist, wenn die Zieldatei ein Programm enthält, das gerade ausgeführt wird. Mit der aktuellen Busybox würde die Datei gelöscht und neu erstellt, anderenfalls bekäme man die Fehlermeldung "Text File Busy". Man kann sie dann aber immer noch von Hand löschen. Ich kann mir aber nicht vorstellen, daß das eine große Bedeutung hat, speziell nicht auf einen System, wo die meisten Programme im ROM sind.

[kriegaex]

Der richtige Weg für den cp-Patch wäre das Einreichen via BusyBox-Mailingliste, damit es upstream begutachtet und ggf. gefixt wird. Falls keiner Lust hat, die Liste zu abonnieren, kann ich das dann mal zum Review einreichen, ich habe die Liste sowieso abonniert.

[RalfFriedl]

Das ist richtig.

In Version 18119 wurde das Verhalten von cp geändert. Es gibt auch eine Option, die anscheinend dazu da ist, auf das alte Verhalten umzuschalten.

#define DO_POSIX_CP 0  /* 1 - POSIX behavior, 0 - safe behavior */

Leider ist diese fest auf 0 eingestellt und kann aus der Konfiguration nicht geändert werden. Der Patch besteht also darin, diesen Wert auf 1 zu ändern. Ich habe es auch ausprobiert, damit wird das Verhalten geändert.

Das "safe behavior" bezieht sich darauf, daß anderenfalls die Zieldatei ein Link sein könnte. In diesem Fall wird das Ziel des Links erstellt oder überschrieben, bzw. wenn der Link komplett ungültig ist, ist das Erstellen der Zieldatei nicht möglich.

Da die Box sowieso kein Mehrbenutzersystem ist, ist der Sicherheitsaspekt sowieso nicht von Bedeutung.

Auch sonst überzeugt mich die Begründung nicht. Auf jedem POSIX-Kompatiblen System ist das Verhalten anders, wenn es damit irgendwelche Probleme gegeben hätte, hätte man sich wahrscheinlich überlegt, den Standard zu ändern.

Selbst wenn die Busybox Gruppe der Meinung ist, daß ihr Verhalten besser ist, wollte sie zumindest die Option für ein korrektes Verhalten über menuconfig anbieten, ohne daß man dafür in der Datei den Wert ändern muß.

[MaxMuster]

Also, ich fände das Ändern des cp auf das "original-Verhalten" auch am besten über die offizielle BB-Schiene.
Grundsätzlich frage ich mich noch immer, warum AVM dafür ein cp nutze, meiner Ansicht nach wäre doch "cat" der "richtigere" Weg im Umgang mit den charakter devices, oder?
Aber wenn man mit der geänderten BB das rc.S nicht deswegen ändern muss, hat das natürlich auch seine Vorteile...
Das einzig gute ist wohl, dass viele erst ihr System zurückgesetzt haben und danach den ds-mod installiert haben und nicht beides gleichzeitig (außer Heini natürlich )

Jörg

[RalfFriedl]

Das Zurücksetzen direkt vor der Installation ist ja gerade das, was das Problem hervorruft: Leere Konfiguration, Device-Dateien werden überschrieben, Änderungen werden zum Teil nicht dauerhaft gespeichert. Wenn man die Konfiguration schon drin hat, sind die Dateien nicht leer, und alles ist bestens.

Nachdem inzwischen klar ist, daß es mit einem cp, das POSIX-konform ist, funktioniert, finde ich nichts schlimmes daran, cp zu verwenden. Ich vermute, daß Du cat nur deswegen als "richtiger" empfindest, weil Du Dich daran gewöhnt hast, daß es mit cp nicht funktioniert.

Ich fände es auch besser, wenn die Busybox direkt geändert wird statt über einen Patch von uns. Nachdem diese aber schon mit Absicht in die andere Richtung geändert wurde, habe ich da meine Zweifel. Es würde aber schon reichen, wenn die Option wenigstens über die Konfiguration gesteuert werden kann. Bis dahin können wir auch den Patch verwenden.

[MaxMuster]

Das Zurücksetzen direkt vor der Installation ist ja gerade das, was das Problem hervorruft: Leere Konfiguration, Device-Dateien werden überschrieben, Änderungen werden zum Teil nicht dauerhaft gespeichert. Wenn man die Konfiguration schon drin hat, sind die Dateien nicht leer, und alles ist bestens.

... ich denke, dass die meisten den Reset vor dem Patchen machen, dann fährt die Box ja noch mit dem originalen cp wieder hoch und alles ist gut. Nur die "Spielkinder" (so wie ich) müssen ja immer wieder alles zurücksetzen

Das "Gefühl" kommt, da hast du recht, vermutlich aus einer anderen Ecke: Dem Gegenteil der Aktion. Es ist ja auch keine gute Idee eine "Datei", die eigentlich ein charakter device ist, per cp "auslesen" zu wollen. Da schleicht sich halt eine Vorliebe ein. Aber jetzt wird es eher "unproduktiv" und ich höre lieber auf.

Wenn man aber bis zum Fix noch "Warnung" mit in den ds-Thread bringen könnte, fände ich das ganz gut. Ich glaube viele merk(t)en das auch einfach nicht, denn während des laufenden Betriebes stört es ja nicht.

Jörg