lsを実行すると、なぜこのファイルが非表示になるのですか？

編集：私はこのスレッドを完全に忘れていました。ハードディスクに問題があったことがわかりました。他のニーズのためにこのサーバーを再展開する必要があったので、ようやく1つの不良ディスクの交換に取り掛かり、ビジネスに復帰しました。

数週間前から、この1つの特定のファイルを削除できなかった理由がわかりませんでした。rootとしてはできますが、シェルスクリプトは別のユーザーとして実行されます。だから私はls -laを実行しますが、そこにはありません。ただし、パラメーターとして呼び出すと表示されます。案の定、所有者はrootであるため、削除できません。

6535が欠落していることに注意してください...

[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

直接呼び出すと表示されます。

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

ここに面白いものがあります。6535はrootが所有しているため、シェルスクリプトで削除に失敗するため、この問題を見つけました。「rm -rf」を実行すると、実際にファイルが表示されます。以前に試してみましたが、ディレクトリが空ではないことが通知されたため、ディレクトリを削除できませんでした。中に入って見てみると、ファイル「6535」がようやく表示されました。なぜこれが行われているのかわかりません。

straceは次のように述べています

#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

それは少し心配です。ls既知の正常なファイルと比較して、ファイルが変更されていないことを確認します。ディストリビューションのパッケージツールを使用して、隔離されたシステムでファイルを確認できます。

時々、ファイル名はカーソル移動シーケンスのような奇妙な文字をそれらに含みます。これを確認してください：

ls -lq

制御文字の代わりに疑問符が表示されるはずです（これはおそらくデフォルトですが、そうでない可能性があります）。

これは、存在する可能性のある問題のタイプを部分的に示しています。

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

私も試してみます：

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

エイリアスまたは関数が定義されているかどうか、またはバイナリが奇妙な場所にあるか、変更されているかどうかを確認します。

そのボリュームをfsckすることもできます。

「ls」が変更されたと思う場合、私は通常このようなことをします...

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

もちろん、Python、Cライブラリ、カーネル、またはファイルシステムを変更することもできますが、通常は単なるシェルユーティリティです。

straceを使用すると、lsの動作を正確に調べることができます。これにより、そのファイル名が表示されない理由がわかります。

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

それを通してそれを見て、何が起こっているのかを見てください。

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

出力は次のようになります。

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

そしてあなたが何かのようなものを見た場合

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

注意してください、あなたは0wnedされています...

これは決定的なテストではありませんが、良い指標です...

（solarisまたは他のOSを使用している場合は、straceの代わりにtrussまたは他の同様のユーティリティを使用する必要がある場合があります）

（csh / tcsh派生シェルを使用している場合は、おそらく異なるリダイレクトステートメントが必要になります）

クイックアップデート。他の理由でサーバーを交換する必要がありました。それはファイルシステムでした。すべてが順調です!!! みんなありがとう。

ハック理論は興味深いですが、私には別の理論があります。Unixのファイル削除セマンティクスは、すべてのプロセスがそれを指す開いているファイルハンドルを閉じるまで、ファイルを保持します。おそらく、誰かがSVNチェックアウト/コミットを一時停止したか、サーバースレッドがハングアップした可能性があります。SVNプロセス（またはApache）を再起動すると問題が解決する場合は、ここで非難します。

おそらく、このファイルをまだ使用しているプロセスを特定できますlsof | grep 6535か？