निर्देशिका को "rm -rf" से हटाने की कोशिश की जा रही है, लेकिन संदेश प्राप्त करें कि यह खाली नहीं है


36

मैंने "rm -rf" का उपयोग करके एक निर्देशिका हटाने की कोशिश की है और मुझे संदेश "निर्देशिका खाली नहीं है" मिल रहा है:

Bens-MacBook-Pro:please benjaminhocking$ ls -lart empty_directory/
total 16
drwxr-xr-x  5 benjaminhocking  staff  170 Aug 27 14:46 .
drwxr-xr-x  3 benjaminhocking  staff  102 Aug 27 15:28 ..
Bens-MacBook-Pro:please benjaminhocking$ rm -rf empty_directory/
rm: empty_directory/: Directory not empty
Bens-MacBook-Pro:please benjaminhocking$ rmdir empty_directory/
rmdir: empty_directory/: Directory not empty

अगर मैं फाइंडर (ट्रैश में फ़ोल्डर को खींचते हुए) का उपयोग करके यही कोशिश करता हूं, तो मुझे संदेश मिलता है

ऑपरेशन पूरा नहीं किया जा सकता क्योंकि आइटम "रिक्त_निर्देशिका" उपयोग में है।

मैंने करने की कोशिश की xattr -d com.apple.quarantine, विशुद्ध रूप से अंधविश्वास से बाहर, लेकिन यह अच्छा नहीं हुआ।

संभवतः संदर्भ का एक महत्वपूर्ण हिस्सा यह है कि यह निर्देशिका शुरू में एक निर्देशिका में थी जिसे मुझे "लॉक क्लीन" कमांड द्वारा हटा दिया जाना चाहिए था, जो मुझे टर्मिनल लॉक करने से पहले जारी किया गया था, जिसके बाद मेरे पास आधे से अधिक अन्य कार्यक्रम थे। स्काइपे सहित लॉकिंग भी बंद हो रही है, और अंततः ओएस ही। मैंने पावर कुंजी दबाकर और कंप्यूटर को रिबूट करने के लिए समाप्त कर दिया।

जोड़ने के लिए संपादित करें: मेरे द्वारा छोड़ी गई एक और महत्वपूर्ण जानकारी यह थी कि यह एक एन्क्रिप्टेड फ़ोल्डर में आ रहा था encfs। मैं चीजों के एन्क्रिप्टेड पक्ष में संबंधित फ़ोल्डर को ट्रैक करने और वहां इसे हटाने में सक्षम था। मुझे अभी भी नहीं पता है कि मैं इसे डिक्रिप्टेड साइड से चीजों की तरह क्यों नहीं कर सकता जैसे मैं सामान्य रूप से करता हूं। यदि किसी के पास इसका अच्छा उत्तर है तो मैं इस अनुत्तरित को अभी के लिए छोड़ दूँगा।


2
क्या आपके पास इस निर्देशिका के भीतर कोई अन्य शेल खुला है, या केवल उपयोग करने वाला ऐप चल रहा है? शब्द "उपयोग में है" का अर्थ यह भी हो सकता है कि (हालांकि मैंने कभी भी इसका अनुभव नहीं किया rmdirहै - लेकिन यह अक्सर यही कारण है कि कोई एक मात्रा को अनमाउंट नहीं कर सकता है)।
इज़ी

उस समय नहीं जब उन विशेष आदेशों को जारी किया गया था। मैंने उससे ठीक पहले एक पूर्ण रीबूट किया था।
बेन होकिंग 13

मुझे कभी-कभी EncFS के साथ भी यही समस्या है और अब तक मुझे नहीं पता कि इसे कैसे हल किया जाए। कुछ नया?
मार्टिन प्रीससे

@emempe: आखिरकार मैं क्या कर रहा था एन्क्रिप्टेड स्पेस में फ़ोल्डर को हटा रहा था, अंतिम पहचानकर्ता के रूप में अंतिम संशोधित टाइमस्टैम्प का उपयोग कर रहा था। (जो खतरनाक हो सकता है।) अगर मैं बेहतर समाधान के साथ आता हूं, तो मैं आपको बता दूंगा।
बेन हॉकिंग

@BenHocking: मैं भी यही करता हूं। मेरे लिए शायद ही कभी होता है इसलिए मैं इसके साथ ठीक हूं। फिर भी, मुझे यह महसूस नहीं हो रहा है कि मेरा EncFS किसी तरह भ्रष्ट हो गया ...?) मेरा EncFS एक ड्रॉपबॉक्स में है, शायद कुछ कनेक्शन?
मार्टिन प्रीससे

जवाबों:


12

अपने कंप्यूटर को रिबूट करें और rmdir(1)फिर से चलाएं ।

$ rmdir -r empty_directory/

यदि वह काम नहीं करता है, तो कोशिश करें:

$ rm -rf empty_directory/

यदि यह अभी भी काम नहीं करता है, तो मान लें कि OS X lsof(8)पूर्वस्थापित है, तो दर्ज करें:

$ lsof +D empty_directory/

यह बताना चाहिए कि क्या इस निर्देशिका की कोई भी फाइल किसी प्रोग्राम द्वारा उपयोग की जा रही है। मुझे लगता है कि HFS + फाइलसिस्टम उपयोग में आने वाली फाइलों को हटाने की अनुमति नहीं देता है। वैसे भी, killall(1)कोई भी निष्पादनयोग्य जो इस निर्देशिका या उसके अंदर किसी छिपी हुई फाइल का उपयोग कर सकता है। यह संभावना है कि खोजक empty_directoryफ़ोल्डर दृश्य सेटिंग्स को संग्रहीत करने के लिए निर्देशिका में छिपी हुई फ़ाइल का उपयोग कर रहा है । उम्मीद है की यह मदद करेगा।

पुनश्च: पता लगाने के लिए कि lsof(8)क्या स्थापित है, दर्ज करें:

$ lsof

यदि आउटपुट इस तरह दिखता है, तो lsof(8)आपके सिस्टम पर स्थापित है।

lsof: /usr/bin/lsof /usr/bin/X11/lsof /usr/share/man/man8/lsof.8.gz

उस निर्देशिका में किसी भी छिपी और एन्क्रिप्टेड फ़ाइलों या एन्क्रिप्शन कुंजी फ़ाइलों की जाँच करें। ये अपराधी हो सकते हैं।


4

डिस्क उपयोगिता का उपयोग करके डिस्क की मरम्मत करना मेरे लिए इस समस्या को ठीक करता है।


मेरा मानना ​​है कि ज्यादातर परिदृश्यों में यह काम करेगा। पूरी तरह से मेरे लिए काम किया। Thanx
GeekRide

फ़ाइल मेनू के अंतर्गत विशिष्ट कमांड "रन फर्स्ट एड ..." है। मुझे लगता है कि इससे पहले कि मैं "मरम्मत" शब्द के लिए मेनू में खोज करने में थोड़ा बहुत समय बिताया!
RoG

3

यदि ऐसा होता है और आप सुनिश्चित हैं कि आप सब कुछ हटाना चाहते हैं, तो आपको उपयोग करने का प्रयास करना चाहिए sudo rm -rf directory/


1
यह किसी कारण से ~ / .Tash पर काम नहीं करता है।
मार्कुस

2
यह वास्तव में तब तक काम नहीं करता है जब तक कि समस्या अनुमतियाँ नहीं हैं, जो कंसोल के लिए एक अलग त्रुटि संदेश होगा।
tresf

2

मैं एक निर्देशिका (rm -r dirname) को हटाने की कोशिश करते हुए इस त्रुटि में भाग गया। इससे पहले कि मैंने इस सूत्र को खोजा और पाया, मैंने उन सभी सुझावों की कोशिश की, जो मैंने यहाँ पढ़े हैं। मुझे नहीं पता कि मूल प्रश्न से अनजाने में कोई अतिरिक्त बिंदु छूट गए होंगे, लेकिन मेरे मामले में समस्या की जड़, और समाधान था:

  • प्रश्न में निर्देशिका नेटवर्क-माउंटेड डिस्क पर थी

  • lsखोजक या कमांड लाइन के किसी भी प्रयास ने .और कुछ नहीं दिखाया..

  • मैंने sshकमांड के माध्यम से नेटवर्क डिस्क सर्वर में लॉग इन किया और ls -alवहां जांच की । परिणाम दिखाया गया है, के अलावा .और .., .__filenameविस्तारित सुरक्षा जानकारी के साथ कई आइटम (यानी, +मोड में संलग्न)।

मेरा मानना है कि इन कर रहे हैं, या के समान हैं, फ़ाइलें जो मैं पहले मैक OSX साल पहले बनाने का उपयोग करते समय ध्यान दिया cp -R, tarया cpioफ़ाइलों का संग्रह या चाल समूहों के लिए। मैंने उस समय में कटौती की थी कि वे चाल के बाद कुछ फ़ाइल गुणों को ठीक से रीसेट करने के लिए उपयोग किए गए थे - शायद uid / gid, mode, acls, mtime / utime / ctime, आदि; मुझे वास्तव में यकीन नहीं है - जो गुण उस समय से पहले उन कमांड द्वारा सही ढंग से रीसेट नहीं हो रहे थे (मुझे याद है कि ओएसएक्स में शामिल थे mvmacऔर cpmacसमस्या के चारों ओर काम करने के लिए कमांड का इस्तेमाल किया था इससे पहले कि इन .__filenameप्रकार की फाइलें दिखाई देती हैं जब सामान्य रूपों का उपयोग करना शुरू होता है cp, tar, आदि)।

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

rm -rf dirname नेटवर्क डिस्क सर्वर पर एक लॉगिन से अपनी सामग्री के साथ निर्देशिका को ठीक से हटा दिया।

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


2

बिना किसी परिणाम के यहाँ सभी उत्तरों की कोशिश की। हालाँकि, मैं mv कमांड का उपयोग करके डायरेक्टरी को अलग करने में सक्षम था, जिसने मुझे जारी रखने की अनुमति दी।


2

मेरे लिए काम करने वाला एकमात्र समाधान /unix/234876/unable-to-delete-a-file-whatever-i-do था :

उन्हें / tmp में ले जाएँ और पुनः आरंभ करें।

मैंने कोशिश की अन्य विकल्प थे:

  • डिस्क उपयोगिता - प्राथमिक चिकित्सा।
  • lsof +D bad_file कोई आउटपुट नहीं दिखाया गया।
  • सूद rm -rf
  • एकल-उपयोगकर्ता टर्मिनल में बूटिंग और rm -rf

1
एकल-उपयोगकर्ता टर्मिनल से Fsck ने कोई मदद नहीं की, न ही rm -rf, और न ही lsof +Dकुछ भी दिखाया। अजीब तरह से, मैं आपत्तिजनक dirs को स्थानांतरित करने में सक्षम था /tmp, हालांकि इसे पुनरारंभ करने के बाद हटाया नहीं गया था। एक ही समस्या बनी हुई है, लेकिन कम से कम यह कुछ हद तक बाहर है।
अप्सिक्स

1

पाठकों के लाभ के लिए:

rm -rfऐसे में खबरदार ! यह एक नेटवर्क साझा होने के मामले में कहीं और समस्याएं पैदा कर सकता है! आपको चेतावनी दी गई है!

लगभग सभी मामलों में, यदि कोई directoryखाली लगता है , तो उपयोग करें rmdir directoryया शायद sudo rmdir directoryrm(या delविंडोज के तहत) का उपयोग न करें । यदि यह काम नहीं करता है, तो आपको यह पता लगाने की आवश्यकता है कि इस अनुरोध को क्या अवरुद्ध करता है, इसे ठीक करें और फिर पुनः प्रयास करें rmdir

कृपया ध्यान दें कि मुझे OS-X का पता नहीं है, लेकिन मुझे लगता है कि चीजें यूनिक्स / बीएसडी व्यवहार के समान हैं।

यह बहुत संभावना है कि विचाराधीन निर्देशिका सिर्फ एक माउंट बिंदु (एनकोफ़्स से) या माउंट बिंदु पर रहने वाली है जो आसानी से बन गई है या कुछ अनुचित स्थिति में अटक गई है (जो निर्देशिका को हटाने से रोकती है)। यदि आप अब निर्देशिका को हटाने के लिए बाध्य करते हैं, तो बहुत बुरी चीजें हो सकती हैं।

अच्छे मामले में निर्देशिका वास्तव में खाली थी, इसलिए इसे हटाने (माउंट आदि को नष्ट करना) ने कोई और नुकसान नहीं पहुंचाया। खराब स्थिति में, यह खाली नहीं था, बस प्रतीत होता है, जिसका अर्थ है, आपने कुछ ऐसा ट्रैश किया है जिसे आप शायद मारना नहीं चाहते थे। यह सब माउंट प्रकार पर निर्भर करता है, जो ड्राइवर उपयोग में हैं आदि पीपी।

अगर चीजें बहुत अच्छी तरह से लागू की जाती हैं, तो आमतौर पर कुछ भी बुरा नहीं होना चाहिए। हालाँकि यह सामान्य मामला नहीं है। चीजें पहले से ही एक अजीब स्थिति में हैं, जिसका अर्थ है: कुछ गलत है, इसलिए बेहतर है कि इसे आगे भी मिश्रण करने की कोशिश न करें! अगर कुछ फटा है, तो कोई भी गलत स्पर्श उसे तोड़ सकता है।

उदाहरण के लिए, यदि आप किसी नेटवर्क शेयर पर दौड़ की स्थिति मारते हैं, तो यह हो सकता है कि आपका rm -rfडेटा हटा दिया जाए जो किसी अन्य व्यक्ति द्वारा शेयर में कॉपी किया गया हो।

हालांकि rmdir, कभी भी खाली निर्देशिका को हटाने के अलावा नुकसान न करने की गारंटी दी जाती है। एनएफएस पर यह और भी सही है, क्योंकि एनएफएस केवल mkdirऔर वास्तव में परमाणु व्यवहार की गारंटी देता है rmdir, लेकिन कहीं और नहीं।

जानकारी के लिए:

आप टूल का उपयोग करके एक माउंटपॉइंट का पता लगा सकते हैं mountpoint directory। वैकल्पिक रूप से के उत्पादन में देखो mountऔर वहाँ अपने आरोह स्पॉट की कोशिश करो। लेकिन सावधान रहें, कम से कम लिनक्स के तहत यह झूठ हो सकता है। mountpointउपयोगिता का अधिक विश्वसनीय लेकिन कम सुविधाजनक उपयोग करना ।

उस स्थिति में आपने माउंटपॉइंट पाया, आप इसे अनमाउंट कर सकते हैं और फिर डायरेक्टरी को हटा सकते हैं, यह निम्नलिखित अनुक्रम है:

umount directory rmdir directory

यदि आवश्यक उपयोग sudo, हमेशा की तरह।

टिप्पणियाँ:

  • rmdirएक्सेस अधिकारों के कारण नेटवर्क शेयर अस्वीकार कर सकते हैं (और कुछ भी)।

  • rmdirविफल रणनीति के आधार पर दोषपूर्ण फाइल सिस्टम अस्वीकार कर सकते हैं। शायद आपको उस मामले में एक उचित संदेश दिखाई देगा, शायद नहीं।

  • लिनक्स (और शायद किसी भी आधुनिक ओएस) के तहत आप अलग-अलग साधनों का उपयोग करके भी प्रतिबंधित कर सकते हैं (जैसे किसी चीज़ को आसानी से बढ़ाना, सेलाइनक्स जैसी क्षमताएं, आदि)। इसका मतलब है कि आप यह नहीं देखते हैं कि यह एक माउंटपॉइंट है, और आपको कुछ भी गलत नहीं दिखता है, लेकिन यह सिर्फ काम नहीं करता है। उस मामले में आपको किसी अन्य कारण की तलाश करने की आवश्यकता है और यह ओएस में बहुत गहराई से दफन हो सकता है। यह उपकरण पर निर्भर करता है यदि आप कुछ उचित त्रुटि संदेश देखते हैं। शायद dmesgलिनक्स के तहत जैसे syslog / k गिरी-लॉग में एक नज़र है (क्षमा करें, मुझे OS-X समतुल्य नहीं पता है)।

  • ध्यान दें कि अनिवार्य फ़ाइल लॉकिंग एक स्रोत भी हो सकता है। हालांकि यह विंडोज पर सामान्य है, आमतौर पर यह सामान्य मामला नहीं है यूनिक्स और मैंने इसे निर्देशिका के लिए कभी नहीं सुना। अनिवार्य फ़ाइल लॉक POSIX द्वारा कवर किए गए हैं, लेकिन वे वैकल्पिक हैं।

  • अक्सर ऐसे मामलों में, प्रश्न में निर्देशिका एक अलग फाइल सिस्टम पर रहती है, जिसके बारे में आपने सोचा था। आप यह पता लगा सकते हैं कि कौन सी कमांड के साथ df directory(मुझे लगता है कि यह ओएस-एक्स के तहत समान है)।

  • आप statया जैसे statfsनिर्देशिका पर उपकरणों के साथ गहराई से निरीक्षण कर सकते हैं । हालांकि ये सामान्य लोगों के लिए थोड़ा कम स्तर हैं, और अक्सर ऐसे उपकरण सामान्य उपयोगकर्ताओं से अच्छी तरह से छिपे होते हैं।

  • निर्देशिकाएँ में अजीब नामों वाली फाइलें हो सकती हैं। एक फाइल की तरह जो तुरंत टर्मिनल आउटपुट को मिटा देती है, इसलिए ऐसा लगता है कि यह वहां नहीं है। कुछ ऐसी कोशिश करें ls -al | lessया मिडनाइटकॉमर जैसी किसी चीज़ का इस्तेमाल करें mc

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


1

यह एक ऐसा मामला भी हो सकता है, जिसे मैंने अभी हल किया है जिसमें एक टूटा हुआ सिमलिंक सर्वर-साइड पर था और CIFS पर क्लाइंट को दिखाई नहीं दे रहा था। सिम्लिंक ने एक गैर-खाली निर्देशिका को पॉप्युलेट किया, लेकिन क्लाइंट डायरेक्ट्री को अनलिंक करने से पहले डायरेक्टरी को साफ़ करने के उद्देश्य से सिम्लिंक को देखने या स्टैट करने में असमर्थ था। चूंकि यह अदृश्य था, इसलिए उसने इस विरोधाभास को पैदा किया जहां क्लाइंट की तरफ से यह खाली था लेकिन आरएम द्वारा चुनौती देने पर "खाली नहीं" था । यदि आपके पास सर्वर तक एसएसएच पहुंच है, तो उस छोर पर एक शेल की कोशिश करें और देखें कि क्या निर्देशिका वास्तव में खाली है या यदि यह टूटी हुई सिम्बिंक हो सकती है। मैं एक Drobo5N पर ऐसा करने में सक्षम था और इसने मेरे बट को बचा लिया।


यह एक समान स्थिति में दूसरों के लिए सहायक हो सकता है, लेकिन निश्चित रूप से मेरे लिए ऐसा नहीं था क्योंकि मैं उस समय किसी सर्वर से जुड़ा नहीं था।
बेन हॉकिंग

0

उस निर्देशिका को विंडोज से खोलने का प्रयास करें, मैक ओएस में कुछ दिखाया नहीं जा सकता है। मैक और विन पीसी के बीच कई कॉपी ऑपरेशंस के बाद भी मेरे पास ऐसा ही मुद्दा था: निर्देशिका टर्मिनल में भी खाली थी लेकिन विंडोज पर मुझे एक छिपी हुई विंडोज़ फाइल मिली, इसलिए मैंने सफलतापूर्वक निर्देशिका को वहां से हटा दिया।


0

टर्मिनल में:

  1. दर्ज करें sudo su (कमांड लाइन प्रॉम्प्ट को कुछ इस तरह बदलना चाहिए sh-3.2#)
  2. जिसे आप हटाना चाहते हैं, उसके मूल फ़ोल्डर में नेविगेट करें
  3. दर्ज rm -rf TheDirectoryYouWantToDelete

0

एक एप्लिकेशन का उपयोग करने वाले फ़ोल्डर को हटाने का प्रयास करते समय मुझे इस समस्या का सामना करना पड़ा। जब मैंने एप्लिकेशन को बंद कर दिया, तो मुझे इस त्रुटि को फेंकने के बिना फ़ोल्डर को हटाने दें, इसलिए उन एप्लिकेशन को छोड़ने का प्रयास करें जो इसका उपयोग कर रहे हैं।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.