☰

为什么运行 ls 时此文件被隐藏？

tag-icon • tag-icon linux command-line-interface shell
为什么运行 ls 时此文件被隐藏？

编辑：我完全忘记了这个帖子。结果发现我的硬盘坏了。我们不得不重新部署这台服务器以满足其他需求，所以我终于有时间更换一个坏盘，我们又可以继续工作了。

几个星期以来，我一直搞不明白为什么我无法删除这个特定的文件。我可以以 root 身份删除它，但我的 shell 脚本以其他用户身份运行。所以我运行 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

这里有一些有趣的东西。我之所以发现这个问题，是因为在我的 shell 脚本中，由于 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

答案1

这有点令人担忧。我会ls通过与已知良好的文件进行比较来验证您的文件是否未被修改。您可以使用发行版的软件包工具在隔离系统上验证文件。

答案2

有时文件名中会包含奇怪的字符，例如光标移动序列。请尝试以下操作以确保：

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

查看别名或函数是否已定义，或者查看二进制文件是否位于奇怪的位置或已被修改。

答案3

您可能需要对该卷进行 fsck。

答案4

您可以使用 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

小心，你已经被打败了……

这不是一个结论性的测试，但它是一个很好的指标......

（如果您使用的是 solaris 或其他操作系统，则可能需要使用 truss 或其他类似的实用程序来代替 strace）

（如果您使用的是 csh/tcsh 派生的 shell，则可能需要不同的重定向语句）

相关内容