इसे हटाने का प्रयास करते समय यह फ़ाइल स्पष्ट रूप से मौजूद क्यों नहीं है?

Question

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

C:\cygwinसाइगविन में रहता है , और मैं स्रोत को अनारक्षित करता हूं C:\cygwin\src\linux-3.7.1। यह संकलन नहीं था ... इसलिए मैंने फ़ोल्डर को हटाने का प्रयास किया। यह अच्छी तरह से चल रहा था, अंत तक, जब मुझे एहसास हुआ कि सभी फाइलें नष्ट नहीं हुई हैं। मैंने linux-3.7.1फ़ोल्डर को फिर से हटाने की कोशिश की , और एक त्रुटि पॉप अप हुई:

मैंने फ़ोल्डर खोला, और पाया कि 1 स्रोत फ़ाइल बची है: aux.cजो अंदर है C:\cygwin\src\linux-3.7.1\drivers\gpu\drm\nouveau\core\subdev\i2c\aux.c।

यह नहीं होगा:

• हटाएं
• खुला हुआ
• चाल

सामान्य विशेषता:

सुरक्षा गुण:

मैं इस फ़ाइल को कैसे निकालूँ?

Comments

ठीक है, इस समय यह चल रहा है

— एलेक्स

हो गया, हालांकि काम नहीं किया ...

— एलेक्स

काम नहीं करना चाहिए। इसे डॉस / विंडोज के अंदर से डिलीट करने की अक्षमता इस प्रकार है। इस प्रकार यह कोई त्रुटि नहीं है जिसे आप इस तरह से ठीक कर सकते हैं।

— हेन्नेस

Answer 1

इसे (उन्नत) कमांड प्रॉम्प्ट से आज़माएँ:

del \\?\C:\cygwin\src\linux-3.7.1\drivers\gpu\drm\nouveau\core\subdev\i2c\aux.c

Comments

ठीक aux.cहै, हटा दिया गया है, लेकिन अब `src` फ़ोल्डर स्पष्ट रूप से उपयोग में है जब मैं इसे हटाने की कोशिश करता हूं

— एलेक्स

इसके अंदर कुछ भी छिपा नहीं है? शायद rd /s /q \\?\C:\cygwin\srcमदद करेगा।

— करण

प्रिंट का उत्पादन कि `src` उपयोग में है

— एलेक्स

करण: ओह, चतुर। सामान्य फाइलसिस्टम नामस्थान से बचना। @ एलेक्स यान: फ़ोल्डर में कोई cmd विंडो नहीं खुली?

— हेन्नेस

हाँ, rd को तब तक ट्रिक करनी चाहिए जब तक कि कुछ फ़ोल्डर की पकड़ में न आ जाए, या उसके अंदर कोई फ़ाइल न हो ... अन्य सभी खुली हुई विंडो / एप्स को बंद करें और src के प्रॉपर्टीज को चेक करें। दिखाए गए फ़ाइल का आकार और संख्या क्या है?

— करण

Answer 2

प्राचीन DOS आरक्षणों के कारण आप जिस समस्या में भाग गए थे।

नीचे दी गई सूची की फाइलों के विशेष अर्थ थे। इसका एक हिस्सा अभी भी आधुनिक दिन के विंडोज़ संस्करणों में मौजूद है:

CON, PRN, AUX , CLOCK $, NUL, COM1, COM3, COM3, COM4, ​​COM6, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, और LPT9।

उन्हें हटाने का सबसे आसान तरीका एक ऑपरेटिंग सिस्टम को बूट करना है जो इन फाइलनामों को विशेष नहीं मानता है। (उदाहरण के लिए किसी भी गैर-विंडोज लाइवसीडी को बूट करें)।

win7-x86 अंतिम पर किए गए परीक्षण [संपादित करें]

एक साधारण परीक्षण फ़ाइल बनाना:

S: \> प्रतिलिपि चोर foo.c
परीक्षा
^ Z
        1 फ़ाइल (ओं) की नकल की।

सामग्री की जाँच:

S: \> प्रकार foo.c
परीक्षा

अब aux के साथ .c

S: \> प्रतिलिपि con aux.c
^ Z
सिस्टम निर्दिष्ट फाइल का पता लगाने में नाकामयाब रहा।
        0 फ़ाइल (ओं) की नकल की।

ऐसा लगता है कि खिड़कियों के कुछ हिस्से अभी भी पीछे की ओर संगत हैं।

Comments

लेकिन यह फाइल हैaux.c

— एलेक्स

यह अभी भी ऑक्स के साथ शुरू होता है, और पुरानी फ़ाइल नाम शैली "फाइलनेम" डॉट "एक्सटेंशन" है। और मैंने सिर्फ copy con aux.cwin7 पर परीक्षण किया और यह विफल रहा। ( copy con test.cकाम करता है)।

— हेन्नेस

Answer 3

इस मामले में यह स्पष्ट रूप से DOS समय से विरासत में auxमिले विशेष अर्थ के बारे में था , क्योंकि हेन्नेस ने सही ढंग से बताया। हालाँकि, भविष्य में इस पर ठोकर खाने वाले पाठकों के लिए मैं एक और संभावित मामला जोड़ना चाहूँगा जहाँ इस व्यवहार को देखा जा सकता है।

जब एक फ़ाइल एक अनुगामी बिंदु के साथ बनाई गई थी। अधिक विदेशी मामले भी हैं। लेकिन filename.ext.ऐसा एक फ़ाइल नाम होगा और सामान्य रूप से Win32 सबसिस्टम से हटाया नहीं जा सकता है। यह वह जगह है जहां करण से चाल आती है। एस / वह एक नाम का उपयोग करता है जिसे Win32 सबसिस्टम के नीचे की परत में दिए जाने से पहले उसके \\?\C:\...रूप से "मूल" में बदल दिया जाएगा (यह भी है कि फ़ाइल सिस्टम फ़िल्टर ड्राइवर इसे कैसे देखते हैं) रूप \??\C:\...। जबकि विंडोज के संस्करण के आधार पर यह एक तथाकथित ऑब्जेक्ट डायरेक्टरी हो सकती है (ऑब्जेक्ट मैनेजर नेमस्पेस में जाने के लिए Sysinternals / Microsoft से WinObj का उपयोग करें) या एक प्रतीकात्मक लिंक (विस्टा के बाद से NTFS में पहचान की गई इकाई के साथ भ्रमित नहीं होने के लिए) किसी अन्य ऑब्जेक्ट डायरेक्टरी जैसे कि\DosDevices। उत्तरार्द्ध केवल एक नाम है और डिफ़ॉल्ट रूप से Win32 प्रक्रियाओं के लिए दिखाई देने वाले ऑब्जेक्ट प्रबंधक नामस्थान के भाग का वर्णन करता है। अधिक जानकारी के लिए, पुस्तक श्रृंखला विंडोज इंटर्नल्स की जांच करें या विशेष रूप से Google के प्रोजेक्ट ज़ीरो पर विशेष रूप से पार्सिंग पर पढ़ें (Win32 पर NT पथ रूपांतरण के लिए निश्चित गाइड) । विशेष रूप से आप Win32 फ़ाइल नामस्थान और Win32 डिवाइस नामस्थान के बीच अंतर पर ध्यान देना चाह सकते हैं ।

अब ऐसी फाइल पहली जगह में कैसे बनाई जा सकती है? कई संभावनाएं हैं।

1. एक Win32 प्रोग्राम जो \\?\X:पथ नामों के लिए उपसर्ग को नियोजित करता है ताकि 260 वर्णों से उपलब्ध पथ की लंबाई को लगभग 32767 वर्णों तक बढ़ाया जा सके (देखें फुटनोट 1!) ने पहली बार फ़ाइल बनाई, इस प्रकार Win32 सबसिस्टम की कुछ सीमाओं को दरकिनार कर दिया ।
2. एक कार्यक्रम एक अलग उपतंत्र में निहित है। पूर्व POSIX सबसिस्टम (बाद में इंटरिक्स अब SUA), OS / 2 सबसिस्टम (लंबे समय तक चला गया, लेकिन NT 3.51 पर मौजूद था) या कुछ परत जो Windows समझ में बिल्कुल सबसिस्टम नहीं है (Cygwin, to my knowledge) फ़ाइल या फ़ोल्डर। इसी तरह विंडोज 10 पर डब्ल्यूएसएल (लिनक्स के लिए विंडोज सबसिस्टम) अब एक और उम्मीदवार है।
3. एक अलग ऑपरेटिंग सिस्टम ने इसे बनाया (समानांतर लिनक्स बूट, उदाहरण के लिए)।
4. यह एक गैर-विंडोज सर्वर पर स्थित नेटवर्क शेयर पर एक फाइल है।

अंतिम दो बिंदु भी उल्लेखित उपायों में से एक पर संकेत देते हैं: एक गैर-विंडोज लाइव सीडी को बूट करें और फ़ाइल (एस) को हटा दें।

मुद्दा वास्तव में उस मामले की तुलना में हो सकता है जहां एक पुराना गैर-यूनिकोड Win32 कार्यक्रम कई कोड पृष्ठों से फ़ाइल नाम के साथ सामना किया जाता है। अक्सर यह उनमें से कुछ को "ढूंढने" में सक्षम नहीं होगा, क्योंकि प्रत्येक संबंधित एएनएसआई कोडपेज केवल 256 वर्णों को फिट कर सकता है, जबकि यूटीएफ -16 (इसके सबसेट यूसीएस -2 नहीं, हालांकि) सैद्धांतिक रूप से कोड बिंदुओं की लगभग असीमित मात्रा में सांकेतिक शब्दों में बदल सकता है। ( unicode.org और विकिपीडिया पर इस विषय पर पढ़ें )।

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

---

फुटनोट 1: पथ में अधिकतम वर्ण निरपेक्ष नहीं है, क्योंकि एक पथ जो कि अधिकतम अधिकतम (32767 वर्ण) के करीब है, अच्छी तरह से वस्तु प्रबंधक और फ़ाइल सिस्टम फ़िल्टर या फ़ाइल सिस्टम द्वारा स्वयं दोनों का विस्तार कर सकता है (उदाहरण के लिए बिंदुओं को फिर से बनाएँ) ।

Comments

मुझे जोड़ा तकनीकी पृष्ठभूमि से प्यार है।

— हेन्नेस

Answer 4

मेरे पास यह मुद्दा था और बहुत निराश था, कुछ भी काम नहीं किया। फिर, मैंने एक लिनक्स उबंटू सीडी का उपयोग किया। सीडीरॉम से बूट किया गया, डेमो मोड में गया, एक्सेस किया गया जहां परेशान फाइलें थीं और बस उन्हें हटा दिया गया। यह एक सपने की तरह काम करता है।

Comments

ज्ञात हो, कि विंडोज के एक फ़ाइल को डिलीट न कर पाने का कारण, यह तथ्य हो सकता है कि विंडोज में जिन पात्रों को अनुमति नहीं है, उन्हें लिनक्स पर फ़ाइल नाम में डाल दिया गया है। मुझे पूरा यकीन है कि यह नहीं है क्योंकि लिनक्स परवाह नहीं करता है। मैंने मध्यस्थों से कुछ पाठ को हटाने को मंजूरी देने और उस हिस्से को रखने के लिए कहा जो प्रयोग करने योग्य है।

— मोगेट