Warum wird diese Datei ausgeblendet, wenn Sie ls ausführen?

EDIT: Ich habe diesen Thread total vergessen. Es stellte sich heraus, dass ich eine schlechte Festplatte hatte. Wir mussten diesen Server für andere Anforderungen neu bereitstellen, damit ich endlich die eine fehlerhafte Festplatte ersetzen konnte und wir wieder im Geschäft sind.

Seit einigen Wochen konnte ich nicht herausfinden, warum ich diese eine bestimmte Datei nicht löschen konnte. Als root kann ich, aber mein Shell-Skript läuft als anderer Benutzer. Also gehe ich ls -la laufen und es ist nicht da. Wenn ich es jedoch als Parameter aufrufe, wird es angezeigt! Sicher genug, der Besitzer ist root, daher kann ich nicht löschen.

Beachten Sie, 6535 fehlt ...

[root@server]# ls -la 653*
-rw-rw-r--  1 svn svn  24002 Mar 26 01:00 653
-rw-rw-r--  1 svn svn   7114 Mar 26 01:01 6530
-rw-rw-r--  1 svn svn   8653 Mar 26 01:01 6531
-rw-rw-r--  1 svn svn   6836 Mar 26 01:01 6532
-rw-rw-r--  1 svn svn   3308 Mar 26 01:01 6533
-rw-rw-r--  1 svn svn   3918 Mar 26 01:01 6534
-rw-rw-r--  1 svn svn   3237 Mar 26 01:01 6536
-rw-rw-r--  1 svn svn   3195 Mar 26 01:01 6537
-rw-rw-r--  1 svn svn  27725 Mar 26 01:01 6538
-rw-rw-r--  1 svn svn 263473 Mar 26 01:01 6539

Jetzt wird es angezeigt, wenn Sie es direkt aufrufen.

[root@server]# ls -la 6535
-rw-rw-r--  1 root root 3486 Mar 26 01:01 6535

Hier ist etwas Interessantes. Ich habe dieses Problem festgestellt, weil es in meinem Shell-Skript nicht gelöscht werden konnte, da 6535 im Besitz von root ist. Die Datei wird tatsächlich angezeigt, nachdem ich "rm -rf" ausgeführt habe. Ich habe es früher versucht und das Verzeichnis konnte nicht entfernt werden, da mir mitgeteilt wurde, dass das Verzeichnis nicht leer ist. Ich ging hinein und schaute und sicher genug, die Datei "6535" wird endlich angezeigt. Keine Ahnung warum es so ist.

strace sagt folgendes

#strace ls -la 653* 2>&1 | grep ^open

open("/etc/ld.so.cache", O_RDONLY)      = 3
open("/lib64/tls/librt.so.1", O_RDONLY) = 3
open("/lib64/libacl.so.1", O_RDONLY)    = 3
open("/lib64/libselinux.so.1", O_RDONLY) = 3
open("/lib64/tls/libc.so.6", O_RDONLY)  = 3
open("/lib64/tls/libpthread.so.0", O_RDONLY) = 3
open("/lib64/libattr.so.1", O_RDONLY)   = 3
open("/etc/selinux/config", O_RDONLY)   = 3
open("/proc/mounts", O_RDONLY)          = 3
open("/usr/lib/locale/locale-archive", O_RDONLY) = 3
open("/proc/filesystems", O_RDONLY)     = 3
open("/usr/share/locale/locale.alias", O_RDONLY) = 3
open("/usr/share/locale/en_US.UTF-8/LC_TIME/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en_US.utf8/LC_TIME/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en_US/LC_TIME/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en.UTF-8/LC_TIME/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en.utf8/LC_TIME/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en/LC_TIME/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/etc/nsswitch.conf", O_RDONLY)    = 3
open("/etc/ld.so.cache", O_RDONLY)      = 3
open("/lib64/libnss_files.so.2", O_RDONLY) = 3
open("/etc/passwd", O_RDONLY)           = 3
open("/etc/group", O_RDONLY)            = 3
open("/etc/mtab", O_RDONLY)             = 3
open("/proc/meminfo", O_RDONLY)         = 3
open("/etc/localtime", O_RDONLY)        = 3

Das ist ein bisschen besorgniserregend. Ich würde überprüfen, ob Ihre lsDatei nicht durch Vergleich mit einer bekanntermaßen guten Datei geändert wurde. Sie können die Paket-Tools Ihrer Distribution verwenden, um die Datei auf einem isolierten System zu überprüfen.

Manchmal enthalten Dateinamen ungerade Zeichen, z. B. Cursorbewegungssequenzen. Versuchen Sie dies, um sicherzustellen, dass:

ls -lq

Es sollte Fragezeichen anstelle von Steuerzeichen anzeigen (dies ist wahrscheinlich die Standardeinstellung, aber möglicherweise nicht).

Dies zeigt teilweise die Art des Problems, das vorhanden sein kann:

touch A C
touch B$(tput cuu1)$'\r'
ls -l
ls -lq
ls -l --show-control-chars    # for systems that have that option and default to -q

Ich würde auch versuchen:

type -a ls
alias ls
declare -f ls
md5sum /bin/ls    # compare to a known-good identical system

um zu sehen, ob ein Alias ​​oder eine Funktion definiert ist oder ob sich eine Binärdatei an einer ungeraden Stelle befindet oder geändert wurde.

Möglicherweise möchten Sie dieses Volume überprüfen.

Normalerweise mache ich so etwas, wenn ich glaube, dass 'ls' geändert wurde ...

python -c "import os; print os.listdir('.')"

Natürlich Python könnte die C - Bibliothek, der Kern oder das Dateisystem auch modifiziert werden, aber in der Regel ist es nur der Shell - utils.

Sie können mit strace genau untersuchen, was ls tut, und das kann Ihnen sagen, warum es vermieden wird, diesen Dateinamen anzuzeigen.

strace ls -la 653* 2>&1 | less

Schauen Sie sich das an und sehen Sie, was los ist.

strace ls -la 653* 2>&1 | grep ^open

Die Ausgabe sieht folgendermaßen aus:

open("/etc/ld.so.cache", O_RDONLY)      = 3
open("/lib/librt.so.1", O_RDONLY)       = 3
open("/lib/libacl.so.1", O_RDONLY)      = 3
open("/lib/libselinux.so.1", O_RDONLY)  = 3
open("/lib/libc.so.6", O_RDONLY)        = 3
open("/lib/libpthread.so.0", O_RDONLY)  = 3
open("/lib/libattr.so.1", O_RDONLY)     = 3
open("/lib/libdl.so.2", O_RDONLY)       = 3
open("/lib/libsepol.so.1", O_RDONLY)    = 3
open("/etc/selinux/config", O_RDONLY|O_LARGEFILE) = 3
open("/proc/mounts", O_RDONLY|O_LARGEFILE) = 3
open("/selinux/mls", O_RDONLY|O_LARGEFILE) = 3

und wenn du so etwas siehst

open("/var/tmp/.../H@ckl1st", O_RDONLY) = 3

Sei vorsichtig, du wurdest geboren ...

Dies ist kein abschließender Test, aber ein guter Indikator ...

(Wenn Sie Solaris oder andere Betriebssysteme verwenden, müssen Sie möglicherweise ein Fachwerk oder ein ähnliches Dienstprogramm anstelle von strace verwenden.)

(Wenn Sie eine von csh / tcsh abgeleitete Shell verwenden, benötigen Sie wahrscheinlich andere Umleitungsanweisungen.)

Schnelles Update, wir mussten den Server aus anderen Gründen ersetzen. Es war das Dateisystem. Jetzt ist alles gut !!! Vielen Dank an alle.

Die Hack-Theorie ist interessant, aber ich habe eine alternative Theorie. Die Semantik zum Löschen von Unix-Dateien behält die Datei so lange bei, bis alle Prozesse geschlossene Dateihandles geschlossen haben, die darauf zeigen. Möglicherweise hat jemand ein SVN-Checkout / Commit angehalten oder ein Server-Thread ist aufgelegt. Wenn ein Neustart des SVN-Prozesses (oder von Apache) Ihr Problem löst, würde ich hier die Schuld geben.

Vielleicht können Sie den Prozess identifizieren, mit dem diese Datei noch verwendet wird lsof | grep 6535?