☰

„find: .: Keine solche Datei oder kein solches Verzeichnis“ bei Verwendung von „find“ im aktuellen Verzeichnis

tag-icon • tag-icon find
„find: .: Keine solche Datei oder kein solches Verzeichnis“ bei Verwendung von „find“ im aktuellen Verzeichnis

Der Befehl „Find“ scheint überhaupt nicht zu funktionieren. Ich befinde mich beispielsweise in einem Verzeichnis, in dem sich eine Datei mit dem Namen „index.php“ befindet, und führe Folgendes aus:

[root@server htdocs]# find . -name "index.php"
find: .: No such file or directory

Ich erhalte immer die Fehlermeldung „Keine solche Datei oder kein solches Verzeichnis vorhanden“.

Egal welchen Pfad ich definiere oder nach welcher Datei ich suche, ich erhalte immer diesen Fehler. Ich bin ziemlich sicher, dass ich etwas ganz Einfaches übersehe. Kann mir jemand sagen, was ich falsch mache?

[root@server htdocs]# pwd
/srv/www/htdocs
[root@server htdocs]# type -a find
find is /usr/bin/find
[root@server htdocs]# ls -la | grep index.php
-rw-rw-r--  1 andris users  413 Sep  1  2013 index.php
[root@server htdocs]# find . -name "index.php"
find: .: No such file or directory
[root@server htdocs]# find .
.
find: .: No such file or directory

[root@server htdocs]# stat .
  File: `.'
  Size: 4096            Blocks: 8          IO Block: 4096   directory
Device: ca00h/51712d    Inode: 155686      Links: 12
Access: (0775/drwxrwxr-x)  Uid: (  504/  andris)   Gid: (  100/   users)
Access: 2014-06-17 19:37:22.000000000 +0000
Modify: 2014-06-08 21:06:16.000000000 +0000
Change: 2014-06-08 21:06:16.000000000 +0000

[root@server htdocs]# find --version
GNU find version 4.2.27
Features enabled: D_TYPE O_NOFOLLOW(enabled) LEAF_OPTIMISATION SELINUX

strace find .Ausgabe:https://gist.github.com/andrisp/f3adaf740548eead33da

[root@server htdocs]# find . -noleaf -name "index.php"
find: .: No such file or directory

Antwort1

Laut Ihrer straceAusgabe (und ich habe keine Ahnung, warum) open()versieht die Funktion die Dateinamen mit dem folgenden Präfix /proc/:

open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 4
fcntl64(4, F_SETFD, FD_CLOEXEC) = 0
getdents64(4, /* 21 entries */, 32768) = 664
getgid32() = 0
stat64("/proc/index.php", 0xbfc53bd0) = -1 ENOENT (No such file or directory)
getgid32() = 0
stat64("/proc/.svn", 0xbfc53bd0) = -1 ENOENT (No such file or directory)
getgid32() = 0
stat64("/proc/init-dist.php", 0xbfc53bd0) = -1 ENOENT (No such file or directory)
getgid32() = 0
stat64("/proc/landing-page.html", 0xbfc53bd0) = -1 ENOENT (No such file or directory)
getgid32() = 0
[...]
stat64("/proc/js", 0xbfc53bd0) = -1 ENOENT (No such file or directory)
getgid32() = 0
stat64("/proc/extras", 0xbfc53bd0) = -1 ENOENT (No such file or directory)
getgid32() = 0
stat64("/proc/sitemaps", 0xbfc53bd0) = -1 ENOENT (No such file or directory)
getdents64(4, /* 0 entries */, 32768) = 0

Antwort2

Ich habe gesehen, dass dies auf einem Mac passiert, wenn sich das Verzeichnis auf einem Wechseldatenträger befindet, der seit dem Öffnen des Terminalfensters entfernt und wieder hinzugefügt wurde. Ich kann nicht erklären, warum (wahrscheinlich hat es mit Informationen zu tun, die beim Starten der Terminalsitzung zwischengespeichert wurden), aber es war reproduzierbar. Habe die Terminalsitzung einfach neu gestartet und alles war in Ordnung.

Antwort3

Versuchen Sie es mit dem absoluten Pfad wie:

   sudo find /where/your_file_is/located/ -iname "index.php"

Und wie bereits oben erwähnt, kann es sein, dass Sie keine Berechtigungen haben. Was passiert, wenn Sie:

ls .

Weiß Ihre Shell, was mit dem Punkt zu tun ist?

Antwort4

Möglicherweise verfügen Sie als Benutzer nicht über die Ausführungsberechtigung für das Verzeichnis, in dem Sie suchen. Verfügt Ihr Benutzer über Lese- und Ausführungsberechtigung?

verwandte Informationen