जब आप ls चलाते हैं तो यह फ़ाइल क्यों छिपाई जाती है?

Question

संपादित करें: मैं इस धागे के बारे में पूरी तरह से भूल गया। यह पता चला है कि मेरे पास एक खराब हार्ड डिस्क थी। हमें इस सर्वर को अन्य जरूरतों के लिए फिर से तैयार करना था, इसलिए मैं अंत में एक खराब डिस्क की जगह ले पाया और हम व्यापार में वापस आ गए।

अब कुछ हफ्तों के लिए मैं यह पता नहीं लगा सका कि मैं इस एक विशेष फ़ाइल को हटाने में सक्षम क्यों नहीं था। रूट के रूप में मैं कर सकता हूं, लेकिन मेरी शेल स्क्रिप्ट एक अलग उपयोगकर्ता के रूप में चलती है। तो मैं 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 रूट के स्वामित्व में है। "Rm -rf" चलाने के बाद फ़ाइल वास्तव में दिखाई देती है। मैंने इसे पहले ही आज़मा लिया था और निर्देशिका को हटाने में विफल रहा क्योंकि उसने मुझे बताया कि निर्देशिका खाली नहीं है। मैं अंदर गया और देखा और निश्चित रूप से पर्याप्त था, "6535" फ़ाइल अंत में दिखाती है। पता नहीं यह ऐसा क्यों कर रहा है।

स्ट्रेस निम्नलिखित कहता है

#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

Comments

यदि आप इसका पता लगाते हैं तो कृपया एक अपडेट पोस्ट करें।

— आइंस्टीन

दिलचस्प। ls -ab के साथ क्या रिपोर्ट मिलती है? शायद कुछ अजीब गैर अष्टाक्षर चरित्र फ़ाइल नाम में है? मुझे लगता है कि -a इसे वैसे भी सूचीबद्ध करेगा लेकिन मुझे यकीन नहीं है।

— ५२ पर एर्गोर्री

क्या आपने हाल ही में एक fsck भागा है? यह दूरस्थ रूप से संभव है कि फाइल सिस्टम पर कुछ टूट गया है।

— ज़ॉर्दाचे

मुझे कल फिर से इसका परीक्षण करना होगा, दिन के लिए छोड़कर।

— सौभाग्यमृत्यु

Answer 1

यह थोड़ा चिंताजनक है। मैं यह सत्यापित करूँगा कि lsकिसी अच्छी फ़ाइल की तुलना करके आपकी फ़ाइल को संशोधित नहीं किया गया था। आप एक अलग सिस्टम पर फ़ाइल को सत्यापित करने के लिए अपने वितरण के पैकेज टूल्स का उपयोग कर सकते हैं।

Comments

+1: ls -al को सब कुछ दिखाना चाहिए। अगर यह नहीं है तो कहीं कोई समस्या है।

— शैतानिकपुपी

यह काफी संभव है कि lsएक विशिष्ट पीआईडी ​​को छिपाने के लिए संशोधित किया गया है, संभवतः 6535।

— मिकीबी

नहीं ... कुछ भी नहीं ...

— किस्मत मारी

Answer 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

यह देखने के लिए कि क्या एक उपनाम या फ़ंक्शन परिभाषित है या यह देखने के लिए कि क्या द्विआधारी एक विषम जगह में है या संशोधित किया गया है।

Comments

+1 अच्छी अंतर्दृष्टि। यह नोट करना महत्वपूर्ण है कि अगर lsसंशोधित किया गया था, md5sumतो सिस्टम पर संभावित रूप से भी संशोधित किया जा सकता था। एक निश्चित निष्कर्ष पर पहुंचने के लिए आपको सत्यापित करने के लिए एक ज्ञात समझदार वातावरण की आवश्यकता है।

— वार्नर

मैंने पाया है कि भले ही md5 को bogus परिणाम देने के लिए बदल दिया गया हो, अगर आप 'md5 फ़ाइल' जैसी चीजें करते हैं, तो आप bzip2 जैसा कुछ करके भी अच्छे परिणाम प्राप्त कर सकते हैं (यदि md5 प्रोग्राम बिल्कुल काम करता है) <फ़ाइल | md5 और तुलना करें कि कहीं एक ही आदेश के लिए।

— क्रिस

Answer 3

आप उस वॉल्यूम को fsck करना चाह सकते हैं।

Comments

कि उसने क्या कहा।

— आइंस्टीन

Answer 4

मैं आमतौर पर ऐसा कुछ करता हूं अगर मुझे लगता है कि 'ls' को संशोधित किया गया है ...

python -c "import os; print os.listdir('.')"

बेशक, पायथन, सी लाइब्रेरी, कर्नेल या फ़ाइल सिस्टम को भी संशोधित किया जा सकता है, लेकिन आमतौर पर यह केवल शेल बर्तनों का है।

Comments

या, आप निर्देशिका को पढ़ने के लिए शेल के फ़ाइल नाम के विस्तार का उपयोग कर सकते हैं - गूंज * (और यदि आप सब कुछ चाहते हैं, तो प्रतिध्वनि *। *)

— क्रिस

*.*केवल उन फ़ाइलों को दिखाने जा रहा है, जिनमें चरित्र (अक्षर) हैं और उसके बाद एक अक्षर (अक्षर) है। यह निश्चित रूप से * निक्स सिस्टम पर सब कुछ नहीं है। मुझे यकीन नहीं है कि प्रतिध्वनि आपको एक कमांड में सब कुछ दिखा देगी, मैं ऐसा करने में सक्षम थाecho * && echo .*

— आइंस्टीन

यदि आप बारीकी से देखते हैं, तो यह * (स्थान) है। *, न *। * विराम चिह्न इस टिप्पणी प्रणाली का मजबूत सूट नहीं है ... और, "$ IFS" द्वारा अलग किए गए कई भावों का विस्तार करने के लिए गूंज पूरी तरह से खुश है आप इसे खिलाने की देखभाल करते हैं। बूलियन और& आवश्यक नहीं है, या वास्तव में भी बहुत समझ में आता है, क्योंकि && एक बूलियन है और हमेशा काम करेगा क्योंकि इको कमांड हमेशा सफल होती है।

— क्रिस

@ क्रिस: मेरी बुरी, वास्तव में यह देखना मुश्किल है।

— आइंस्टीन

Answer 5

आप वास्तव में देख सकते हैं कि एलएस स्ट्रेस का उपयोग करके क्या कर रहा है, और यह आपको बता सकता है कि यह फ़ाइल नाम दिखाने से परहेज क्यों कर रहा है।

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 रहे हैं ...

यह एक निर्णायक परीक्षण नहीं है, लेकिन यह एक अच्छा संकेतक है ...

(यदि आप सोलारिस या अन्य ओएस का उपयोग कर रहे हैं, तो आपको स्ट्रेस के बजाय ट्रस, या कुछ अन्य समान उपयोगिता का उपयोग करने की आवश्यकता हो सकती है)

(यदि आप एक csh / tcsh व्युत्पन्न शेल का उपयोग कर रहे हैं, तो आपको अलग-अलग रीडायरेक्शन स्टेटमेंट की आवश्यकता होगी)

Comments

यह मुझे पंसद है। straceउपयोगिता वास्तव में एक स्विस सेना चाकू है। आप सिस्टम कॉल स्तर पर सही हो जाते हैं और मनमानी जटिलता के एक पूरे ढेर को बायपास करते हैं। यह किसी भी सिस्टम एडमिन की पहली चीजों में से एक है। एक नई स्थापित मशीन पर डंप करने के लिए एक पैसा भी चाहिए।

— मैकजेफ

हाँ - एक सिस्टम प्रशासक के लिए दो सबसे मूल्यवान उपकरण ट्रस / स्ट्रेस और tcpdump हैं। इनके साथ, आप हमेशा कवर के नीचे देख सकते हैं कि wtf चल रहा है जब कुछ ऐसा हो रहा है या आपकी अपेक्षा के अनुरूप व्यवहार नहीं कर रहा है।

— क्रिस

Answer 6

त्वरित अपडेट, हमें अन्य कारणों से सर्वर को बदलना पड़ा। यह फाइलसिस्टम था। अब सब ठीक है !!! आप सभी को धन्यवाद।

Comments

आपका मतलब है कि फ़ाइल सिस्टम खराब हो गया था और यह सिर्फ एक निराला लक्षण था?

— क्रिस 12

हाँ, यह था

— सौभाग्यवती

आप शायद नीचे दी गई सूची में एक समाधान कहने के लिए एक संपादन में फंस सकते हैं, क्योंकि यह अन्य उत्कीर्ण (और समस्या निवारण के लिए उपयोगी) उत्तरों के नीचे दफन किया गया है।

— बार्ट सिल्वरस्ट्रिम

Answer 7

हैक सिद्धांत दिलचस्प है, लेकिन मेरे पास एक वैकल्पिक सिद्धांत है। यूनिक्स फ़ाइल विलोपन शब्दार्थ फ़ाइल को तब तक इधर-उधर रखेगा, जब तक कि सभी प्रक्रियाएँ खुली फ़ाइल हैंडल को इंगित न कर दें। शायद किसी ने SVN चेकआउट / कमिट, या सर्वर थ्रेड को लटका दिया है। यदि SVN प्रक्रिया (या Apache) को पुनरारंभ करने से आपकी समस्या हल हो जाती है, तो यह वह जगह है जहाँ मैं दोष देता हूँ।

शायद आप इस फ़ाइल के साथ अभी भी इस प्रक्रिया की पहचान कर सकते हैं lsof | grep 6535?

Comments

हाँ lsof कुछ भी नहीं दिखा। दिलचस्प बात यह है कि, 6535 स्रोत में "लापता" भी है। मेरी स्क्रिप्ट किसी अन्य निर्देशिका में मूल रेपो की हॉटकॉपी करती है। यही कारण है कि जब मैं किसी कारण से इस विशेष फ़ाइल को हटाने में सक्षम नहीं होने के मुद्दों में भाग गया।

— भाग्यदिक्षि

एक हटाई गई लेकिन खुली हुई फ़ाइल आपको युक्त निर्देशिका को हटाने से नहीं रखेगी क्योंकि एक बार जब उस प्रविष्टि को हटा दिया जाता है, तो निर्देशिका प्रविष्टि मौजूद नहीं होगी, इसलिए निर्देशिका खाली हो जाएगी। आपको फ़ाइल से उस स्थान को वापस नहीं मिलेगा जब तक कि जो प्रक्रिया खुली है वह मार दी गई है, लेकिन उस निर्देशिका में जो फ़ाइल थी उसे अब हटाया जा सकता है।

— क्रिस

आपका वैकल्पिक सिद्धांत दिलचस्प है। हटाने, सफल होने पर, तुरंत कड़ी को हटा देगा। इनोड की संभावना अभी भी डेटा में होगी और कुछ फ़ाइल हैंडल में यह मेमोरी में कैश्ड हो सकता है, लेकिन मुझे विश्वास नहीं है कि यह परिदृश्य वर्णित व्यवहार को समझा सकता है। या, किस क्रिस ने कहा, हे।

— वार्नर