इस अपरिहार्य निर्देशिका को कैसे हटाया जाए?


40

मैंने एक भ्रष्ट टार फ़ाइल को अनट्रेड किया, और कुछ निर्देशिका के साथ समाप्त करने में कामयाब रहा जिसे मैं हटा नहीं सकता, यदि मैं इसे हटाने की कोशिश करता हूं, तो ऐसा लगता है कि इसे नहीं पाया जा सकता है, लेकिन lsयह दिखाता है कि यह मौजूद है, दोनों बैश के साथ और अजगर के साथ इसी तरह के व्यवहार के अलावा, ठीक इसके बाद जब मैं इसे हटाने की कोशिश करता हूं rm -rf, lsशिकायत करता है कि यह नहीं मिल सकता है, तो यह इसे सूचीबद्ध करता है (नीचे देखें rm -rf)। findआदेश से पता चलता है फ़ाइल मौजूद है, लेकिन अभी भी मैं इसे नष्ट करने के लिए एक तरह से नहीं सोच सकते हैं।
यहाँ मेरे प्रयास हैं:

यहाँ आप दोनों देखते हैं lsऔर findसहमत हैं कि हमारे पास एक निर्देशिका है,

rl]$ ls
mikeaâ??cnt
rl]$ find -maxdepth 1 -type d -empty -print0  
./mikeaâcnt 

लेकिन मैं इसे हटा नहीं सकता:

rl]$ find -maxdepth 1 -type d -empty -print0 |  xargs -0 rm -f -v 
rm: cannot remove `./mikeaâ\302\201\302\204cnt': Is a directory
rl]$ ls
mikeaâ??cnt

cdहालांकि मैं इसे कर सकता हूं और यह खाली है:

rl]$ cd mikeaâ^Á^Äcnt/
mikeaâ^Á^Äcnt]$ ls
mikeaâ^Á^Äcnt]$ pwd
.../rl/mikeaâcnt


mikeaâ^Á^Äcnt]$ cd ../
rl]$ ls
mikeaâ??cnt

नीचे देखें कि यह एक साधारण फ़ाइल नहीं है, लेकिन एक निर्देशिका है, प्लस lsमजाकिया व्यवहार करता है क्योंकि rm -rf यह कहता है कि यह फ़ाइल नहीं ढूँढ सकता है तो इसे सीधे बाद में सूचीबद्ध करता है:

rl]$ rm mikeaâ^Á^Äcnt/
rm: cannot remove `mikeaâ\302\201\302\204cnt/': Is a directory
rl]$ rm -rf  mikeaâ^Á^Äcnt/
rl]$ ls
ls: cannot access mikeaâcnt: No such file or directory
mikeaâ??cnt
rl]$ 

तो यह अजगर के साथ प्रयास है, फ़ाइल मिल गई है, लेकिन नाम एक नाम के रूप में उपयोग करने योग्य नहीं है जिसे हटाया जा सकता है:

rl]$ python 
Python 2.6.6 (r266:84292, Jul 10 2013, 22:48:45) 
[GCC 4.4.7 20120313 (Red Hat 4.4.7-3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> import shutil
>>> os.listdir('.')
['mikea\xc3\xa2\xc2\x81\xc2\x84cnt']
>>> shutil.rmtree(os.listdir('.')[0] )
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python2.6/shutil.py", line 204, in rmtree
    onerror(os.listdir, path, sys.exc_info())
  File "/usr/lib64/python2.6/shutil.py", line 202, in rmtree
    names = os.listdir(path)
OSError: [Errno 2] No such file or directory: 'mikea\xc3\xa2\xc2\x81\xc2\x84cnt'

यहां तक ​​कि जब मैं टैब को पूरा करने वाले नाम का उपयोग करता हूं, तो वह उपयोग करने योग्य नहीं है:

rl]$ rm -rf mikeaâ^Á^Äcnt 
rl]$ ls
ls: cannot access mikeaâcnt: No such file or directory
mikeaâ??cnt

अजगर के नाम से पता चलता है कि मुझे यह मिलता है।

rl]$ rm -rf "mikea\xc3\xa2\xc2\x81\xc2\x84cnt"
rl]$ ls
ls: cannot access mikeaâcnt: No such file or directory
mikeaâ??cnt

क्या इस भ्रष्ट डायर से छुटकारा पाने के लिए मैं कुछ कर सकता हूं? अंतर्निहित फ़ाइल सिस्टम (NFS) कार्यशील लगता है और कोई अन्य समस्या रिपोर्ट नहीं की जाती है, और मुझे भ्रष्ट टार फ़ाइल तक ऐसी कोई समस्या नहीं है।

संपादित करें: यहाँ कॉल करने के लिए findस्वयं के -execविकल्प का उपयोग किया जा रहा हैrm

rl]$ find -maxdepth 1 -type d -empty -exec rm -f {} \;
find: `./mikeaâ\302\201\302\204cnt': No such file or directory
rl]$ ls
ls: cannot access mikeaâcnt: No such file or directory
mikeaâ??cnt
rl]$

लेकिन फ़ाइल अभी भी वहाँ है, ( lsशिकायत है कि यह नहीं मिल सकता है, लेकिन फिर इसे वैसे भी दिखाता है)

दूसरा संस्करण:

rl]$ find -maxdepth 1 -type d -empty -exec rm -rf {} \;
find: `./mikeaâ\302\201\302\204cnt': No such file or directory
rl]$ ls
ls: cannot access mikeaâcnt: No such file or directory
mikeaâ??cnt

व्यवहार अभी भी अपरिवर्तित है, फ़ाइल अभी भी मौजूद है

तीसरा संस्करण:

rl]$ ls
mikeaâ??cnt
rl]$ find -maxdepth 1 -type d -empty -exec rm -rf {} + 
rl]$ ls
ls: cannot access mikeaâcnt: No such file or directory
mikeaâ??cnt

ऐसा लगता है mikeaâcntकि अजगर के प्रयास के उत्पादन को देखने से कहीं अधिक नाम है mikea\xc3\xa2\xc2\x81\xc2\x84cnt, और इस स्क्रीनशॉट:

एल एस उत्पादन

चौथा EDIT: यह एक वाइल्ड कार्ड के साथ प्रयास है:

rl]$ echo * 
mikeaâcnt
rl]$ echo mike* 
mikeaâcnt
rl]$ rm -rf mike*
rl]$ ls
ls: cannot access mikeaâcnt: No such file or directory
mikeaâ??cnt

और मेरा स्थान:

rl]$  locale
LANG=en_US.utf8
LC_CTYPE="en_US.utf8"
LC_NUMERIC="en_US.utf8"
LC_TIME="en_US.utf8"
LC_COLLATE="en_US.utf8"
LC_MONETARY="en_US.utf8"
LC_MESSAGES="en_US.utf8"
LC_PAPER="en_US.utf8"
LC_NAME="en_US.utf8"
LC_ADDRESS="en_US.utf8"
LC_TELEPHONE="en_US.utf8"
LC_MEASUREMENT="en_US.utf8"
LC_IDENTIFICATION="en_US.utf8"
LC_ALL=

5 वां संपादन:

rl]$ ls -i 
ls: cannot access mikeaâcnt: No such file or directory
? mikeaâ??cnt

लेकिन व्यवहार भी बदल गया है, अब lsऔर cd यह करें:

rl]$ ls
ls: cannot access mikeaâcnt: No such file or directory
mikeaâ??cnt
rl]$ cd mikeaâ^Á^Äcnt 
mikeaâcnt: No such file or directory.

यह हटाने के प्रयासों के बाद हुआ है, मैं सोच रहा हूं कि यह NFS के मुद्दे हो सकते हैं जैसा कि यहां एक उत्तर में vinc17 द्वारा सुझाया गया है।

6 संपादित करें: इस के उत्पादन में है lsofऔरls -a

rl] $ / usr / sbin / lsof mikeaâ ^ Ä ^ lcnt lsof: mikeaâ \ xc2 \ x81 \ xc2 \ x84cnt पर स्थिति त्रुटि: ऐसी कोई फ़ाइल या निर्देशिका नहीं

ऊपर गलत है, यहाँ सही lsofमंगलाचरण है: (आरएल माता पिता की निर्देशिका है)

rl]$ /usr/sbin/lsof | grep mike | grep rl 
tcsh      11926   mike  cwd       DIR   0,33     4096 19569249 /home/mike/mish/rl
lsof      14733   mike  cwd       DIR   0,33     4096 19569249 /home/mike/mish/rl
grep      14734   mike  cwd       DIR   0,33     4096 19569249 /home/mike/mish/rl
grep      14735   mike  cwd       DIR   0,33     4096 19569249 /home/mike/mish/rl
lsof      14736   mike  cwd       DIR   0,33     4096 19569249 /home/mike/mish/rl
rl]$ 

rl]$ ls -a
ls: cannot access mikeaâcnt: No such file or directory
.  ..  mikeaâ??cnt

7 वीं संपादित करें: यह काम नहीं करेगा, (मैंने यह सब करने से पहले कोशिश की थी, लेकिन मैंने आउटपुट को नहीं बचाया), लेकिन इसमें फ़ाइल के समान lsऔर समस्या है rm

8 वां संस्करण: यह सुझाव के रूप में हेक्स वर्णों का उपयोग कर रहा है:

 rl]$ ls --show-control-chars | xxd
0000000: 6d69 6b65 61c3 a2c2 81c2 8463 6e74 0a    mikea......cnt.
rl]$ rmdir $'mikea\6d69\6b65\61c3\a2c2\81c2\8463\6e74\0acnt' 
rmdir: failed to remove `mikea\006d69\006b651c3\a2c2\\81c2\\8463\006e74': No such file or directory
rl]$ ls
ls: cannot access mikeaâcnt: No such file or directory
mikeaâ??cnt
rl]$

9 वां संपादन: statकमांड के लिए:

 rl]$ stat  mikeaâ^Á^Äcnt 
stat: cannot stat `mikeaâ\302\201\302\204cnt': No such file or directory
 rl]$

यह सभी आउटपुट से और भी अधिक लगता है, टिप्पणियों में सुझाए गए अनुसार बग या अन्य NFS दुर्व्यवहार है।

संपादित करें 10: यह बहुत बड़े, इसके आउटपुट या इन दो कमांडों के बाद से एक जिस्ट में स्ट्रेस आउटपुट है:

strace -xx rmdir ./* | grep -e '-1 E'`
strace -xx -e trace=file ls -li`

https://gist.github.com/mikeatm/e07fa600747a4285e460

संपादित करें 11: इसलिए उपरोक्त के पहले rmdirमैंने देखा कि मैं cdनिर्देशिका में आ सकता हूं , लेकिन बाद में rmdirमैं cdफिर से नहीं हो सकता , कल की तरह। .और .. फ़ाइलों उपस्थित थे:

rl]$ ls
mikeaâ??cnt
rl]$ cd mikeaâ^Á^Äcnt/
mikeaâ^Á^Äcnt]$ ls
mikeaâ^Á^Äcnt]$ ls  -a
.  ..
mikeaâ^Á^Äcnt]$ cd ../

अंतिम संपादन: मैंने इस पर एक स्थानीय व्यवस्थापक को देखा और इसे सर्वर पर लॉग इन करके और वहां से हटाकर निपटा दिया गया। उनसे स्पष्टीकरण यह है कि यह नाम में अनुचित चरित्र सेट के साथ एक समस्या हो सकती है।


वहाँ एक कारण है कि आप findइसे execविकल्प का उपयोग करने के बजाय एक अलग कमांड में आउटपुट कर रहे हैं ?
हेलोजोस्ट जूल

@HalosGhost का कोई कारण नहीं था, अपने सवाल पर अतिरिक्त जानकारी के लिए संपादन देखें
mike-m

2
यूनिक्स और लिनक्स के साथ बहुत कम अनुभव वाले किसी व्यक्ति के रूप में, यहां मेरा विचार है: उन प्रतीकों का उपयोग किए बिना किसी चीज के लिए निर्देशिका का नाम बदलने का प्रयास करें mv। शायद आप उसके बाद इसे हटा सकते हैं। वैकल्पिक रूप से, आप निर्देशिका को एक गहरे फ़ोल्डर स्तर (शायद वाइल्डकार्ड के साथ) ले जाने का प्रयास कर सकते हैं और फिर उस फ़ोल्डर को हटा सकते हैं जिसे आपने इसे स्थानांतरित किया है।
नजल्ल

4
मुझे संदेह है कि निर्देशिका केवल क्लाइंट पर मेमोरी में मौजूद है और सर्वर पर लंबे समय तक चली गई है। क्या आपने इसे umounting और फिर से माउंट करने की कोशिश की है? क्या आपने क्लाइंट को रिबूट करने की कोशिश की है? क्या यह अन्य ग्राहकों पर दिखाई देता है?
कास्परड

6
@ mike-m ऐसा लगता है कि आपने NFS बग मारा है, शायद NFS सर्वर में। सर्वर पर या तो या फ़ाइल सिस्टम भ्रष्टाचार। मुझे संदेह है कि आप इससे निपटने के लिए एनएफएस सर्वर एडमिन (एस) के इंतजार के अलावा वास्तव में कुछ और कर सकते हैं।
जुलाब

जवाबों:


11

इस निबंध के निम्नलिखित अंश संभावित रूप से बताते हैं कि क्यों वह निर्देशिका हटाए जाने से इनकार करती है:

NFSv4 को तार पर UTF-8 का उपयोग करके सभी फ़ाइलनामों का आदान-प्रदान करने की आवश्यकता होती है। NFSv4 विनिर्देश, RFC 3530, का कहना है कि फ़ाइल नाम UTF-8 को खंड 1.4.3 में एन्कोडेड होना चाहिए: "एक मामूली प्रस्थान में, अंतर्राष्ट्रीयकरण की मूल बातें से निपटने के लिए फ़ाइल और निर्देशिका नाम UTF-8 के साथ एन्कोडेड हैं।" एक ही पाठ। नए NFS 4.1 RFC (RFC 5661) खंड 1.7.3 में भी पाया जाता है। वर्तमान लिनक्स एनएफएस क्लाइंट केवल यूटीएफ -8 के वर्तमान स्थान से किसी भी रूपांतरण के बिना, सीधे फाइलनाम से गुजरता है। गैर-UTF-8 फ़ाइलनाम का उपयोग करना दूरस्थ NFSv4 सिस्टम का उपयोग करके सिस्टम पर एक वास्तविक समस्या हो सकती है; एनएफएस विनिर्देश का पालन करने वाला कोई भी एनएफएस सर्वर गैर-यूटीएफ -8 फाइलनाम को अस्वीकार करने वाला है। इसलिए यदि आप यह सुनिश्चित करना चाहते हैं कि आपकी फाइलें वास्तव में लिनक्स क्लाइंट से एनएफएस सर्वर में संग्रहीत की जा सकती हैं, तो आपको वर्तमान में यूटीएफ -8 फाइलनाम का उपयोग करना होगा। दूसरे शब्दों में,

UTF-8 एक दीर्घकालिक दृष्टिकोण है। सिस्टम को UTF-8 और साथ ही कई पुराने एन्कोडिंग का समर्थन करना है, जिससे लोगों को UTF-8 पर स्विच करने का समय मिल रहा है। "हर जगह" यूटीएफ -8 का उपयोग करने के लिए, सभी उपकरणों को यूटीएफ -8 का समर्थन करने के लिए अद्यतन करने की आवश्यकता है। वर्षों पहले, यह एक बड़ी समस्या थी, लेकिन 2011 तक यह अनिवार्य रूप से एक हल की गई समस्या है, और मुझे लगता है कि प्रक्षेपवक्र उन कुछ अनुगामी प्रणालियों के लिए बहुत स्पष्ट है।

सभी बाइट अनुक्रम कानूनी UTF-8 नहीं हैं, और आप यह नहीं जानना चाहते हैं कि उन्हें कैसे प्रदर्शित किया जाए। यदि कर्नेल इन प्रतिबंधों को लागू करता है, तो सुनिश्चित करता है कि केवल UTF-8 फ़ाइल नाम की अनुमति है, तो कोई समस्या नहीं है ... सभी फ़ाइल नाम कानूनी UTF-8 होंगे। मार्कस कुह्न का utf8_check सी फ़ंक्शन तेजी से निर्धारित कर सकता है कि क्या कोई अनुक्रम UTF-8 मान्य है।

फाइलसिस्टम की आवश्यकता होनी चाहिए कि फ़ाइलनाम कुछ मानक को पूरा करते हैं, न कि कुछ दुष्ट लोगों को नियंत्रित करने की आवश्यकता के कारण, लेकिन इतना ही कि नाम हमेशा बाद में सही ढंग से प्रदर्शित किए जा सकते हैं। मानकों की कमी उपयोगकर्ताओं के लिए चीजों को कठिन बनाती है, आसान नहीं। फिर भी फ़ाइल सिस्टम फ़ाइल नाम को UTF-8 होने के लिए बाध्य नहीं करता है, इसलिए इसमें आसानी से कचरा हो सकता है।


ऐसा लगता है कि स्थानीय प्रवेशों से स्पष्टीकरण की प्रतिध्वनि होती है, मैं इसे उत्तर के रूप में चिह्नित करूंगा, जो कि स्पष्टीकरण की व्याख्या कर रहा है। मेरा अंतिम संपादन देखें
mike-m

19

इस तरह फ़ाइलों / direcories को हटाने का एक तरीका उनके इनोडे-संदर्भ द्वारा है।

वर्तमान dir में तत्वों के लिए इनोड्स खोजने के लिए:

ls -i
14813568 mikeaâcnt

इसे हटाने के लिए:

find . -inum 14813568 -delete

कृपया 5 वां संपादन देखें।
माइक-एम।

4
नहीं, यह इनकोड द्वारा फाइलों को डिलीट नहीं करता है। यह दिए गए इनकोड के लिए एक फ़ाइल नाम की तलाश करता है, और फिर फ़ाइल को उसके नाम से हटा देता है। यह यहाँ मदद नहीं कर सकता है, क्योंकि पहले से ही सही नाम के साथ एक प्रयास किया गया था (एक गलत नाम के साथ अन्य प्रयासों के साथ)।
गाइल्स 'एसओ- बुराई को रोकना'

@ गिल्स - तकनीकी रूप से, यह एक इनोड डेंट्री की तलाश करता है और एक फ़ाइल नाम देता है, लेकिन मैं सहमत हूं।
चाटुकार

1
@ निकोलाई मेरे लिए मदद नहीं कर रहा। निर्देशिका खाली संदेश नहीं आता है।
diffracteD

1
हाँ, हा, इस बारे में मज़ेदार कहानी: मैं जिस फ़ाइल को हटाने की कोशिश कर रहा हूँ, ?उसका इनोड संदर्भ है। फिर आप इसे कैसे हटाते हैं?
निक हार्टले

7

आपको कमांड लाइन में गैर-एएससीआईआई पात्रों का उपयोग नहीं करना चाहिए क्योंकि आप देख सकते हैं, किसी कारण से, वे आवश्यक रूप से फ़ाइल नाम के अनुरूप नहीं होंगे (यूनिकोड में उच्चारण अक्षरों को व्यक्त करने के विभिन्न तरीके हैं)। कुछ इस तरह:

rm -rf mike*

काम करना चाहिए क्योंकि फ़ाइल नाम सीधे शेल द्वारा उत्पन्न होता है। लेकिन सुनिश्चित करें कि केवल एक मैच है ( echo mike*पुष्टि करने के लिए पहली बार करें)।

ठीक है, अगर cdकाम करता है, तो कोई कारण नहीं है rmया lsकहना चाहिए No such file or directory, ताकि समस्या फ़ाइल सिस्टम स्तर पर हो।

नोट: का प्रयोग न करें lsकि क्या एक निर्देशिका खाली है खोजने के लिए है, लेकिन ls -a

निर्देशिका को अभी भी किसी अन्य प्रक्रिया द्वारा उपयोग किया जा सकता है (यदि यह किसी प्रक्रिया का cwd है सहित)। IMHO, यही कारण है कि यह अभी भी "मौजूद है", लेकिन त्रुटियों को जन्म दे सकता है, जैसे ls; lsofआपको कुछ जानकारी दे सकता है, लेकिन NFS के साथ, आपको यह पता लगाना होगा कि कौन सी मशीन इसका उपयोग करती है। विशेष रूप से एनएफएस के साथ, यह अजीब त्रुटियां पैदा कर सकता है। ls -aमूल निर्देशिका में आप .nfs*कुछ मामलों में फ़ाइलें / निर्देशिका दिखा सकते हैं ।

आप कब प्राप्त करोगे:

$ ls
ls: cannot access mikeaâcnt: No such file or directory
mikeaâ??cnt

मुझे संदेह है कि एनएफएस कैशिंग और / या क्योंकि यह किसी अन्य प्रक्रिया द्वारा उपयोग किया जाता है, लेकिन संबंधित जानकारी के बिना निर्देशिका तालिका में फ़ाइल अभी भी मौजूद है । जब lsफ़ाइल पर स्वयं जानकारी प्राप्त करने की कोशिश की जाती है, तो उसे एक त्रुटि मिलती है क्योंकि फ़ाइल अब मौजूद नहीं है (यह केवल निर्देशिका तालिका में है), इसलिए प्रदर्शित त्रुटि। फिर lsफ़ाइल नाम आउटपुट करता है क्योंकि यह निर्देशिका तालिका में है। सच है कि आप एक मामले में प्रश्न चिह्न है, लेकिन नहीं अन्य मामले में की एक प्रदर्शन बग के कारण है lsIMHO (आपकी समस्या से संबंधित नहीं)।


मैंने पहले एक वाइल्डकार्ड की कोशिश की थी, यह काम नहीं किया, और मैं अपने प्रश्न में उस प्रयास को पोस्ट करने में विफल रहा, मैं परिणाम के साथ अपडेट करूंगा
माइक-एम

मेरा तीसरा संपादन देखें। IMHO यह एनएफएस (शायद भ्रष्टाचार नहीं, लेकिन खराब कैशिंग) के कारण है और संभवत: यह तथ्य है कि एक और प्रक्रिया निर्देशिका का उपयोग कर रही है। कुछ मामलों में, किसी को सब कुछ (सर्वर और क्लाइंट) को रिबूट करने की आवश्यकता होती है।
vinc17

शायद यह चीजों को समझा सकता है, लेकिन मुझे यकीन नहीं है क्योंकि मेरे पास यह परीक्षण करने के लिए निजीकरण नहीं है। 5 वां संपादन देखें।
माइक-एम

1
@ vinc17 कृपया अपने उत्तर में "EDIT" का उपयोग न करें, क्योंकि नए पाठक के लिए इसका कोई मतलब नहीं है (पहले से ही एक संपादित इतिहास है)
बर्नहार्ड

iv ने कुछ lsof आउटपुट जोड़े, यह सुनिश्चित नहीं था कि यह आपको कुछ भी बता सकता है,
mike-m

3

मैं व्यक्तिगत रूप से का उपयोग कर परीक्षण किया है findके -execनिर्देश:

$ mkdir -p mikeaâcnt
$ ls
mikeaâcnt
$ find -maxdepth 1 -type d -empty -exec rm -rf {} +
$ ls
$ 

फ़ोल्डर सही ढंग से बनाया गया था और सही ढंग से हटा दिया गया था।

जैसा कि @Igeorget द्वारा बताया गया है , यदि आपके पास GNU है तो एक और भी सरल विधि है find:

$ find -maxdepth 1 -type d -empty -delete

मैंने इस कमांड का परीक्षण भी किया, और यह सही ढंग से काम करता है


और यदि आप GNU की खोज का उपयोग करते हैं, तो एक -deleteविकल्प भी है।
lgeorget

कृपया तीसरा संपादन देखें,
mike-m

1

मुझे भी यही समस्या हुई है, मुझे विश्वास है। मैंने पहले एक फ़ाइल नाम के साथ समस्या देखी है lsइस मामले में के रूप में फ़ाइल प्रदर्शित की है â??, लेकिन मैं इसे हटाने में सक्षम था rm ☃

यह मुझे गलत नाम को सही में बदलने के लिए निम्नलिखित तरीके से ले गया:

पहले फ़ाइल नाम के बाइट्स प्राप्त करें:

$ ls --show-control-chars | xxd
0000000: 6d69 6b65 61c3 a2c2 81c2 8463 6e74 0a    mikea......cnt.

फिर यूटीएफ -8 के रूप में इन बाइट्स को डिकोड करें, यूनिकोड कोडपॉइंट्स प्राप्त करने के लिए, उदाहरण के लिए इस वेबसाइट के हेक्साडेसिमल इनपुट का उपयोग करते हुए: http://software.hixie.ch/utilities/cgi/unicode-decod-utf8-decoder

U+006D LATIN SMALL LETTER M character
U+0069 LATIN SMALL LETTER I character
U+006B LATIN SMALL LETTER K character
U+0065 LATIN SMALL LETTER E character
U+0061 LATIN SMALL LETTER A character
U+00E2 LATIN SMALL LETTER A WITH CIRCUMFLEX character (&#x00E2;)
U+0081 <control> character (&#x0081;)
U+0084 <control> character (&#x0084;)
U+0063 LATIN SMALL LETTER C character
U+006E LATIN SMALL LETTER N character
U+0074 LATIN SMALL LETTER T character

ध्यान दें कि ये सभी बाइट सीमा से नीचे हैं। हम निम्नलिखित बाइट्स प्राप्त करते हैं:

6D 69 6B 65 61 E2 81 84 63 6E 74

यदि हम UTF-8 में इस क्रम का उपचार करते हैं, तो हम प्राप्त करते हैं:

U+006D LATIN SMALL LETTER M character
U+0069 LATIN SMALL LETTER I character
U+006B LATIN SMALL LETTER K character
U+0065 LATIN SMALL LETTER E character
U+0061 LATIN SMALL LETTER A character
U+2044 FRACTION SLASH character (&#x2044;)
U+0063 LATIN SMALL LETTER C character
U+006E LATIN SMALL LETTER N character
U+0074 LATIN SMALL LETTER T character

और इस प्रकार आपका फ़ाइल नाम है: mikea⁄cntएक सामान्य फॉरवर्ड के बजाय एक अंश स्लेश के साथ। अब आप इस नाम को पास कर सकते हैं rmdir


यह सरल है, अगर मैं इसे फिर से पूरा करता हूं, तो इसे ध्यान में रखना चाहिए। अच्छा था। +1
माइक-

0

फ़ाइल / फ़ोल्डर नाम का सही हेक्स कोड प्राप्त करने के बाद (जो भी विधि मुझे फिट दिखाई देती है, उसका उपयोग करके ls --show-control-chars | xxd), कुछ विशेष निर्माण का उपयोग ऐसे पात्रों को संबोधित करने के लिए किया जाना चाहिए, जब वे नीचे चल रहे हों:

rmdir $'mikea\xc3\xa2\xc2\x81\xc2\x84cnt'

अन्यथा बैकस्लैश को वैनिला बैकस्लैश के रूप में माना जाता है।


कृपया मेरे संपादन (8 वें संपादन) पर एक नज़र डालें
माइक-

@ माइक-मी निश्चित रूप से मौजूद नहीं है, क्योंकि lsआउटपुट डेटा में न्यूलाइन और "cnt" डुप्लिकेट है। हो सकता है कि आप सीधे मेरे उत्तर में लाइन को कॉपी और पेस्ट करने की कोशिश करें और देखें कि क्या यह प्रभावी है?
हाबिल Cheung

नहीं, फिर भी यह: `` rl] $ rmdir $ 'mikea \ xc3 \ xa2 \ xc2 \ x81 \ xc2 \ x84cnt' rmdir: `ikeaâ \ 302 \ 2012 \ 302 \ 204cnt 'निकालने में विफल: ऐसी कोई फ़ाइल या निर्देशिका नहीं `` `
माइक-एम

उस स्थिति में यह काफी संभावना है कि एनएफएस समस्या का एक संयोजन है और स्थानीय सिस्टम अधिकांश गैर-उपयोगिताओं को रोकने के लिए गलत गैर-यूटीएफ 8 बाइट्स को पारित करता है। और ऐसा लग रहा है कि इनोड हटाने से स्थिति और खराब हो गई है। अभी के लिए, एक ही तरीका है जिसके बारे में मैं सोच सकता हूं कि आप अपने सिस्टम को लोकल-फ्री वातावरण ("C" लोकेल LC_*और LANGenv वेरिएबल्स के लिए इस्तेमाल कर रहे हैं), और NFS को बिना किसी कैरेक्टर सेट विकल्पों के माउंट करें
Abel Cheung

0

आप उपयोग कर की कोशिश की है rm -rf ./mikeaâcntया rm -rf "./mikeaâcnt"या एक निरपेक्ष पथ? इसके बजाय rm, प्रयास करें rmdir ./mikeaâcnt


समस्या का एक हिस्सा यह है कि वर्ण mikeaâcntफिल्नाम नहीं प्रतीत होते हैं, लेकिन जो ls प्रदर्शित होता है, उसे देखें 3 संपादित करें
mike-m

0

क्या आपने उस फ़ाइल का इनकोड प्राप्त करने का प्रयास किया है stat:

stat mike*

इससे आपको इनकोड नंबर (और अन्य डेटा) देना चाहिए, और फिर आप इसे हटाने का प्रयास कर सकते हैं।


iv ने statव्यवहार के साथ एक संपादन जोड़ा ,
mike-m

0

मेरे पास इसी तरह के मुद्दे थे। क्या आपके पास Gnome, KDE या किसी प्रकार का Xwindow DM ?. यदि आप अपनी फ़ाइल ब्रॉज़र को खोलते हैं और फ़ाइल को वहाँ से हटाते हैं।

यह काम करना चाहिए।

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

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