क्यों Windows इस फ़ोल्डर की रिपोर्ट करने के लिए कॉपी करने के लिए बहुत लंबा है?

यदि आप विंडोज के साथ पर्याप्त रूप से लंबे समय तक काम करते हैं, विशेष रूप से फ़ोल्डर और फ़ाइलों के साथ जिनके लंबे नाम हैं, तो आप एक विचित्र त्रुटि में चलेंगे: विंडोज रिपोर्ट करेगा कि फ़ोल्डर पथ या फ़ाइल का नाम एक नए गंतव्य पर जाने या यहां तक ​​कि हटाने के लिए बहुत लंबा है। क्या बात है?

अरे कैसे-कैसे गीक!

इसलिए दूसरे दिन, मैं अपने कंप्यूटर पर कुछ फ़ाइलों को पुनर्गठित कर रहा था, फ़ोल्डर बना रहा था, उस तरह का सामान। फिर, जब मैं कुछ फ़ाइलों को एक फ़ोल्डर में ले जा रहा था, तो मुझे एक संदेश मिलता है, जिसमें कहा गया है कि परिणामी फ़ोल्डर पथ बहुत लंबा होगा। मैं भ्रमित था। मुझे पता है कि डॉस के बाद से हर एक ओएस लॉन्ग फाइलनेम का समर्थन करता है, फिर भी विंडोज का दावा है कि रास्ता बहुत लंबा है? ऐसा क्यों होता है?

Sincerly,

श्री अव्यवस्थित

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

विंडोज 95 में अंतर्निहित MS-DOS आर्किटेक्चर के माध्यम से लंबे फाइलनाम पेश किए गए थे। 255 अक्षरों तक की फ़ाइल और निर्देशिका नामों के लिए नई LFN प्रणाली की अनुमति दी गई थी। यह पिछली फ़ाइल नाम प्रणाली का एक स्वागत योग्य विस्तार था, जिसे आमतौर पर 8.3 फाइलिंग कहा जाता था क्योंकि यह नाम आठ वर्णों और तीन अंकों के विस्तार तक सीमित था, लेकिन इसे शॉर्ट फिलनेम (एसएफएन) के रूप में भी जाना जाता था। जैसा कि आप कल्पना कर सकते हैं, वापस तो अभी भी बहुत सारे डॉस-आधारित ऐप थे और कुछ से अधिक सिरदर्द थे जो नए एलएफएन और विरासत एसएफएन को एक दूसरे के साथ अच्छा खेलने की कोशिश कर रहे थे। यदि आप कभी भी एक पुराने डिस्केट या सीडी-रॉम पर अजीब तरह से छंटनी की गई फाइलों (जैसे abcdef ~ 1.txt) के साथ आए हैं, तो फ़ाइल नाम को कुछ SFN का उपयोग करके कुछ लंबे और असमर्थित LFN (जैसे abcdefghijk) से कट गया था। टेक्स्ट).

हम 1990 के दशक के मध्य से एक लंबा रास्ता तय कर रहे हैं, हालांकि, और पूरी लंबी फिल्म का नाम (अधिकांश भाग के लिए) मजबूती से बाहर है। यदि आप पिछले 10 वर्षों से विंडोज का एक संस्करण चला रहे हैं, तो संभव है कि आप कभी भी फ़ाइल नाम की लंबाई के टकराव में नहीं आए हों, जैसे कि हम डॉस / विंडोज 95 दिनों में वापस चलाते थे। उस ने कहा, हम अभी भी हिचकी में चलते हैं, जैसा कि आपने अपने डिस्क क्लीनअप प्रोजेक्ट के साथ खोजा था। पर क्यों? यदि विंडोज 'लॉन्ग फाइलन सिस्टम फोल्डर्स और फाइल नामों को 255 कैरेक्टर प्रति घटक तक सपोर्ट करता है, तो आप किस दीवार में चल रहे हैं? हम NTFS को दोष नहीं दे सकते (फाइलसिस्टम जो कि आधुनिक विंडोज मशीनों के विशाल बहुमत का उपयोग करता है) NTFS के रूप में फ़ोल्डर्स और फ़ाइल नामों की एक श्रृंखला का समर्थन करेगा, जो कुल पथ की लंबाई 32,767 अक्षर है। अब तक विशिष्ट निर्देशिका संरचना से अधिक है जो अधिकांश उपयोगकर्ताओं को कभी भी आवश्यकता होगी.

जहां यह सब अलग हो जाता है वह LFN / NTFS सिस्टम के शीर्ष पर एक कृत्रिम प्रतिबंध विंडोज स्टैक है: MAX_PATIN चर। MAX_PATH वैरिएबल निर्दिष्ट करता है कि विंडोज में एक पूर्ण निर्देशिका संरचना 260 कुल वर्णों को पार नहीं कर सकती है, जिसमें ड्राइव अक्षर, बृहदान्त्र, बैकस्लैश और नल बैकलैश शामिल हैं। इस प्रकार आपके पास केवल 256 अक्षरों का एक वास्तविक वास्तविक MAX_PATH है, उदा. C: \ अपने-256-चरित्र-पथ \.

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

अब, आप सोच रहे होंगे “आह-हा! हम सिर्फ MAX_PATH चर को बदलेंगे और समस्या को हल करेंगे! ”काश, यह इतना आसान नहीं होता। न केवल MAX_PATH वैरिएबल अनिवार्य रूप से विंडोज में हार्ड कोडित है, लेकिन अगर आप इसे बदलने की भारी परेशानी से गुजरते हैं, तो भी आप अंत में इसे इतना तोड़ पाएंगे कि यह इसके लायक नहीं होगा। बहुत से एप्लिकेशन पथ के वैरिएबल की अपेक्षा करते हैं कि विंडोज लंबे समय तक इसे निर्दिष्ट करता है। हम सिर्फ एक विशाल गड़बड़ बनाने के बिना इसे बदलने के आसपास नहीं जा सकते.

वह आपको कहां छोड़ता है? ठीक है, सबसे सरल समाधान केवल पथ डेटा को संपादित करना है। उदाहरण के लिए, यदि आपके पास सहेजे गए लेखों का एक टन है, जहां आपके द्वारा वेब से उन्हें सहेजने के लिए उपयोग किए जाने वाले एप्लिकेशन / एक्सटेंशन ने एक निर्देशिका बनाई है जो लेख + लेख लीड का पूर्ण शीर्षक थी, और फिर फ़ाइल का नाम ही पूर्ण शीर्षक है लेख + लेख का नेतृत्व, यह वास्तव में हिट करने के लिए या एक ही बचत के साथ MAX_PATH से अधिक सरल होगा। उन विशाल फ़ोल्डर और लेख के शीर्षक को अधिक उचित आकार में संपादित करना समस्या को ठीक करने का एक आसान तरीका है.

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

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

rmdir c: \ document \ some-really-super-long-folder-name-Scheme \

सेवा मेरे:

rmdir \\? \ c: \ दस्तावेज \ कुछ-वास्तव में सुपर-लॉन्ग-फोल्डर-नाम-स्कीम \

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

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

एक टेक तकनीक का सवाल है? हमें@@ttogeek.com पर एक ईमेल भेजें और हम इसका जवाब देने की पूरी कोशिश करेंगे.