find: . changed during execution of find (sorry, but again)
Hi Leute,
ich weiß, wir hatten das Thema bereits mehrfach ... aber könnte mir
vielleicht mal jemand erklären, wieso das so sein soll? Ich verstehe es
schlicht und einfach nicht!!!!!!!!!
Folgendes:
Unter bestimmten Bedingungen liefert find die Fehlermeldung "find: .
changed during execution of find" und verweigert die Erfüllung der
gestellten Aufgabe!!
Meine Umgebung ist wie folgt:
Linux: SuSE 9.2
Aktuelles Verzeichnis: /home/martin
Inhalt von "/media/dvdrekorder/": SuSE 10.1 Installations DVD
Version von find: 4.1.20
Aufruf von find: find /media/dvdrekorder/
-type f -fprint xxx
Ausgabe von find: "find: . changed during
execution of find"
Inhalt der Datei "xxx":
Am Freitag, 10. November 2006 12:13 schrieb Martin Deppe:
(...). Frage: was soll dieser Mist?
Sieh dir diese Threads an: http://lists.suse.com/archive/suse-linux-e/2005-Jan/0466.html http://lists.suse.com/archive/suse-linux-e/2005-Jan/0346.html
Ich befinde mich in meinem Homeverzeichnis, möchte alle Dateien unterhalb von "/media/dvdrekorder" (auf der DVD) in der Datei "xxx" aufgelistet bekommen, aber find sagt mir, was auch vollkommen richtig ist, daß sich das aktuelle Verzeichnis während seiner Ausführung geändert hätte. (...).
subfs/automount und find vertragen sich wohl einfach nicht. Gruß Jan -- Most men who run down women are usually running down only one woman.
Am Freitag, 10. November 2006 12:44 schrieb Jan Ritzerfeld:
Am Freitag, 10. November 2006 12:13 schrieb Martin Deppe:
(...). Frage: was soll dieser Mist?
Sieh dir diese Threads an: http://lists.suse.com/archive/suse-linux-e/2005-Jan/0466.html http://lists.suse.com/archive/suse-linux-e/2005-Jan/0346.html (...).
Ich seh grad, bei beiden hast du selbst mitgeschrieben, daher wirst du sie wohl auch gelesen haben. Und in beiden wurde auch erklärt, was das Problem ist. Und das sind wohl gerade per subfs gemountete Verzeichnisse, wie eben genau das was du durchsuchen läßt (/media/dvdrecorder). Die Frage ist jetzt, kommt die Fehlermeldung auch, wenn du zuerst ein "cd /media/dvdrecorder" machst und dann "find . ..." aufrufst? Gruß Jan -- No amount of genius can overcome a preoccupation with detail.
Jan Ritzerfeld wrote:
Am Freitag, 10. November 2006 12:44 schrieb Jan Ritzerfeld:
Am Freitag, 10. November 2006 12:13 schrieb Martin Deppe:
(...). Frage: was soll dieser Mist?
Sieh dir diese Threads an: http://lists.suse.com/archive/suse-linux-e/2005-Jan/0466.html http://lists.suse.com/archive/suse-linux-e/2005-Jan/0346.html (...).
Ich seh grad, bei beiden hast du selbst mitgeschrieben, daher wirst du sie wohl auch gelesen haben. Und in beiden wurde auch erklärt, was das Problem ist. Und das sind wohl gerade per subfs gemountete Verzeichnisse, wie eben genau das was du durchsuchen läßt (/media/dvdrecorder). Die Frage ist jetzt, kommt die Fehlermeldung auch, wenn du zuerst ein "cd /media/dvdrecorder" machst und dann "find . ..." aufrufst?
Gruß Jan
Hallo Jan, es geht mir darum, daß ich EINEN Verzeichnisbaum checke, und nur genau den, der mit dem aktuellen Verzeichnis ÜBERHUAPT NICHTS zu tun hat. Und doch wird das aktuelle Verzeichnis von find gecheckt, ob sich dort etwas getan hat. Und ja, ich habe obige Threads natürlich mit verfolgt, aber auch dort/damals konnte mir niemand zufriedenstellend erklären, warum find so programmiert wurde, wie es ist. Und nein, ich denke nicht, daß es eine Sache zwischen subfs und find ist. Ich denke, jetzt, daß es eine Sache von find ist!!! An Deinem Vorschlag, ein "cd" in das Verzeichnis zu machen, ist zwar grundsätzlich nichts falsch, geht aber an der Sache vorbei. Immerhin ist find ja prinzipiell so programmiert, daß ich es sowohl so als auch so, wie ich es gemacht habe, machen kann und es ist nichts falsch daran, die Standardausgabe von find in eine Datei im aktuellen Verzeichnis umzuleiten. Wenn ich dies aber tue, laufe ich genau auf obiges Problem - zumindest, wenn ich ein völlig anderes Verzeichnis durchsuche. Ich denke, daß sollte von jedem leicht nachzuvollziehen sein. Wie auch immer, ich habe mir mein eigenes find jetzt gebaut - das funktioniert - auch mit subfs! Und sollte ich damit nochmal auf ein Problem laufen, welches durch meine Änderung verursacht ist, werde ich mir den Kram nochmal genauer anschauen. Ich würde nur, wie gesagt, gern verstehen, was der Hintergrund dieser Vorgehensweise ist. Gruß Martin
Am Freitag, 10. November 2006 13:26 schrieb Martin Deppe:
(...). es geht mir darum, daß ich EINEN Verzeichnisbaum checke, und nur genau den, der mit dem aktuellen Verzeichnis ÜBERHUAPT NICHTS zu tun hat. Und doch wird das aktuelle Verzeichnis von find gecheckt, ob sich dort etwas getan hat.
Das hast du im Source von find verifiziert oder woher weißt du das so genau? Außerdem ist das findutils von SL 9.2 natürlich uralt. Hast du mal eine aktuelle Version probiert/analysiert? http://savannah.gnu.org/support/?func=detailitem&item_id=101535 http://savannah.gnu.org/bugs/?func=detailitem&item_id=9043 http://savannah.gnu.org/bugs/?func=detailitem&item_id=3998
Und ja, ich habe obige Threads natürlich mit verfolgt, aber auch dort/damals konnte mir niemand zufriedenstellend erklären, warum find so programmiert wurde, wie es ist.
http://www.gnu.org/software/findutils/manual/html_node/find_html/Error-Messa... Normalerweise will man, daß find nur den Zustand berücksichtigt, der zum Zeitpunkt des Aufrufs herrschte. Der harmloseste Fall tritt auf, wenn ein Verzeichnis verschoben wird während find läuft und find es somit mehrfach berücksichtigen würde.
(...). An Deinem Vorschlag, ein "cd" in das Verzeichnis zu machen, ist zwar grundsätzlich nichts falsch, geht aber an der Sache vorbei. (...).
Jein. Ich will damit sicherstellen, daß es wirklich am "."-Verzeichnis liegt und "find: . changed during execution of find" nicht nur eine leicht irreführende Warnung ist. Daher ist es schon interessant in welchen "."-Verzeichnissen das Problem überhaupt auftritt. Alternativ könntest du in ein Verzeichnis erstellen, in den ein "find ." funktioniert. Und dann von dort aus "find /media/dvdrecorder" ausführen. Wenn das dann funktioniert, wird es wirklich am $HOME liegen. Es würde mich ehrlich gesagt wundern, weil ich mein Home ohne Probleme durchsuchen kann. Aber ich benutze auch ein aktuelles find. Gruß Jan -- One man's wage rise is another man's price increase. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-de+help@opensuse.org
Jan Ritzerfeld wrote:
Am Freitag, 10. November 2006 13:26 schrieb Martin Deppe:
(...). es geht mir darum, daß ich EINEN Verzeichnisbaum checke, und nur genau den, der mit dem aktuellen Verzeichnis ÜBERHUAPT NICHTS zu tun hat. Und doch wird das aktuelle Verzeichnis von find gecheckt, ob sich dort etwas getan hat.
Das hast du im Source von find verifiziert oder woher weißt du das so genau? Außerdem ist das findutils von SL 9.2 natürlich uralt. Hast du mal eine aktuelle Version probiert/analysiert? http://savannah.gnu.org/support/?func=detailitem&item_id=101535 http://savannah.gnu.org/bugs/?func=detailitem&item_id=9043 http://savannah.gnu.org/bugs/?func=detailitem&item_id=3998
Und ja, ich habe obige Threads natürlich mit verfolgt, aber auch dort/damals konnte mir niemand zufriedenstellend erklären, warum find so programmiert wurde, wie es ist.
http://www.gnu.org/software/findutils/manual/html_node/find_html/Error-Messa... Normalerweise will man, daß find nur den Zustand berücksichtigt, der zum Zeitpunkt des Aufrufs herrschte. Der harmloseste Fall tritt auf, wenn ein Verzeichnis verschoben wird während find läuft und find es somit mehrfach berücksichtigen würde.
(...). An Deinem Vorschlag, ein "cd" in das Verzeichnis zu machen, ist zwar grundsätzlich nichts falsch, geht aber an der Sache vorbei. (...).
Jein. Ich will damit sicherstellen, daß es wirklich am "."-Verzeichnis liegt und "find: . changed during execution of find" nicht nur eine leicht irreführende Warnung ist. Daher ist es schon interessant in welchen "."-Verzeichnissen das Problem überhaupt auftritt. Alternativ könntest du in ein Verzeichnis erstellen, in den ein "find ." funktioniert. Und dann von dort aus "find /media/dvdrecorder" ausführen. Wenn das dann funktioniert, wird es wirklich am $HOME liegen. Es würde mich ehrlich gesagt wundern, weil ich mein Home ohne Probleme durchsuchen kann. Aber ich benutze auch ein aktuelles find.
Antwort(en) siehe unten ...
Gruß Jan
Hallo Jan, ich war in Gedanken schon dabei, nach dem Motto "mea culpa", mir Formulierungen zu überlegen, Dir/hier zu antworten. Schließlich hatte ich in der Tat find nicht in der aktuellen Version 4.3.1, sondern in Version 4.1.20 verwendet. Aber bevor ich mich wieder in die Nesseln setze, bin ich Deinem Rat gefolgt und habe mir eben die neueste Version runtergeladen und es damit versucht. (übrigens Danke für den Link) Ja, und da falle ich doch fast vom Glauben ab! Mir fehlen die Worte, mir fehlen wirklich die Worte: martin@martin4:/home/martin> /usr/src/packages/SOURCES/findutils-4.3.1/find/find /media/dvdrecorder/ -type f -fprint xxx /usr/src/packages/SOURCES/findutils-4.3.1/find/find: /media/dvdrecorder/: No such file or directory martin@martin4:/home/martin> ls -l /media/dvdrecorder/ total 1692887 -r--r--r-- 1 martin users 2048 2006-05-30 15:06 boot.catalog -r--r--r-- 1 martin users 189952 2006-05-30 15:06 bootlogo dr-xr-xr-x 2 martin users 2048 2006-05-30 15:06 bootspl.inc -r--r--r-- 1 martin users 1695174669 2006-05-30 15:05 cloop.img -r--r--r-- 1 martin users 225 2006-05-23 12:10 gfxboot.cfg -r--r--r-- 1 martin users 36796916 2006-05-30 15:06 initrd.gz -r--r--r-- 1 martin users 12880 2006-04-28 16:00 isolinux.bin -r--r--r-- 1 martin users 441 2006-05-23 12:09 isolinux.cfg dr-xr-xr-x 2 martin users 2048 2006-05-30 15:06 media.1 -r--r--r-- 1 martin users 274 2004-07-26 18:28 txtmsg -r--r--r-- 1 martin users 1332562 2006-05-03 12:41 vmlinuz martin@martin4:/home/martin> Das Verzeichnis ist mitnichten leer oder existiert nicht (wie man oben auch sehen kann) und ich stelle fest, respektive schlußfolgere, daß find offensichtlich jetzt tatsächlich ein Problem mit subfs hat!! Oder könnte es vielleicht sein, daß find in der Version 4.3.1 auch gleichzeitig ein Linux in aktueller Version braucht (nicht mein SuSE 9.2), um korrekt zu funktionieren? Ich bin echt platt! Ich habe jetzt nicht weiter untersucht, wie es auf den "Gedanken" kommt "no such file or directory". Und, nur um sicher zu gehen, habe ich gerade noch einmal überprüft, wie denn die Datei "xxx" jetzt aussieht. Sie ist leer! Ich fasse es einfach nicht ... Also, liegt das jetzt alles an mir und daran, daß ich so unmögliche Wünsche an/Vorstellungen von find habe? Und was mir noch aufgefallen ist: Die ausführbare Datei der Version 4.3.1 ist ca. DOPPELT so groß wie die der Version 4.1.20. Wie kommt denn das? Meine Antworten zu oben: Ich habe find aus meinem $HOME aufgerufen und als Startverzeichnis ein völlig anderes angegeben. Ich bin der Ansicht, daß (zumindest in diesem Fall) find sich einen Dreck darum scheren sollte, was im aktuellen Verzeichnis passiert. Ich wiederhole nochmal: Genau genommen soll find mir eine Liste der Dateien von einem völlig anderen Gerät liefern, als das, aus dem heraus es gestartet wurde. Also, find ist offensichtlich eine Welt für sich und dabei bin ich eigentlich ein großer Anhänger dieses Tools. Martin --------------------------------------------------------------------- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo, Am Fre, 10 Nov 2006, Martin Deppe schrieb:
Jein. Ich will damit sicherstellen, daß es wirklich am "."-Verzeichnis liegt und "find: . changed during execution of find" nicht nur eine leicht irreführende Warnung ist.
Bevor du hier rumbrüllst (wie in deinen ersten Mails), werf mal 'ltrace' an! Guckstu: ~ $ ltrace -echdir,opendir find /tmp/test/ -type d chdir("/tmp/test/") = 0 opendir(".") = 0x08050f00 Und? Welches Verzeichnis wird als "." geoeffnet?
4.3.1 ist ca. DOPPELT so groß wie die der Version 4.1.20. Wie kommt denn das?
Die ist noch nicht gestrippt. Das wird erst beim 'make install' erledigt. Und ja, doppelt so gross ist normal. -dnh -- Speed doesn't kill... Impact does. -- David Wilcox --------------------------------------------------------------------- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Freitag, 10. November 2006 21:31 schrieb David Haller:
Am Fre, 10 Nov 2006, Martin Deppe schrieb:
Jein. Ich will damit sicherstellen, daß es wirklich am "."-Verzeichnis liegt und "find: . changed during execution of find" nicht nur eine leicht irreführende Warnung ist.
Bevor du hier rumbrüllst (wie in deinen ersten Mails),
Wer jetzt? Ich fühl mich irgendwie angesprochen. Denn der obige Text ist ursprünglich von mir, du hast das "Jan Ritzerfeld wrote:" unterschlagen.
werf mal 'ltrace' an! Guckstu:
~ $ ltrace -echdir,opendir find /tmp/test/ -type d chdir("/tmp/test/") = 0 opendir(".") = 0x08050f00
Und? Welches Verzeichnis wird als "." geoeffnet? (...).
Genau das meinte ich ja. Gruß Jan -- The right half of the brain controls the left half of the body. This means that only left handed people are in their right mind. --------------------------------------------------------------------- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Freitag, 10. November 2006 15:46 schrieb Martin Deppe:
Aber bevor ich mich wieder in die Nesseln setze, bin ich Deinem Rat gefolgt und habe mir eben die neueste Version runtergeladen und es damit versucht. (übrigens Danke für den Link)
Du könntest auch versuchen, ein src.rpm eines neueren SL mit "rpmbuild --rebuild ..." neu zu bauen.
Ja, und da falle ich doch fast vom Glauben ab! Mir fehlen die Worte, mir fehlen wirklich die Worte:
martin@martin4:/home/martin> /usr/src/packages/SOURCES/findutils-4.3.1/find/find /media/dvdrecorder/ -type f -fprint xxx /usr/src/packages/SOURCES/findutils-4.3.1/find/find: /media/dvdrecorder/: No such file or directory martin@martin4:/home/martin> ls -l /media/dvdrecorder/ total 1692887 -r--r--r-- 1 martin users 2048 2006-05-30 15:06 boot.catalog -r--r--r-- 1 martin users 189952 2006-05-30 15:06 bootlogo dr-xr-xr-x 2 martin users 2048 2006-05-30 15:06 bootspl.inc -r--r--r-- 1 martin users 1695174669 2006-05-30 15:05 cloop.img -r--r--r-- 1 martin users 225 2006-05-23 12:10 gfxboot.cfg -r--r--r-- 1 martin users 36796916 2006-05-30 15:06 initrd.gz -r--r--r-- 1 martin users 12880 2006-04-28 16:00 isolinux.bin -r--r--r-- 1 martin users 441 2006-05-23 12:09 isolinux.cfg dr-xr-xr-x 2 martin users 2048 2006-05-30 15:06 media.1 -r--r--r-- 1 martin users 274 2004-07-26 18:28 txtmsg -r--r--r-- 1 martin users 1332562 2006-05-03 12:41 vmlinuz martin@martin4:/home/martin>
Guck dir mal die Ausgaben von strace /usr/src/packages/SOURCES/findutils-4.3.1/find/find /media/dvdrecorder/ und strace ls -l /media/dvdrecorder/ an und vergleiche sie. Ja, die sind lang und vieles davon ist unwichtig. Aber irgendwo wirst du sehen, was find versucht und nicht schafft und was ls eben anders macht.
Das Verzeichnis ist mitnichten leer oder existiert nicht (wie man oben auch sehen kann) und ich stelle fest, respektive schlußfolgere, daß find offensichtlich jetzt tatsächlich ein Problem mit subfs hat!! Oder könnte es vielleicht sein, daß find in der Version 4.3.1 auch gleichzeitig ein Linux in aktueller Version braucht (nicht mein SuSE 9.2), um korrekt zu funktionieren?
Das halte ich eher für unwahrscheinlich. Wenn, dann hat SUSE das find von der 9.2 angepaßt, damit es ein wenig besser mit subfs zurecht kommt.
Also, liegt das jetzt alles an mir und daran, daß ich so unmögliche Wünsche an/Vorstellungen von find habe?
Vielleicht ist dir auch nur die Funktionsweise sowohl von subfs als auch find reichlich unklar. David hat dazu ja schon was geschrieben, wie du mal vernünftig herausfinden kannst, woran genau es liegt.
(...). Meine Antworten zu oben: Ich habe find aus meinem $HOME aufgerufen und als Startverzeichnis ein völlig anderes angegeben. Ich bin der Ansicht, daß (zumindest in diesem Fall) find sich einen Dreck darum scheren sollte, was im aktuellen Verzeichnis passiert. (...).
Nochmal: Das ist mir schon klar. Nur deine Behauptung, daß es sich um das aktuelle Verzeichnis kümmert, bezweifle ich eben. Nur weil find "." sagt, muß sich das nicht auf das Verzeichnis beziehen, was vor dem Aufruf das aktuelle war. Daher sollst du das mal aus einem Verzeichnis heraus probieren, von dem du weißt, daß sich der "." keinesfalls auf eben dieses Verzeichnis beziehen kann.
Also, find ist offensichtlich eine Welt für sich und dabei bin ich eigentlich ein großer Anhänger dieses Tools.
Du schiebst das Problem die ganze Zeit auf find, nur weil es dir bei dessen Benutzung auffällt. subfs wird von aktuellen SL-Versionen eh nicht mehr benutzt. Daher wirst du wohl damit leben müssen. Gruß Jan -- When in doubt, take all the defaults. --------------------------------------------------------------------- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Jan Ritzerfeld wrote:
Am Freitag, 10. November 2006 15:46 schrieb Martin Deppe:
Aber bevor ich mich wieder in die Nesseln setze, bin ich Deinem Rat gefolgt und habe mir eben die neueste Version runtergeladen und es damit versucht. (übrigens Danke für den Link)
Du könntest auch versuchen, ein src.rpm eines neueren SL mit "rpmbuild --rebuild ..." neu zu bauen.
Also, da stellt sich mir erst einmal eine Frage: Wozu ist das gut bzw. was soll das bewirken? (ich kenne rpmbuild nicht weiter und habe noch nie ein RPM gebaut)
Ja, und da falle ich doch fast vom Glauben ab! Mir fehlen die Worte, mir fehlen wirklich die Worte:
martin@martin4:/home/martin> /usr/src/packages/SOURCES/findutils-4.3.1/find/find /media/dvdrecorder/ -type f -fprint xxx /usr/src/packages/SOURCES/findutils-4.3.1/find/find: /media/dvdrecorder/: No such file or directory martin@martin4:/home/martin> ls -l /media/dvdrecorder/ total 1692887 -r--r--r-- 1 martin users 2048 2006-05-30 15:06 boot.catalog -r--r--r-- 1 martin users 189952 2006-05-30 15:06 bootlogo dr-xr-xr-x 2 martin users 2048 2006-05-30 15:06 bootspl.inc -r--r--r-- 1 martin users 1695174669 2006-05-30 15:05 cloop.img -r--r--r-- 1 martin users 225 2006-05-23 12:10 gfxboot.cfg -r--r--r-- 1 martin users 36796916 2006-05-30 15:06 initrd.gz -r--r--r-- 1 martin users 12880 2006-04-28 16:00 isolinux.bin -r--r--r-- 1 martin users 441 2006-05-23 12:09 isolinux.cfg dr-xr-xr-x 2 martin users 2048 2006-05-30 15:06 media.1 -r--r--r-- 1 martin users 274 2004-07-26 18:28 txtmsg -r--r--r-- 1 martin users 1332562 2006-05-03 12:41 vmlinuz martin@martin4:/home/martin>
Guck dir mal die Ausgaben von strace /usr/src/packages/SOURCES/findutils-4.3.1/find/find /media/dvdrecorder/ und strace ls -l /media/dvdrecorder/ an und vergleiche sie. Ja, die sind lang und vieles davon ist unwichtig. Aber irgendwo wirst du sehen, was find versucht und nicht schafft und was ls eben anders macht.
Ich habe mal die Ausgabe des 'strace' von' find' Version 4.1.20 ("find-4.1.20.strace") und ebenso von Version 4.3.1 ('find-4.3.1.strace') angehängt! Um die Ausgabe nicht zu umfangreich werden zu lassen, habe ich mir erlaubt, eine Diskette mit lediglich wenigen Dateien und einem Unterverzeichnis statt der DVD zu verwenden. Da es sich dabei auch um ein per subfs eingebundenes Verzeichnis handelt, gibt es ansonsten keinen Unterschied.
Das Verzeichnis ist mitnichten leer oder existiert nicht (wie man oben auch sehen kann) und ich stelle fest, respektive schlußfolgere, daß find offensichtlich jetzt tatsächlich ein Problem mit subfs hat!! Oder könnte es vielleicht sein, daß find in der Version 4.3.1 auch gleichzeitig ein Linux in aktueller Version braucht (nicht mein SuSE 9.2), um korrekt zu funktionieren?
Das halte ich eher für unwahrscheinlich. Wenn, dann hat SUSE das find von der 9.2 angepaßt, damit es ein wenig besser mit subfs zurecht kommt.
Gut, Danke, sehe ich auch nicht so!
Also, liegt das jetzt alles an mir und daran, daß ich so unmögliche Wünsche an/Vorstellungen von find habe?
Vielleicht ist dir auch nur die Funktionsweise sowohl von subfs als auch find reichlich unklar. David hat dazu ja schon was geschrieben, wie du mal vernünftig herausfinden kannst, woran genau es liegt.
Ok, also dann beschreibe ich mal, wie ich das verstehe: subfs ist ein System, welches sich zwischen Kernel und Gerätetreiber klemmt, um im Falle des Zugriffs seitens einer Anwendung auf einen Wechseldatenträger zu prüfen, ob ein solcher Wechseldatenträger verfügbar ist, eben diesen bei Anwesenheit einbindet und den Zugriff unter den dann geltenden Bedingungen durchführt. Die Anwendung bekommt davon überhaupt nichts mit und müßte schon, um (nur) einen Indiz zu erhalten, eine Zeitmessung durchführen, die aber auch nur beim allerersten Zugriff auf das Medium (nach Einlegen) funktioniert, solange sie nicht auf subfs (oder gegebenenfalls Komponenten) selbst zugreift und entsprechende Anfragen stellt. Ich verstehe das System so, daß es transparent für die Anwendung (oder selbst den Kernel) sein soll und IST. Ich als Mensch bekomme etwas davon mit, weil ich denke und ein Gefühl für Zeit habe, eine Anwendung jedoch kann weder das eine noch hat sie das andere und müte schon konkrete (Zeit-)Messungen machen, um überhaupt etwas davon mit zu bekommen - zumindest, solange kein Fehler auftritt, der einen entsprechenden Hinweis liefert, was aber auch nur dann als Hinweis erkannt wird, wenn die Fehlerursache näher untersucht wird. So, und 'find'? Nun, 'find' soll mir einfach durch einen Verzeichnisbaum wandern, ein paar Tests machen und, in Abhängigkeit der Ergebnisse dieser Tests, einige Ausgaben (respektive Aktionen) tätigen. Das ist eigentlich alles. Liege ich damit vielleicht völlig falsch?
(...). Meine Antworten zu oben: Ich habe find aus meinem $HOME aufgerufen und als Startverzeichnis ein völlig anderes angegeben. Ich bin der Ansicht, daß (zumindest in diesem Fall) find sich einen Dreck darum scheren sollte, was im aktuellen Verzeichnis passiert. (...).
Nochmal: Das ist mir schon klar. Nur deine Behauptung, daß es sich um das aktuelle Verzeichnis kümmert, bezweifle ich eben. Nur weil find "." sagt, muß sich das nicht auf das Verzeichnis beziehen, was vor dem Aufruf das aktuelle war.
Ok, das macht Sinn, aber es wäre dann auch wieder ein Problem von 'find'. Denn wenn '.' nicht das aktuelle Verzeichnis (aus dem heraus ich 'find' gestartet habe) ist, welches ist es dann? Woher soll ich denn als Anwender wissen, welches Verzeichnis '.' gerade für 'find' ist? Wenn '.' nicht '.' ist, müßte find mir nicht '.' anzeigen, sondern den vollen (oder zumindest relativen) Pfad dessen, was 'find' zur Zeit als '.' angibt. Sorry, aber in diesem Fall läge das Problem ursprünglich bei einem Mißverständnis des Programmierers bzw. Entwicklers. (ich bin selbst Techniker, Programmierer und Entwickler seit 1984 und ich denke, ich verstehe ein bißchen was davon)
Daher sollst du das mal aus einem Verzeichnis heraus probieren, von dem du weißt, daß sich der "." keinesfalls auf eben dieses Verzeichnis beziehen kann.
??? Der '.' bezieht sich IMMER auf das aktuelle Verzeichnis und wenn 'find' SEIN aktuelles Verzeichnis zur LAUFZEIT ÄNDERT, ist es durch den Anwender nicht nachvollziebar, in welchem Verzeichnis sich 'find' gerade befindet, wenn dieser Fehler auftritt. Ergo müßte 'find' nicht '.' sondern das entsprechende Verzeichnis angeben!!!
Also, find ist offensichtlich eine Welt für sich und dabei bin ich eigentlich ein großer Anhänger dieses Tools.
Du schiebst das Problem die ganze Zeit auf find, nur weil es dir bei dessen Benutzung auffällt.
Bei wessen Benutzung soll es mir denn sonst auffallen? 'find' ist das einzige Programm, bei dem ich dieses Problem festgestellt habe.
subfs wird von aktuellen SL-Versionen eh nicht mehr benutzt. Daher wirst du wohl damit leben müssen.
Ich fürchte, daß ändert nicht das Geringste am eigentlichen Problem, aber ich lasse mich gern eines besseren belehren und habe deshalb auch hier schon noch ein paar weitere Tests gemacht und festgestellt, daß es offensichtlich tatsächlich nur unter subfs auftritt. Zusätzlich habe ich aber auch festgestellt, daß der Aufruf KORREKT durchläuft, wenn ich ihn ein zweites Mal INNERHALB VON ZWEI SEKUNDEN wiederhole. Folgende Kommandosequenz: CMD="/usr/src/packages/SOURCES/findutils-4.1.20/find/find /media/floppy/ -type f -print"; $CMD; echo; $CMD; echo; sleep 2; $CMD liefert mir: ------------------ Beginn Ausgabe /usr/src/packages/SOURCES/findutils-4.1.20/find/find: . changed during execution of /usr/src/packages/SOURCES/findutils-4.1.20/find/find (3: stat..dev=512,dir..dev=17, stat..ino=1, dir..ino=4649) /media/floppy/kernel.sys /media/floppy/command.com /media/floppy/autoexec.bat /media/floppy/config.sys /media/floppy/Kommunikationstraining/Aufbau-des-Johari-Fensters.jpg /media/floppy/Kommunikationstraining/Kommunikationstraining2.ppt /usr/src/packages/SOURCES/findutils-4.1.20/find/find: . changed during execution of /usr/src/packages/SOURCES/findutils-4.1.20/find/find (3: stat..dev=512,dir..dev=17, stat..ino=1, dir..ino=4649) ------------------ Ende Ausgabe Bemerkung: Die Ausgabe "(3: ...)" von 'find' habe ich zum debuggen hinzugefügt. Meine weiter Suche (ausgehend vom strace) hat ergeben, daß das Verzeichnis offensichtlich mit dem Argument O_NONBLOCK geöffnet wird. Ich denke, daß das letztlich dafür verantwortlich ist. Würde das Verzeichnis im Nicht-O_NONBLOCK-Mode geöffnet werden, sollte das Problem nicht mehr auftreten. Leider habe ich noch nicht herausgefunden, wo das innerhalb 'find' eingestellt wird (wenn überhaupt) und muß jetzt erst mal los! Martin martin@martin4:/home/martin/Documents> strace /usr/src/packages/SOURCES/findutils-4.1.20/find/find /media/floppy/ execve("/usr/src/packages/SOURCES/findutils-4.1.20/find/find", ["/usr/src/packages/SOURCES/findutils-4.1.20/find/find", "/media/floppy/"], [/* 85 vars */])= 0 uname({sys="Linux", node="martin4", ...}) = 0 brk(0) = 0x8055000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 5 fstat64(5, {st_mode=S_IFREG|0644, st_size=98868, ...}) = 0 old_mmap(NULL, 98868, PROT_READ, MAP_PRIVATE, 5, 0) = 0x40018000 close(5) = 0 open("/lib/tls/libc.so.6", O_RDONLY) = 5 read(5, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\0L\1\000"..., 512) = 512 fstat64(5, {st_mode=S_IFREG|0755, st_size=1359489, ...}) = 0 old_mmap(NULL, 1137708, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 5, 0) = 0x40031000 madvise(0x40031000, 1137708, MADV_SEQUENTIAL|0x1) = 0 mprotect(0x40140000, 27692, PROT_NONE) = 0 old_mmap(0x40141000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 5, 0x10f000) = 0x40141000 old_mmap(0x40145000, 7212, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40145000 close(5) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40147000 mprotect(0x40141000, 4096, PROT_READ) = 0 set_thread_area({entry_number:-1 -> 6, base_addr:0x40147300, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0,useable:1}) = 0 munmap(0x40018000, 98868) = 0 brk(0) = 0x8055000 brk(0x8076000) = 0x8076000 [... Die ganze Locale Geschichte entfernt] time(NULL) = 1163242809 open(".", O_RDONLY|O_LARGEFILE) = 5 fchdir(5) = 0 lstat64(".", {st_mode=S_IFDIR|0755, st_size=5648, ...}) = 0 lstat64("/media/floppy/", {st_mode=S_IFDIR|0777, st_size=0, ...}) = 0 chdir("/media/floppy/") = 0 lstat64(".", {st_mode=S_IFDIR|0777, st_size=0, ...}) = 0 lstat64(".", {st_mode=S_IFDIR|0777, st_size=0, ...}) = 0 fstat64(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 0), ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40255000 write(1, "/media/floppy/\n", 15/media/floppy/ ) = 15 open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = ? ERESTARTSYS (To be restarted) --- SIGCONT (Continued) @ 0 (0) --- open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 6 fstat64(6, {st_mode=S_IFDIR|0755, st_size=512, ...}) = 0 fcntl64(6, F_SETFD, FD_CLOEXEC) = 0 getdents(6, /* 7 entries */, 512) = 164 getdents(6, /* 0 entries */, 512) = 0 close(6) = 0 lstat64(".", {st_mode=S_IFDIR|0755, st_size=512, ...}) = 0 lstat64("kernel.sys", {st_mode=S_IFREG|0755, st_size=78560, ...}) = 0 write(1, "/media/floppy/kernel.sys\n", 25/media/floppy/kernel.sys ) = 25 lstat64("command.com", {st_mode=S_IFREG|0755, st_size=78280, ...}) = 0 write(1, "/media/floppy/command.com\n", 26/media/floppy/command.com ) = 26 lstat64("autoexec.bat", {st_mode=S_IFREG|0755, st_size=55, ...}) = 0 write(1, "/media/floppy/autoexec.bat\n", 27/media/floppy/autoexec.bat ) = 27 lstat64("config.sys", {st_mode=S_IFREG|0755, st_size=70, ...}) = 0 write(1, "/media/floppy/config.sys\n", 25/media/floppy/config.sys ) = 25 lstat64("Kommunikationstraining", {st_mode=S_IFDIR|0755, st_size=512, ...}) = 0 write(1, "/media/floppy/Kommunikationstrai"..., 37/media/floppy/Kommunikationstraining ) = 37 open("Kommunikationstraining", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 6 fstat64(6, {st_mode=S_IFDIR|0755, st_size=512, ...}) = 0 fcntl64(6, F_SETFD, FD_CLOEXEC) = 0 getdents(6, /* 4 entries */, 512) = 116 getdents(6, /* 0 entries */, 512) = 0 close(6) = 0 chdir("Kommunikationstraining") = 0 lstat64(".", {st_mode=S_IFDIR|0755, st_size=512, ...}) = 0 write(1, "/media/floppy/Kommunikationstrai"..., 68/media/floppy/Kommunikationstraining/Aufbau-des-Johari-Fensters.jpg ) = 68 write(1, "/media/floppy/Kommunikationstrai"..., 65/media/floppy/Kommunikationstraining/Kommunikationstraining2.ppt ) = 65 chdir("..") = 0 lstat64(".", {st_mode=S_IFDIR|0755, st_size=512, ...}) = 0 fchdir(5) = 0 munmap(0x40255000, 4096) = 0 exit_group(0) = ? martin@martin4:/home/martin/Documents> strace /usr/src/packages/SOURCES/findutils-4.3.1/find/find /media/floppy/ execve("/usr/src/packages/SOURCES/findutils-4.3.1/find/find", ["/usr/src/packages/SOURCES/findutils-4.3.1/find/find", "/media/floppy/"], [/* 85 vars */]) =0 uname({sys="Linux", node="martin4", ...}) = 0 brk(0) = 0x805e000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 5 fstat64(5, {st_mode=S_IFREG|0644, st_size=98868, ...}) = 0 old_mmap(NULL, 98868, PROT_READ, MAP_PRIVATE, 5, 0) = 0x40018000 close(5) = 0 open("/lib/tls/libc.so.6", O_RDONLY) = 5 read(5, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\0L\1\000"..., 512) = 512 fstat64(5, {st_mode=S_IFREG|0755, st_size=1359489, ...}) = 0 old_mmap(NULL, 1137708, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 5, 0) = 0x40031000 madvise(0x40031000, 1137708, MADV_SEQUENTIAL|0x1) = 0 mprotect(0x40140000, 27692, PROT_NONE) = 0 old_mmap(0x40141000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 5, 0x10f000) = 0x40141000 old_mmap(0x40145000, 7212, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40145000 close(5) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40147000 mprotect(0x40141000, 4096, PROT_READ) = 0 set_thread_area({entry_number:-1 -> 6, base_addr:0x40147300, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0,useable:1}) = 0 munmap(0x40018000, 98868) = 0 uname({sys="Linux", node="martin4", ...}) = 0 ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0 time(NULL) = 1163242819 brk(0) = 0x805e000 brk(0x807f000) = 0x807f000 [... Die ganze Locale Geschichte entfernt] ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0 open(".", O_RDONLY|O_LARGEFILE) = 5 fchdir(5) = 0 lstat64("/media/floppy/", {st_mode=S_IFDIR|0777, st_size=0, ...}) = 0 open(".", O_RDONLY|O_NONBLOCK|O_NOCTTY|O_LARGEFILE|O_DIRECTORY) = 6 fchdir(6) = 0 fstat64(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 0), ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40255000 write(1, "/media/floppy/\n", 15/media/floppy/ ) = 15 open("/media/floppy/", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = ? ERESTARTSYS (To be restarted) --- SIGCONT (Continued) @ 0 (0) --- open("/media/floppy/", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 7 fstat64(7, {st_mode=S_IFDIR|0755, st_size=512, ...}) = 0 fcntl64(7, F_SETFD, FD_CLOEXEC) = 0 fstat64(7, {st_mode=S_IFDIR|0755, st_size=512, ...}) = 0 close(7) = 0 write(2, "/usr/src/packages/SOURCES/findut"..., 53/usr/src/packages/SOURCES/findutils-4.3.1/find/find: ) = 53 write(2, "/media/floppy/", 14/media/floppy/) = 14 [... Noch mehr Locale Geschichte entfernt] write(2, ": No such file or directory", 27: No such file or directory) = 27 write(2, "\n", 1 ) = 1 fchdir(6) = 0 close(6) = 0 close(1) = 0 munmap(0x40255000, 4096) = 0 exit_group(1) = ?
Kennst du das hier schon: http://lists.suse.com/archive/suse-linux/2005-May/2352.html oder hast du vor lauter Aufregung vergessen zu googlen? -- Viele Grüße ------------------------------------------------------------------------ Michael --------------------------------------------------------------------- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Michael Behrens wrote:
Kennst du das hier schon: http://lists.suse.com/archive/suse-linux/2005-May/2352.html oder hast du vor lauter Aufregung vergessen zu googlen?
Danke und ja, findet aber in diesem Fall keine Anwendung, wie ich bereits die ganze Zeit zu verdeutlichen versuche! Ich habe zwar ein per subfs eingehängtes Dateisystem, welches ich untersuche, ändere aber während des Suchlaufs nichts daran und befinde mich bei Aufruf von find in einem völlig anderen Verzeichnis, als durchsucht wird! Martin --------------------------------------------------------------------- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Freitag 10 November 2006 15:50 schrieb Martin Deppe:
Danke und ja, findet aber in diesem Fall keine Anwendung, wie ich bereits die ganze Zeit zu verdeutlichen versuche!
Ich habe zwar ein per subfs eingehängtes Dateisystem, welches ich untersuche, ändere aber während des Suchlaufs nichts daran und befinde mich bei Aufruf von find in einem völlig anderen Verzeichnis, als durchsucht wird!
Und der Lauf von find bewirkt auch nicht, dass subfs etwas mountet? Das ist alles schon vorher gemountet??? -- Viele Grüße ------------------------------------------------------------------------ Michael --------------------------------------------------------------------- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Michael Behrens wrote:
Am Freitag 10 November 2006 15:50 schrieb Martin Deppe:
Danke und ja, findet aber in diesem Fall keine Anwendung, wie ich bereits die ganze Zeit zu verdeutlichen versuche!
Ich habe zwar ein per subfs eingehängtes Dateisystem, welches ich untersuche, ändere aber während des Suchlaufs nichts daran und befinde mich bei Aufruf von find in einem völlig anderen Verzeichnis, als durchsucht wird!
Und der Lauf von find bewirkt auch nicht, dass subfs etwas mountet? Das ist alles schon vorher gemountet???
Nein, es ist alles schon vorher eingehängt und selbst wenn, es hat nichts mit dem aktuellen Verzeichnis zu tun (mein Home-Verzeichnis). --------------------------------------------------------------------- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
participants (4)
-
David Haller
-
Jan Ritzerfeld
-
Martin Deppe
-
Michael Behrens