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

[kriegaex]

Sicher kann man darüber streiten, ob es richtig von Denis Vlasenko war, die aus seiner Sicht sicherere anstatt der POSIX-kompatiblen Variante als Standard zu wählen und damit außerdem ein paar Bytes Codegröße einzusparen. Wir dürfen nicht vergessen, BusyBox soll eine kleinere Variante der Coreutils sein, nicht die Coreutils 1:1. Aber davon abgesehen, bin ich aus einem ganz bestimmten Grund dafür, lieber die Shell-Skripten von cp auf cat umzupatchen: Ein Werks-Reset muß auch funktionieren, wenn die Character Devices unter /var/flash aus irgendeinem Grund nicht existieren, und cp würde hier immer noch scheitern, cat ist die richtige Wahl.

Insofern gebe ich Ralf Recht, es sollte konfigurierbar sein in BusyBox und man kann sich wundern, daß es geändert wurde. Aber Max hat auch Recht, denn Ralfs Patch beseitigt aus Sicht von rc.S das Symptom, nicht die Ursache.

Übrigens ist Olivers Patch nicht richtig, die Dateiumleitung gehört zum cat, nicht zum cp. Das ist bestimmt durch Copy & Paste passiert.

 

[olistudent]

Hups. Der Patch war falsch rum und dann hab ich die Umleitung vergessen...

Aber davon abgesehen, bin ich aus einem ganz bestimmten Grund dafür, lieber die Shell-Skripten von cp auf cat umzupatchen: Ein Werks-Reset muß auch funktionieren, wenn die Character Devices unter /var/flash aus irgendeinem Grund nicht existieren, und cp würde hier immer noch scheitern, cat ist die richtige Wahl.

Das versteh ich nicht? Warum sollte cp da scheitern?
Ich finde immernoch, dass wir die busybox patchen sollten. Ansonsten brauchen wir für jede Box wieder einen eigenen Patch, oder ging einer für alle?

MfG Oliver

 

[RalfFriedl]

Aber davon abgesehen, bin ich aus einem ganz bestimmten Grund dafür, lieber die Shell-Skripten von cp auf cat umzupatchen: Ein Werks-Reset muß auch funktionieren, wenn die Character Devices unter /var/flash aus irgendeinem Grund nicht existieren, und cp würde hier immer noch scheitern

Deine Begründung ist nicht zu Ende gedacht: Wenn diese Character Devices nicht existieren, funktioniert es weder mit cat noch mit cp.

Die Platzeinsparung ist hier nicht das Thema. Wir reden hier von ca. 30 bis 60 Bytes, je nachdem, ob man die Meldung "file exists" am Anfang der Datei mit dazu zählt oder nicht. Wenn man wirklich Platz sparen wollte, könnte man zum Beispiel auf rekursives Kopieren verzichten, das würde einiges mehr einbringen. (Nicht daß es das jetzt vorschlagen will.)

Mir ist klar, daß die Kommandos der Busybox einen eingeschränkten Funktionsumfang haben, um Platz zu sparen. Hier geht es darum, daß ein Standard-konformes Verhalten vorhanden war und entfernt wurde, ohne daß man die Möglichkeit hat, sich das auszusuchen.

Auch wenn man AVM bei der Firmware einiges vorwerfen kann, sich an den Standard zu halten gehört nicht dazu.

Du hältst cat für besser geeignet als cp. Ich vermute, das liegt daran, daß Du Dich, genau wie Max, daran gewöhnt hast, daß cat dafür verwendet werden muß.
Ich kann mich noch gut erinnern, wie vor ein paar Tagen einer das Problem mit den Geräte-Dateien hatte. Da habe ich auch gedacht "schon wieder einer, der cp genommen hat."
Aber nachdem mit klar ist, daß es mit einem Standard-cp funktionieren sollte, sehe ich das anders.

Das cp Kommando wieder in Ordnung zu bringen, beseitigt die Ursache, nicht das Symptom. Ich habe auch nichts gefunden, wo Max das Gegenteil behauptet hätte.

Mal angenommen, wir stellen jetzt alles auf cat um. In der nächsten Version der Busybox ist die Shell so geändert, daß sie bei einer Ausgabe-Umleitung erst die Zieldatei löscht, bevor sie erstellt wird. Dann funktioniert diese Variante auch nicht mehr.
Das mag jetzt etwas unwahrscheinlich klingen, aber es gibt gute Argumente dafür, die Zieldatei zuerst zu löschen. Und zwar genau die gleichen, die auch dafür sprechen, es beim cp so zu machen. Wenn es aus irgendeinem Grunde gefährlich ist, auf einen Link mit cp zu schreiben, dann ist es genauso gefährlich, auf diesen Link über die Ausgabeumlenkung der Shell zu schreiben.

Man muß sich darauf verlassen können, daß die verwendeten Kommandos sich so verhalten, wie sie sollen.

 

[kriegaex]

Deine Begründung ist nicht zu Ende gedacht: Wenn diese Character Devices nicht existieren, funktioniert es weder mit cat noch mit cp.

Da hast Du vollkommen Recht, das war nicht zu Ende gedacht.

Die Platzeinsparung ist hier nicht das Thema.

Das habe ich auch nicht als Begründung angeführt, warum mir cat lieber wäre, sondern ich erklärte, weshalb es einer von zwei Gründen (und zwar der unwichtigere) für Denis war, es so zu implementieren.

Du hältst cat für besser geeignet als cp. Ich vermute, das liegt daran, daß Du Dich, genau wie Max, daran gewöhnt hast, daß cat dafür verwendet werden muß.

Nein, es lag maßgeblich daran, daß ich - s.o. - nicht zu Ende gedacht hatte.

Das cp Kommando wieder in Ordnung zu bringen, beseitigt die Ursache, nicht das Symptom.

Upstream ist mir trotzdem wichtig, es ist genauso wenig erstrebenswert, vom Busybox-Standard abzuweichen wie die AVM-Skripten zu patchen. Daher bitte ich um einen vollständigen Patch, der die Einstellung konfigurierbar macht, so daß wir die BusyBox patchen und die Default-Konfigurationen dementsprechend anpassen können. Falls Dein Patch es in den Upstream schafft - ich reiche ihn für Dich gern ein, wie gesagt - entfällt er dann irgendwann, wir könnten aber die Konfigurationen beibehalten.

Wäre das eine sinnvolle Lösung auch aus Eurer Sicht? Wenn wir schon vom Zu-Ende-Denken reden...

Update: Ich habe in der BusyBox-Liste angefragt, ob man sich mit einem neuen Konfigurationsschalter diesbezüglich anfreunden könnte. Ich berichte dann über die Antwort, Ihr könnt den Thread auch selbst beobachten: http://busybox.net/lists/busybox/2007-September/028707.html

 

[MaxMuster]

Guten Morgen,

nachdem ich eine Nacht drüber geschlafen habe, muss ich das "Fass nochmal aufmachen" ;-)
Mittlerweile denke ich, dass die Busybox-Variante eigentlich die richtigere ist und einfach AVM "falsch" liegt. Also, "Grundsatzdiskussion, Part x":

Ich kann mich noch gut erinnern, wie vor ein paar Tagen einer das Problem mit den Geräte-Dateien hatte. Da habe ich auch gedacht "schon wieder einer, der cp genommen hat."
Aber nachdem mit klar ist, daß es mit einem Standard-cp funktionieren sollte, sehe ich das anders.

Schade, ist doch immer noch meine Meinung ;-)
"cp" soll(te) (dass ist mein Verständnis) genau das tun, was der Name sagt, eine "Kopie" anlegen. Und da bekommen meine "gefühlten Bedenken" nun auch Umrisse, denn dazu gehören Dinge wie "das Format" des Inhaltes, und auch Dinge wie Datei-Berechtigungen usw.
Ein Charakter Device ist was anderes. Das enthält eben "nur Charakters".
Wenn ich es "ernst" meine, müßte ein cp einer Datei auf ein Charakter Device dann ja zumindest die Berechtigungen usw. übernehmen (das ist das Ziel der Kopie, möglichst nahe am Original zu sein), das wird aber selten (oder nie?) das gewollte sein. Ich will nur den Inhalt das CD's verändern, nicht "die Datei", also den Node selber.

Es ist auch, mit Verlaub, nicht einzusehen, warum ein cp nicht "in beiden Richtungen gleich" funktionieren sollte: Mache ich ein cp einer CD-"Datei", dann erhalte ich genau das: Eine Kopie des CD's . Warum sollte dann strenggenommen ein "cp" einer "normalen Datei" zu etwas anderem führen als einer "normale Datei"?

Und deshalb bleibt mein "Gefühl" erhalten: Ein "cp" ist hier fehl am Platze, auch wenn es sich "nett verhält" und versucht, "richtig" zu handeln, gemeint ist es, den Inhalt zu verändern und nicht den Node, und dafür sind cat (oder dd) die richtigen Befehle.

Meine These (zumindest noch heute früh am Morgen): Eigentlich kommt die "neue" Busybox der cp-Intention näher (auch wenn man ein fehlertoleranteres Verhalten gewöhnt war) und im rc.S sollte eigentlich ein cat (oder dd) stehen.

EDIT 8:30 (und drei Kaffee später): Ralf hat ja recht. Wenn ich an die "ursprünglichen" Devices denke, dann sollte ein cp einer Datei auf das "Drucker-Device" die Datei drucken und sicher nicht das Device löschen...
EDIT 8:45 Ich weiß, die Änderung ist "radikal", aber wenn sie so stimmt, dann ist die Implementierung des BB cp schlicht "falsch" im Umgang mit Specialdevices. Der Effekt tritt nämlich bei allen Specialdevices auf, und keiner kann doch ernthaft meinen, dass das dann richtig ist:
Versucht man (ich mache das lieber im qemu) eine Datei auf ein Terminal auszugeben, indem sie nach /dev/tty<xy> kopiert wird, ist das Device auch "weg" und durch die Datei ersetzt. Da sollten noch andere Anwendungen Probleme kriegen, die nicht ein umgeleitetes cat, echo oder so zur Ausgabe nutzen, sondern cp.

Jörg

EDIT 8:13 Ich muss mich in sofern relativieren, dass das "originale" cp wenn ich ein Device kopiere schon "konsequent" ist, und eine Datei mit dem Inhalt des Devices anlegt. (Zitat aus info cp):

By default, `cp' copies the contents of special files only when not
copying recursively. This default can be overridden with the
`--copy-contents' option.

Also soll es wohl so sein

 

[kriegaex]

Denis (neuerdings schreibt er sich Denys, weil er in ein anderes Land gezogen ist und es überall andere Transkriptionsregeln für kyrillische Schrfit gibt) hat bereits in der BusyBox-Liste geantwortet und im POSIX-Fall eine Ausnahme für Devices eingebaut, siehe dort. Ihr könnt den Patch ja mal testen. Was er mißverstanden hat, war, daß ich nach einer Konfigurations-Option für Menuconfig gefragt hatte, das habe ich dort klargestellt. Vielleicht kommt ja noch ein zweiter Patch, und dann haben wir es drin im Upstream (zumindest im Trunk, und solange basteln wir uns einen eigenen Patch).

 

[RalfFriedl]

Meiner Meinung nach sind seine Bedenken wegen der Sicherheit übertrieben. Wenn man es ernst meint, müßte man jedes Programm, das auf eine Datei schreiben kann, entsprechend abändern.

Es gibt noch andere Gründe für das Posix-Verhalten:
- Die Zieldatei könnte Zugriffsrechte haben, die in der Form beibehalten werden sollen.
- Die Zieldatei könnte sonstige Attribute haben (unwahrscheinlich auf einer FritzBox).
- Die Zieldatei könnte Hard Links unter anderem Namen haben, diese Zuordnung geht verloren.

Ich gehe davon aus, daß das Programm eher kleiner wäre, wenn man nur die reine Posix-Semantik implementieren würde, aber ein paar Bytes in die eine oder andere Richtung sind hier nicht so von Bedeutung.

 

[kriegaex]

Melde Dich in der BB-Liste an und antworte im dortigen Thread. Mailen kann man auch so (einfach im Web-Archiv klicken, steht dann sogar der Betreff drin), ob der Server es von nicht angemeldeten Benutzern annimmt, weiß ich nicht, könnte aber klappen. Mitlesen geht auch online.

 

[RalfFriedl]

Der Server nimmt keine Emails von nicht registrierten Benutzern an (heutzutage eine sinnvolle Einstellung).

Was machen wir jetzt? Für's erste DO_POSIX_CP aktivieren, bis die entsprechende Änderung in der Busybox drin ist?

 

[MaxMuster]

Die Diskussion ist ja schon recht weit, auch der Lösungsansatz (remove bei cp -r) sieht doch gut aus.
Hat mal einer das "andere" cp "aus" eine specialdevice betrachtet? Da ist das Verhalten auch geändert (die Kopie ist ebenfalls das Specialdevice, nicht der Inhalt). Könnte das in Zukunft auch stören?

Jörg

 

[RalfFriedl]

GNU cp unterscheidet auch hier zwischen normler und rekursiver Kopie.

Normales cp kopiert den Inhalt, rekursives cp kopiert die Devices.

Könnte man bei der Gelegenheit auch ändern, aber ich weiß nicht, wie weit wir mir dem Vorschlag kommen. Im Moment sehe ich auch keine Probleme damit.

 

[MaxMuster]

Mich stört es ja nicht, ich nehme "cat" dafür ;-) Aber mir fällt in der Tat auch momentan spontan nichts ein, wo "andere" cp zum Lesen aus einem Specialdevice nutzen könnten, aber wenn man schonmal dabei ist ... (denn schließlich macht die "alte" BB, dia auch AVM nutzt, es ja noch anders).

Jörg

 

[Bratwurst0815]

Hallo,

ich habe das gleiche Problem mit meiner Freumex.
Könnte mir jemand mal bitte den Patch mailen, oder kurz erklären, was ich wie und wo andern muss? Ich stecke leider nicht so tief in der Materie drin.
Besteht das Problem mit jeder Freumex?

Danke

 

[MaxMuster]

Hi,

steht eigentlich weiter vorne schon drin, ich trag es nochmal zusammen:

cd /var/flash 
mv fx_conf tmp
mknod /var/flash/fx_conf c 240 129
cat tmp > fx_conf

mv fx_lcr tmp
mknod /var/flash/fx_lcr c 240 130
cat tmp > fx_lcr

mv fx_moh tmp
mknod /var/flash/fx_moh c 240 131
cat tmp > fx_moh

mv fx_cg tmp
mknod /var/flash/fx_gc c 240 132
cat tmp > fx_cg

rm tmp

Das eventuell abhängig davon, bei welchen Dateien bei dir halt "normale" Dateien statt "Special-Devices" sind. Es müsste in etwa so aussehen:

# 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...]

Jörg

 

[Bratwurst0815]

Hi,

muss ich das nicht auch für die "telefon_misc" machen?

Danke

 

[RalfFriedl]

Für alle Dateien in /var/flash, die reguläre Dateien sind statt Geräte-Dateien.

telefon_misc hat die Nummer 133

 

[klarglas]

Hallo,

ich muss das Thema jetzt nochmal hoch holen, ich hab auch eine
Eumex mit DS-Mod am laufen, und habe heute ein update auf die 15.2er Version gemacht.

Sollte in dieser Version das Problem schon gefixt sein? oder besteht es bei der 15.1 und 15.2 ?

Leider verliert meine Eumex auch immer die Einstellungen nach einem Reboot.
Es liegt wie ich gelesen habe, daran das ich einen Werksreset gemacht habe.
Wenn ich den oben geposteten Patch einspiele bzw. einfach auf der Konsole das alles ändere,
vergisst die Box die Einstellungen nicht mehr, aber sobald ich wieder einen Werksreset
mache, vergisst sie wieder alles.

Ich würde das gerne dauerhaft lösen, aber wie kann ich machen das die Box, auch nach einen Werksreset,
nicht wieder ihre Einstellungen verliert?

mfg markus

 

[olistudent]

Hi.
Nein, das ist in 15.2 noch nicht gefixt.
Wie oft machst du einen Werksreset?

MfG Oliver

 

[klarglas]

Hallo

Leider schon recht oft (alle 2 Wochen) weil ich immer recht viel an der Box "rumspiele".
Bisher hab ich immer einen Werksreset gemacht wenn ich die Box irgendwie im Netzwerk
umgestellt habe (oder am Asterisk was umstelle). Das werde ich mir wohl jetzt abgewöhnen müssen .
Ich hab mir jetzt gerade noch den ds-mod mit 2.4 Kernel angeschaut, der hat das Problem ja
anscheinend nicht.

Jetzt weiß ich natürlich nicht wie lange es noch dauert bis die nächste Ds-mod Version raus kommt,
aber falls das nicht all zu lange ist werde ich mir den Patch einfach in eine Datei auf die Box legen,
und immer nach dem Werksreset ausführen.

mfg markus

 

[MaxMuster]

Alternativ nimm eine andere Busybox oder ändere den Part im rc.S so ab, dass dort
statt "cp xy z" steht "cat xy > z", das sollte reichen.

Jörg