编辑：我完全忘了这个线程。 事实certificate，我有一个坏的硬盘。 我们不得不重新部署这台服务器来满足其他的需求，所以我终于开始replace这个坏的磁盘，然后我们又恢复了业务。
几个星期后，我无法弄清楚为什么我无法删除这个特定的文件。 作为root我可以，但我的shell脚本作为不同的用户运行。 所以我去运行ls -la，它不在那里。 但是，如果我将其作为参数调用，则会显示！ 果然，主人是根，因此我无法删除。
注意，6535缺less…
[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
这是一些有趣的事情。 所以我遇到这个问题，因为在我的shell脚本，它将无法删除，因为6535属于根。 运行“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
这有点令人担忧。 我会通过比较一个已知的好文件来validation你的ls文件没有被修改。 您可以使用您的发行版的打包工具来validation隔离系统上的文件。
有时文件名会得到奇怪的字符，如光标移动序列。 试试这个来确保：
ls -lq
它应该显示问号而不是控制字符（这可能是默认值，但可能不是）。
这部分certificate了可能存在的问题的types：
touch AC 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
查看是否定义了别名或函数，或查看二进制文件是否在奇怪位置或已被修改。
你可能想要甩这个音量。
如果我相信'ls'已被修改，我通常会做这样的事情…
python -c "import os; print os.listdir('.')"
当然Python，C库，内核或者文件系统也可以被修改，但是通常它只是shell utils。
你可以通过使用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
要小心，你已经被…
这不是一个确定的testing，但它是一个很好的指标。
（如果您使用的是solaris或其他操作系统，则可能需要使用truss或其他类似的工具来代替strace）
（如果你使用的是csh / tcsh派生的shell，你可能需要不同的redirect语句）
快速更新，我们不得不更换服务器的其他原因。 这是文件系统。 一切都很好！ 谢谢大家。
黑客理论很有趣，但是我有另一种理论。 Unix文件删除语义将保留该文件，直到所有进程closures打开的文件句柄指向它。 也许有人暂停了一个SVN checkout / commit，或者一个服务器线程挂起。 如果重新启动SVN进程（或Apache）解决了你的问题，这是我的责任。
也许你可以用lsof | grep 6535来识别仍在使用这个文件的进程 lsof | grep 6535 ？