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) = ?