[...] wenn nur sauber/ordentlich programmiert worden wäre.
Danke für die Blumen ... ich bin halt noch in der Lernphase - mancher ist es bei der Programmierung, manch' andere beim Benehmen.
Ich hatte in #1369 noch die Bereitschaft gezeigt, auf Dein Problem einzugehen und auch Dateien zu einem anderen Zeitpunkt zu löschen, wenn Du es mir denn plausibel zeigen solltest, wo das auftritt ... dazu gehört für mich eine ordentliche Fehlerbeschreibung und das kann nur eine sein, die sich um sachliche Darstellung des Problems bemüht und allen anderen Firlefanz beiseite läßt. Du wirst mir ja sicherlich nicht einreden wollen, daß irgendjemand Deinen Account übernommen hat und da nun ein "social bot" mit digitalem Tourette-Syndrom schreibt.
Ich konnte bis zu diesem Zeitpunkt (#1396) noch nicht einmal erahnen, daß Du auf einer 7580 bist - außer Du willst mir jetzt erklären, Du hättest das schon vor Monaten mal geschrieben und ich hätte daraus jetzt ableiten müssen, daß Du alle meine Warnungen und Ablehnungen zur 7580 konsequent ignorierst. Wenn Du das machst, ist das immer noch Dein eigenes Problem.
Auf einer 7490 sollte das Problem schon deshalb eher nicht ebenso auftreten können, weil da nur in den seltensten Fällen noch genug freier Speicher zum Entpacken des Template-Filesystems vorhanden sein sollte, den ich mit 96 MB angesetzt habe. Hier sollte schon das laufende FRITZ!OS nicht genug Speicher bereitstellen können im "tmpfs", damit die erste Anforderung von 134 MB für das "Arbeitsverzeichnis" ($working_directory) befriedigt werden kann und damit landet das automatisch auf einem USB-Volume (oder im NAND, wenn man keine Vorkehrungen trifft), wo dann in der Folge auch das "$unpack_directory" in > 99% aller Fälle landen wird, solange ein Arbeitsverzeichnis im ersten Schritt ausgewählt wurde, welches den angegebenen Anforderungen von 256 MB freiem Speicherplatz gerecht wird.
Ich hätte gar kein Problem damit gehabt, die erwähnten Dateien tatsächlich früher zu löschen ... aber das, was Du hier als "Fehlermeldung" verbrämen willst, war (zumindest im Original und ich recherchiere jetzt nicht noch extra, welche Stellen Du im Nachgang alle noch entschärft hast) eine einzige Abfolge von Unverschämtheiten - bis hin zur Feststellung, Du würdest Dich nur wegen meiner schlampigen Programmierung darüber wundern müssen, warum auch bei einer (noch einmal: nicht mal im Ansatz von mir unterstützten) 7580 beim Arbeiten nur im Hauptspeicher der Platz nicht ausreichen würde.
Dabei hast Du es nicht einmal dabei auf die Reihe gebracht, das mit einer konkreten Fehlermeldung zu untermauern. Es ist schon ein erheblicher Unterschied, ob das bereits beim Suchen nach freiem Speicher, beim Entpacken, beim Einpacken oder gar erst beim Kopieren unter dem Ausgabenamen (das ist nämlich auch noch einmal ein "cp"-Kommando und braucht damit noch einmal denselben Platz, wenn man das vom "tmpfs" als Arbeitsverzeichnis ins "tmpfs" als Zielverzeichnis kopieren läßt) geschieht ... das Einzige, was Du ganz sicher wußtest, war der Dateiname "firmware.image" und inzwischen weißt Du auch, daß es am Ende nur an meiner Unfähigkeit liegt.
Weißt Du was? Mach' es besser oder nur "anders" oder mach' einfach was Du willst ... Du bist weder verpflichtet, "modfs" zu benutzen noch bin ich dazu bereit, in diesem Stil mit Dir weiterhin zu diskutieren. Wenn ich einen echten Grund dafür finden sollte, die Dateien schon früher zu löschen, werde ich mir das überlegen und es dann (weil ich selbst es als richtig erachte) auch umsetzen.
Mir fallen aber garantiert noch mind. zwei Gründe ein, warum man genau die "filesystem.image" (mit dem Inhalt des "wrapper"-Dateisystems)
noch braucht (und damit ein Löschen an zusätzliche Bedingungen knüpfen muß). Das ist nämlich nur dann nicht der Fall, wenn man das Wrapper-FS gar nicht installieren will und das wäre - unbestritten - sogar der von Dir genutzte (Sonder-)Fall (ich will nicht noch einmal darauf hinweisen, daß ich schon den eigentlich eher auf Deinen Wunsch als wegen einer tatsächlichen Notwendigkeit eingebaut habe - auch wenn das natürlich andere ebenfalls benutzen dürfen) ... aber in allen anderen Fällen (wo die Datei überhaupt existiert und das ist nur bei "update" der Fall) wird es eben auch nach dem Einpacken noch benötigt und da finde ich Deine Behauptung, es wäre "unsauber programmiert", wenn die Datei am Breakpoint noch nicht gelöscht ist, schon reichlich kühn.
Das widerlegt auch unmittelbar Deine Annahme/Aussage, man müßte gar nicht mehr wissen, wie "modfs" aufgerufen wurde und könnte das gesamte Verzeichnis praktisch in jedem Falle löschen ... wenn ich das falsch verstanden habe, kannst Du mir ja (bitte in einer "originalen Version" und nicht durch nachträgliches Redigieren) einfach zeigen, wo Du das so erklärt hast, daß es nur für den speziellen Fall, daß auf der Box nichts zu installieren ist, geschehen sollte (also bei "update" mit zwei zusätzlichen Parametern).
Und die "filesystem_core.squashfs" (mit dem originalen Inhalt des AVM-Dateisystems bzw. genauer mit dem Template für weitere Änderungen, denn es kann sich ja auch um ein Freetz-Image handeln) lasse ich u.a. auch deshalb noch stehen, weil man dann versehentlich manuell modifizierte Dateien auch am "Breakpoint" noch jederzeit erneut extrahieren kann - man hat nämlich in aller Regel zuvor festgelegt, wo diese Dateien zu finden sein werden (halt auf dem Datenträger, wohin man das Arbeitsverzeichnis legen läßt, wenn man danach gefragt wird).
Diese Datei (filesystem_core.squashfs) steht zwar auch noch einmal in der "filesystem.image" (weil ich die nicht extra zerlegen will, wenn es sich um ein SquashFS-Image handelt und auch bei einem ext2-Image nutzt es mal genau gar nichts, wenn man eine Datei löscht - dadurch wird das Image nicht automatisch kleiner) - aber da ist sie eben nicht ohne weiteres zugänglich und müßte erst noch einmal extrahiert werden. Die wenigsten "modfs"-Benutzer werden das von Hand machen wollen - bei einigen anderen Modi ist das wieder nicht erforderlich (z.B. weil diese Datei im aktiven Wrapper-FS ohnehin vorhanden ist oder von einem USB-Volume entpackt werden kann) und dann gibt es auch keine nutzlose Kopie davon im "tmpfs" ... ich würde also schon einschätzen, daß ich mit dem verfügbaren Platz einigermaßen verantwortungsvoll umgehe.
