Die rc.user und die debug.cfg sollten identisch sein.
Warum?
So ein TFFS-Node ist nichts weiter als ein "Fenster" oder ein "spy hole" (Guckloch) in den TFFS-Treiber (der speichert seine Daten dann irgendwo, wo das genau erfolgt, spielt hier keine Rolle). Wenn da durch das Fenster mit der Nummer 98 gesehen wird, steht da irgendein Inhalt. Egal wie man das "Fenster" (die Gerätedatei) im Filesystem nennt, man sieht immer denselben Inhalt im TFFS ... halt unter verschiedenen Namen.
Da es sich beim TFFS-Treiber um einen Treiber für "zeichenorientierte Geräte" (char-Devices) handelt, unterstützt der bestimmte Dateioperationen nicht, in erster Linie ist es hier das Positionieren des Lese-/Schreibzeigers an eine festgelegte Stelle ... einer der entscheidenden Gründe dafür dürfte es sein, daß die Daten im Hintergrund komprimiert gespeichert werden und man daher zur Ermittlung so einer Position die Datei in einen Zwischenpuffer entpacken müßte. Also verzichtet man einfach auf solche Positionier-Operationen (lseek()), denn bei vielen char-Devices machen die ohnehin keinen Sinn. Es ist wenig zielführend, z.B. bei einer Tastatur (das klassische Beispiel für ein "char device") sich an das Ende der "Datei" zu positionieren.
Im Ergebnis kann man eben solche Dateien nicht fortschreiben (dazu müßte man sich ja an das Ende des bisherigen Inhalts positionieren) und da viele normale Programme auch gerne mal auf so ein lseek() zurückgreifen (das geht vom FTP-Server bis zum Editor "vi"), ist es am einfachsten, den aktuellen Inhalt so eines TFFS-Nodes in eine reguläre Datei zu schreiben (dort geht dann auch lseek() und vieles andere) und dort zu be- oder verarbeiten.
Das macht man am besten mit dem Kommando "cat", wobei auch jedes andere Kommando, welches sich auf unterstützte Operationen beschränkt, benutzt werden kann ... es gibt z.B. keinen Grund, für die Suche innerhalb einer "TFFS-Datei" mit "grep" oder "sed" erst eine solche Kopie anzulegen. Für das Zurückschreiben von Inhalten in einen TFFS-Node ("in einem Rutsch", denn Positionieren geht eben nicht) verwendet man am einfachsten ebenfalls "cat".
Damit gibt es eben nicht wirklich zwei verschiedene "Dateien" rc.user und debug.cfg ... macht man es richtig (wie gesagt, beide Namen sind Schall und Rauch und man könnte die Datei auch "Max_und_Moritz" nennen), dann beziehen sich beide Gerätedateien auf dasselbe "peephole" ins TFFS.
Die Änderung durch "modfs" beim Start macht jetzt nichts anderes, als am Ende des Init-Prozesses den Inhalt dieses TFFS-Nodes in die Datei /var/tmp/rc.user zu übertragen und von dort auszuführen. Theoretisch könnte man danach diese Datei auch gleich wieder löschen, denn eine Änderung an dieser
kann keine Auswirkungen auf den Inhalt des TFFS haben ... diese Datei ist nur eine Kopie des Inhalts beim Start des Systems.
Für die Änderung am Inhalt des TFFS habe ich extra das Skript "edit_rcuser" zum modfs hinzugefügt. Dieses macht nichts anderes, als den aktuellen Inhalt des TFFS in eine temporäre Datei zu schreiben und einen Editor für diese "Kopie" des Inhalts aufzurufen. Wird dann der Editor beendet, wird der neue und der alte Inhalt verglichen und sollte etwas geändert worden sein, kann man sich entscheiden, den neuen Inhalt dieser Kopie in das TFFS zu schreiben. Auch hier besteht praktisch kein Zusammenhang mehr zur "/var/tmp/rc.user", diese ist nicht der Gegenstand der Änderung mit "edit_rcuser" und damit vorgenommene Änderungen werden auch nicht in dieser Datei sichtbar (erst nach dem nächsten Start, wenn sie wieder eine Kopie des dann aktuellen Inhalts ist).
Ändert man jetzt den Inhalt des TFFS-Node 98 auf irgendeinem anderen Weg, muß man sich nur an dieses Vorgehen halten.
Insofern kann man auch immer schlecht sagen, ob jemand bei der Nennung von "debug.cfg" nun das richtige Vorgehen beim Editieren verwendet oder nicht. Wenn es sich bei dieser "debug.cfg" um eine mit "mknod" eingerichtete Gerätedatei für den Node 98 im TFFS-Treiber handelt, dann ist das eben ein anders benanntes "Fenster" ins TFFS und man kann (unter Beachtung der oben gemachten Bemerkungen) auch den Inhalt über diesen "Namen" ändern. Ist das eine vollkommen andere (reguläre) Datei, ist das eben auch eine vollkommen andere Stelle im Dateisystem.
Normalerweise würde so eine geänderte reguläre Datei "/var/flash/debug.cfg" auch einfach beim nächsten Start wieder verschwunden sein und damit merkt man schon daran, daß man bei der Änderung etwas falsch gemacht hat ... aber hier kommt jetzt eine weitere "Besonderheit" einiger NAND-Boxen zum Tragen. Diese mounten nämlich unter dem Pfad "/var/flash" eine kleine (1-2 MB) yaffs2-Partition, in der dann die "char devices" für den TFFS-Inhalt angelegt werden. Da dieses Dateisystem auch über einen Neustart hinaus seinen Inhalt behält, wird auch eine dort als "regular file" gespeicherte "debug.cfg" einen Neustart überleben. Da das aber ein anderer Speicherplatz ist (eben das yaffs2 und nicht das TFFS), "sieht" das System durch das Fenster 98 ins TFFS eben nicht das, was in der regulären Datei "debug.cfg" unter /var/flash steht.
Wenn hier also in einer "debug.cfg" etwas steht, was beim Systemstart nicht ausgeführt wird, liegt die Vermutung nahe, daß es eben der falsche Speicherort ist. Der tatsächliche Inhalt des TFFS-Nodes wird folgendermaßen angezeigt (als Einzeiler für C&P):
Code:
m=$(sed -ne "s|^\([0-9]*\) tffs\$|\1|p" /proc/devices);[ -n "$m" ] && ( mknod /tmp/98 c $m 98;cat /tmp/98;rm /tmp/98 );unset m
Zuerst wird die "major ID" des TFFS-Treibers ermittelt (die ist dynamisch und zwar relativ stabil für ein Modell (und einen Kernel), aber das muß nicht immer so bleiben - das hängt damit zusammen, wie der TFFS-Treiber im Kernel initialisiert wird) und wenn diese gefunden wird, dann wird ein "char device" mit der "minor ID" 98 angelegt im /tmp-Verzeichnis, dessen Inhalt angezeigt und im Anschluß wird diese "Datei" dann auch gleich wieder gelöscht. Wäre das jetzt eine reguläre Datei, wäre zusammen mit dem Datei-Inode natürlich auch der Inhalt verschwunden (in Grenzen, aber das ist ein anderes Thema) ... hier wird lediglich das Fenster wieder geschlossen und der Inhalt dahinter bleibt erhalten.
