Почему этот файл скрыт при запуске ls?

РЕДАКТИРОВАТЬ: Я полностью забыл об этой теме. Оказывается, у меня был плохой жесткий диск. Нам пришлось повторно развернуть этот сервер для других нужд, поэтому я наконец нашел способ заменить один неисправный диск, и мы снова в работе.

В течение нескольких недель я не мог понять, почему я не смог удалить этот конкретный файл. От имени 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, ядро ​​или файловая система также могут быть изменены, но обычно это просто утилиты оболочки.

Вы можете посмотреть, что именно делает ls, используя strace, и это может сказать вам, почему он не показывает это имя файла.

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 или другие ОС, вам может потребоваться использовать ферму или другую аналогичную утилиту вместо strace)

(если вы используете производную от csh / tcsh оболочку, вам, вероятно, потребуются другие операторы перенаправления)

Быстрое обновление, нам пришлось заменить сервер по другим причинам. Это была файловая система. Теперь все хорошо !!! Спасибо всем.

Теория взлома интересна, но у меня есть альтернативная теория. Семантика удаления файлов Unix будет держать файл до тех пор, пока все процессы не закроют открытые дескрипторы файлов, указывающие на него. Возможно, кто-то приостановил проверку / принятие SVN, или серверный поток завис. Если перезапуск SVN-процесса (или Apache) решит вашу проблему, я бы возложил вину на это.

Возможно, вы можете идентифицировать процесс, все еще используя этот файл lsof | grep 6535?