Чому цей файл прихований під час запуску ls?

EDIT: Я повністю забув про цю тему. Виявляється, у мене поганий жорсткий диск. Нам довелося перерозподілити цей сервер для інших потреб, тому я нарешті зайнявся заміною одного поганого диска, і ми знову в роботі.

Кілька тижнів я не міг зрозуміти, чому мені не вдалося видалити цей конкретний файл. Як 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

щоб побачити, чи визначено псевдонім або функцію, або побачити, чи двійковий файл знаходиться в непарному місці чи був модифікований.

Можливо, ви захочете розгорнути цей том.

Я зазвичай роблю щось подібне, якщо вважаю, що "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

будьте обережні, ви були 0wned ...

Це не переконливий тест, але це хороший показник ...

(якщо ви використовуєте solaris або інші ОС, вам може знадобитися використовувати ферму або іншу подібну утиліту замість стрижка)

(якщо ви використовуєте оболонку csh / tcsh, вам, швидше за все, знадобляться різні заяви про переадресацію)

Швидке оновлення, нам довелося замінити сервер з інших причин. Це була файлова система. Зараз все добре !!! Всім дякую.

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

Можливо, ви можете ідентифікувати процес, який все ще використовує цей файл lsof | grep 6535?