เหตุใดไฟล์นี้จึงถูกซ่อนเมื่อคุณเรียกใช้ ls

แก้ไข: ฉันลืมเรื่องนี้ทั้งหมด ปรากฎว่าฉันมีฮาร์ดดิสก์ที่ไม่ดี เราต้องปรับใช้เซิร์ฟเวอร์นี้สำหรับความต้องการอื่น ๆ ดังนั้นในที่สุดฉันก็กลับมาแทนที่ดิสก์ที่ไม่ดีหนึ่งอันและเรากลับมาทำธุรกิจอีกครั้ง

สองสามสัปดาห์ตอนนี้ฉันไม่สามารถหาสาเหตุที่ฉันไม่สามารถลบไฟล์นี้โดยเฉพาะ ในฐานะที่เป็น root ฉันทำได้ แต่เชลล์สคริปต์ของฉันทำงานเป็นผู้ใช้อื่น ดังนั้นฉันไปวิ่ง ls -la และมันไม่ได้มี อย่างไรก็ตามถ้าฉันเรียกมันว่าเป็นพารามิเตอร์มันจะปรากฏขึ้น! แน่นอนว่าเจ้าของคือรูตดังนั้นฉันจึงไม่สามารถลบได้

แจ้งให้ทราบล่วงหน้า 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('.')"

แน่นอนงูหลามที่ C Library เคอร์เนลหรือระบบไฟล์อาจจะยังได้รับการแก้ไข แต่มักจะเป็นเพียงเปลือก utils

คุณสามารถดูว่า 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 ...

นี่ไม่ใช่การทดสอบข้อสรุป แต่เป็นตัวบ่งชี้ที่ดี ...

(ถ้าคุณใช้โซลาริสหรือระบบปฏิบัติการอื่น ๆ คุณอาจต้องใช้โครงมัดหรือยูทิลิตี้อื่น ๆ ที่คล้ายกันแทน strace)

(หากคุณใช้เชลล์ที่ได้มาจาก csh / tcsh คุณอาจต้องมีคำสั่งการเปลี่ยนเส้นทางที่แตกต่างกัน)

การอัปเดตด่วนเราต้องเปลี่ยนเซิร์ฟเวอร์ด้วยเหตุผลอื่น มันเป็นระบบไฟล์ ทั้งหมดเป็นอย่างดีในขณะนี้ !!! ขอบคุณทุกคน.

ทฤษฎีแฮ็คน่าสนใจ แต่ฉันมีทฤษฎีทางเลือก ซีแมนทิกส์การลบไฟล์ Unix จะเก็บไฟล์ไว้รอบ ๆ จนกว่ากระบวนการทั้งหมดจะปิดการจัดการไฟล์เปิดที่ชี้ไปที่มัน อาจมีบางคนหยุดการชำระเงิน / การกระทำของ SVN หรือกลุ่มเธรดเซิร์ฟเวอร์หยุดทำงานชั่วคราว หากการรีสตาร์ทกระบวนการ SVN (หรือ Apache) แก้ปัญหาของคุณนี่คือที่ที่ฉันจะกล่าวโทษ

บางทีคุณสามารถระบุกระบวนการที่ยังคงใช้ไฟล์นี้ด้วยlsof | grep 6535?