Windows में 260 वर्ण पथ लंबाई सीमा क्यों मौजूद है?

Question

मैं इस समस्या के खिलाफ कुछ समय के लिए आया हूँ

• गहरे रास्तों वाले ओपन सोर्स जावा प्रोजेक्ट पर काम करने की कोशिश की जा रही है
• स्रोत नियंत्रण में गहरे फिटनेस वाले विकी पेड़ों को संग्रहीत करना
• मेरे स्रोत नियंत्रण ट्री को आयात करने के लिए बाज़ार का उपयोग करने की कोशिश में त्रुटि

यह सीमा क्यों मौजूद है?

इसे अभी तक क्यों नहीं हटाया गया?

आप पथ सीमा के साथ कैसे सामना करते हैं? और नहीं, लिनक्स या मैक ओएस एक्स पर स्विच करना इस सवाल का एक वैध जवाब नहीं है;)

Comments

@Artelius: वास्तव में, विंडोज (Win2K से कम से कम के बाद) समर्थन जंक्शन अंक (करता en.wikipedia.org/wiki/NTFS_junction_point ), और Vista के बाद NT सांकेतिक लिंक (समर्थन en.wikipedia.org/wiki/NTFS_symbolic_link )। वैसे भी, जबकि सीमलिंक लंबे समय तक / नेस्टेड पथों को अधिक अनुकूल बनाने में मदद कर सकते हैं, मैं नहीं सोच सकता कि यदि आप लंबाई की सीमा को मार रहे हैं तो सिमिलिंक कैसे मदद करेंगे।

— आशुतोष मेहरा

यहां तक ​​कि अगर यह सीमा मौजूद नहीं थी, तो हमेशा बहुत सी अन्य सीमाएं होती हैं, और उनमें से हर एक किसी न किसी बिंदु पर कष्टप्रद हो सकती है। मुद्दा यह है कि यह सीमा इतनी कम क्यों है? 8.3 के युग के बाद, और मेगा / गीगा आकार के हार्डवेयर के साथ, एक पथ को अब लगभग असीमित आकार के साथ गतिशील रूप से आवंटित स्ट्रिंग होना चाहिए।

— रोलैंड

Microsoft आखिरकार विंडोज 10 बिल्ड 14352 में इस समस्या को संबोधित कर रहा है।

— वॉरेन पी

हां, और ऐसा लगता है कि आपको लंबे पथ से अवगत कराने के लिए ऐप मैनिफ़ेस्ट को संशोधित करना होगा।

— वॉरेन पी।

@PatrickSzalapski दुर्भाग्य से यह तय किया गया था visualstudio.uservoice.com/forums/121579-visual-studio/...

— phuclv

Answer 1

इस लेख का उद्धरण https://docs.microsoft.com/en-us/windows/desktop/FileIO/naming-a-file#maximum-path-length-limitation

अधिकतम पथ लंबाई सीमा

विंडोज एपीआई में (निम्नलिखित पैराग्राफ में चर्चा किए गए कुछ अपवादों के साथ), एक पथ के लिए अधिकतम लंबाई MAX_PATH है , जिसे 260 वर्णों के रूप में परिभाषित किया गया है। एक स्थानीय पथ को निम्न क्रम में संरचित किया गया है: ड्राइव लेटर, कोलन, बैकस्लैश, बैकस्लैश द्वारा अलग किए गए नाम घटक और एक समाप्ति नल वर्ण। उदाहरण के लिए, ड्राइव D पर अधिकतम पथ "D: \ 256-वर्ण पथ स्ट्रिंग <NUL>" है, जहां "<NUL>" वर्तमान सिस्टम कोडपेज के लिए अदृश्य समाप्ति शून्य वर्ण का प्रतिनिधित्व करता है। (वर्ण <> यहां दृश्य स्पष्टता के लिए उपयोग किए जाते हैं और मान्य पथ स्ट्रिंग का हिस्सा नहीं हो सकते।)

अब हम देखते हैं कि यह 1 + 2 + 256 + 1 या [ड्राइव] [: \] [पथ] [अशक्त] = 260 है। एक मान सकता है कि 256 डॉस दिनों से एक उचित निश्चित स्ट्रिंग लंबाई है। और डॉस एपीआई पर वापस जाने पर हमें पता चलता है कि सिस्टम ने प्रति ड्राइव वर्तमान पथ को ट्रैक किया है, और हमारे पास 26 (32 प्रतीकों के साथ) अधिकतम ड्राइव (और वर्तमान निर्देशिका) हैं।

INT 0x21 AH = 0x47 कहता है "यह फ़ंक्शन ड्राइव अक्षर और प्रारंभिक बैकस्लैश के बिना पथ विवरण देता है।" इसलिए हम देखते हैं कि सिस्टम सीडब्ल्यूडी को एक जोड़ी (ड्राइव, पथ) के रूप में संग्रहीत करता है और आप ड्राइव को निर्दिष्ट करके रास्ता पूछते हैं (1 = ए, 2 = बी, ...), यदि आप 0 निर्दिष्ट करते हैं, तो यह पथ को मानता है ड्राइव INT 0x21 AH = 0x15 AL = 0x19 द्वारा लौटाया गया। तो अब हम जानते हैं कि यह 260 क्यों है और 256 नहीं है, क्योंकि उन 4 बाइट्स पथ स्ट्रिंग में संग्रहीत नहीं हैं।

क्यों 256 बाइट पथ स्ट्रिंग, क्योंकि 640K पर्याप्त रैम है।

Comments

विंडोज एपीआई नवीनतम ओएस में भी लंबाई को सीमित करता है। Microsoft आज उपयोग में आने वाले लाखों ऑपरेटिंग सिस्टम को तोड़ने से डरता है अगर इसे बदलना था क्योंकि उनके पास अब काम करने वाले जीनियस नहीं हैं जो एपीआई को अंदर और बाहर समझते हैं, जैसे कि उन्होंने 1980 और 1990 के दशक में किया था। जोखिम इसे बदलने के लायक नहीं है। serverfault.com/questions/163419/…

— MacGyver

@MacGyver क्षमा करें, लेकिन यह पूरी तरह से बकवास है। माइक्रोसॉफ्ट कि वहाँ खराब लिखित आवेदन के लाखों लोगों को तोड़ने के लिए नहीं चाहता है मान प्रणाली है कि गारंटी नहीं कर रहे थे के बारे में बातें। दुर्भाग्य से, चीजें इतने लंबे समय तक उसी तरह से थीं कि डेवलपर्स उन पर भरोसा करने के लिए आए थे, इसलिए इसे बदलने से अब 3 पार्टी एप्लिकेशन टूट जाएंगे और एमएस को दोष मिलेगा।

— बेसिक

btw कोई सबूत नहीं है कि गेट्स ने कभी कहा "640K राम हर किसी के लिए पर्याप्त है" computerworld.com/article/2534312

— पैट्रिक फेवर

@Basic 260 वर्ण सीमा की गारंटी विंडोज द्वारा दी गई थी । निरंतर को एक स्थिर के रूप में घोषित किया गया था , एक संरचना को विंडोज हेडर फाइलों में घोषित किया गया था जिसमें केवल 260 वर्णों के लिए जगह है। इसे बदलने का कोई तरीका नहीं है।

— इयान बॉयड

मेरे आवेदन में संकलित होने के बाद @Basic स्थिरांक परिवर्तित नहीं होता है। मैं एक एप्लिकेशन चलाता हूं जो आखिरी बार 1994 में बनाया गया था, और अभी भी विंडोज 10 में आज भी चलता है। माइक्रोसॉफ्ट ने मेमोरी के एक ब्लॉक का एक निश्चित द्विआधारी आकार का वादा किया था, और प्रोग्रामर ने उस नियम का पालन किया। यदि Microsoft को निरंतर बदलना था, तो हर मौजूदा एप्लिकेशन, जिसने प्रोग्रामिंग API का सही ढंग से पालन किया, टूट जाएगा । आप बाइनरी संगतता को नहीं तोड़ सकते।

— इयान बॉयड

Answer 2

यह कड़ाई से सच नहीं है क्योंकि NTFS फाइलसिस्टम 32k वर्ण तक के पथ का समर्थन करता है। आप win32 एपि और " \\?\" का उपयोग कर सकते हैं जो 260 से अधिक वर्णों का उपयोग करने के लिए पथ को उपसर्ग करता है।

.Net BCL टीम ब्लॉग से लंबे रास्ते का विस्तृत विवरण ।
एक छोटा सा अंश इस मुद्दे को लंबे रास्तों से उजागर करता है

एक और चिंता असंगत व्यवहार है जो लंबे पथ समर्थन को उजागर करने के परिणामस्वरूप होगा। \\?\उपसर्ग के साथ लंबे पथ का उपयोग फ़ाइल-संबंधित विंडोज एपीआई के अधिकांश में किया जा सकता है, लेकिन सभी विंडोज एपीआई नहीं। उदाहरण के लिए, लोडिंगलिफ्ट, जो कॉलिंग प्रक्रिया के पते में एक मॉड्यूल को मैप करता है, यदि फ़ाइल का नाम MAX_PATH से अधिक लंबा है, तो विफल रहता है। तो इसका मतलब है कि MoveFile आपको किसी DLL को किसी ऐसे स्थान पर ले जाने देगा, जिसका पथ 260 वर्णों से अधिक लंबा हो, लेकिन जब आप DLL को लोड करने का प्रयास करेंगे, तो यह विफल हो जाएगा। पूरे विंडोज एपीआई में समान उदाहरण हैं; कुछ वर्कअराउंड मौजूद हैं, लेकिन वे केस-बाय-केस आधार पर हैं।

Comments

पर्याप्त रूप से उचित है, लेकिन इसका मतलब है कि आपको कई जगहों पर पी / इनवोक का उपयोग करना होगा और यह, मेरे दिमाग में, आपके .Net कोड की पोर्टेबिलिटी को कम करता है। क्या होगा अगर मैं मोनो-संगतता रखना चाहता हूं?

— जेफरी कैमरन

मेरा कहना था कि यदि आप वास्तव में चाहते हैं तो आप लंबे रास्ते का उपयोग कर सकते हैं। लेकिन मैं मानता हूं कि यह एक दर्द है और व्यक्तिगत रूप से मैं इससे भी बचूंगा।

— सॉफ्टवेय

यह चुना हुआ उत्तर होना चाहिए। वास्तव में इस सीमा के उपयोगकर्ता द्वारा प्रस्तुत प्रश्न का उत्तर क्यों मौजूद है और यह एक काम के आसपास प्रदान करता है। दृश्यता के लिए

— अपवोट

यह मुझे लगता है कि Microsoft को अपने एपीआई को ठीक करने की आवश्यकता है, और मुझे लगता है कि यह प्राथमिकता नहीं है। मैं हैरान था कि इस सीमा अभी भी Windows 8 में मौजूद है

— मास

@Mas "फिक्स" जो आप चाहते हैं वह सभी Windows XP में वापस किया गया था। उनके एपीआई के यूनिकोड संस्करण को कॉल करने से आप "विस्तारित पथ" तक पहुंच सकेंगे। मेरा मानना ​​है कि एक्सप्लोरर स्वचालित रूप से इसे संभालता है। यहाँ एक ऐसा कार्य है जो इसका समर्थन करता है - msdn.microsoft.com/en-us/library/windows/desktop/… ।

— नताली एडम्स

Answer 3

सवाल यह है कि सीमा अभी भी मौजूद क्यों है। निश्चित रूप से आधुनिक विंडोज MAX_PATHलंबे रास्तों की अनुमति देने के पक्ष को बढ़ा सकता है। सीमा क्यों नहीं हटाई गई?

• इसका कारण यह नहीं निकाला जा सकता है कि विंडोज ने वादा किया था कि यह कभी नहीं बदलेगा।

एपीआई अनुबंध के माध्यम से, विंडोज ने सभी अनुप्रयोगों की गारंटी दी है कि मानक फ़ाइल एपीआई 260वर्णों की तुलना में लंबे समय तक वापस नहीं आएगी ।

निम्नलिखित सही कोड पर विचार करें :

WIN32_FIND_DATA findData;

FindFirstFile("C:\Contoso\*", ref findData);

विंडोज ने मेरे कार्यक्रम की गारंटी दी कि यह मेरी WIN32_FIND_DATAसंरचना को आबाद करेगा :

WIN32_FIND_DATA {
   DWORD    dwFileAttributes;
   FILETIME ftCreationTime;
   FILETIME ftLastAccessTime;
   FILETIME ftLastWriteTime;
   //...
   TCHAR    cFileName[MAX_PATH];
   //..
}

मेरे एप्लिकेशन ने निरंतरता का मूल्य घोषित नहीं किया MAX_PATH, विंडोज एपीआई ने किया। मेरे अनुप्रयोग ने उस परिभाषित मूल्य का उपयोग किया।

मेरी संरचना सही ढंग से परिभाषित है, और केवल 592कुल बाइट्स आवंटित करता है । इसका मतलब है कि मैं केवल एक फ़ाइल नाम प्राप्त करने में सक्षम हूं जो 260वर्णों से कम है । विंडोज ने मुझसे वादा किया कि अगर मैंने अपने आवेदन को सही तरीके से लिखा है, तो भविष्य में मेरा आवेदन काम करना जारी रखेगा।

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

Microsoft को MAX_PATHनिरंतर बदलने के लिए कॉल करने वाले किसी भी व्यक्ति के लिए , उन्हें पहले यह सुनिश्चित करने की आवश्यकता है कि कोई मौजूदा एप्लिकेशन विफल न हो। उदाहरण के लिए, मैं अभी भी स्वयं का उपयोग करता हूं और एक विंडोज एप्लिकेशन का उपयोग करता हूं जिसे विंडोज 3.11 पर चलाने के लिए लिखा गया था। यह अभी भी 64-बिट विंडोज 10 पर चलता है। यही कारण है कि पीछे की संगतता आपको मिलती है।

Microsoft ने पूर्ण 32,768 पथ नामों का उपयोग करने का एक तरीका बनाया; लेकिन उन्हें ऐसा करने के लिए एक नया एपीआई अनुबंध बनाना पड़ा। एक के लिए, आपको फ़ाइलों को एन्यूमरेट करने के लिए शेल एपीआई का उपयोग करना चाहिए (क्योंकि हार्ड ड्राइव या नेटवर्क शेयर पर सभी फाइलें मौजूद नहीं हैं)।

लेकिन उन्हें मौजूदा उपयोगकर्ता अनुप्रयोगों को भी नहीं तोड़ना होगा। एप्लिकेशन के विशाल बहुमत फ़ाइल कार्य के लिए शेल एपीआई का उपयोग नहीं करते हैं। हर कोई बस एक दिन फोन करता FindFirstFile/ FindNextFileकरती है।

Comments

@JosiahKeller अगर यह किया, तो यह मूल रूप से उस पद्धति के लिए परिभाषित अनुबंध को तोड़ देगा, और ऐसा करने से अनायास ही स्मृति को अधिलेखित किया जा सकता है, और prtentially एक सुरक्षा छेद खोल सकता है। इसे ठीक करने का एकमात्र तरीका एक नया उन्नत एपीआई (जैसे यूनिकोड जागरूक संस्करण) प्रदान करना है, और सभी को नए एपीआई का उपयोग करके अपने सभी अनुप्रयोगों को recompiles / rereleases की उम्मीद है।

— रोलैंड शॉ

@ रॉयस मुझे नहीं लगता कि मेरे मौजूदा विंडोज एप्लिकेशन लिनक्स पर चलेंगे।

— इयान बॉयड

पिछड़ी अनुकूलता अच्छी है। लेकिन मुझे लगता है कि आज (अक्सर बहुत बुरा) समस्याओं से बचने के लिए विंडोज 3.1 एप्लिकेशन का समर्थन करने की तुलना में अधिक महत्वपूर्ण है। कितने लोग लंबे रास्तों के साथ समस्याओं का सामना करते हैं? और कितने लोग अभी भी विंडोज 3.1 एप्लिकेशन का उपयोग करते हैं? वे Windows XP के लिए समर्थन भी रद्द कर देते हैं। तो वे सिर्फ एक घोषणा क्यों नहीं करते हैं, कि विंडोज से [x] और बाद में आने वाले एप्लिकेशन जो यह मानते हैं कि 260 वर्णों से अधिक लंबा रास्ता नहीं होगा, जब वे एक पथ का अनुगमन करेंगे, जो अपेक्षित नहीं है? हमारी गति सीमाएँ भी गाड़ियाँ नहीं मानती हैं।

— JuSchu

@ जशुचू यह सिर्फ विंडोज 3.1 एप्लीकेशन नहीं है। सही API का उपयोग करके आज लिखे गए एप्लिकेशन काम नहीं करेंगे।

— इयान बॉयड

@ TheincredibleJan MSDN। दस्तावेज़ीकरण अनुबंध बनाता है, यही कारण है कि आपको बहुत सावधानी बरतने की आवश्यकता है कि आप क्या दस्तावेज हैं ।

— इयान बॉयड

Answer 4

विंडोज 10. से आप एक रजिस्ट्री कुंजी को संशोधित करके सीमा को हटा सकते हैं ।

टिप विंडोज 10 में शुरू, संस्करण 1607, MAX_PATH की सीमाएं आम Win32 फ़ाइल और निर्देशिका कार्यों से हटा दी गई हैं। हालाँकि, आपको नए व्यवहार के लिए ऑप्ट-इन करना होगा।

एक रजिस्ट्री कुंजी आपको नए लंबे पथ व्यवहार को सक्षम या अक्षम करने की अनुमति देती है। लंबी पथ व्यवहार सक्षम करने के लिए रजिस्ट्री कुंजी सेट करें HKLM\SYSTEM\CurrentControlSet\Control\FileSystem LongPathsEnabled(प्रकार:) REG_DWORD। प्रभावित Win32 फ़ाइल या निर्देशिका फ़ंक्शन (सूची का अनुसरण करता है) के लिए पहली कॉल के बाद कुंजी का मान सिस्टम (प्रति प्रक्रिया) द्वारा कैश किया जाएगा। रजिस्ट्री कुंजी को प्रक्रिया के जीवनकाल के दौरान पुनः लोड नहीं किया जाएगा। कुंजी के मूल्य को पहचानने के लिए सिस्टम पर सभी ऐप्स के लिए, रिबूट की आवश्यकता हो सकती है क्योंकि कुंजी सेट होने से पहले कुछ प्रक्रियाएं शुरू हो सकती हैं। रजिस्ट्री कुंजी को समूह नीति के माध्यम से भी नियंत्रित किया जा सकता है Computer Configuration > Administrative Templates > System > Filesystem > Enable NTFS long paths। आप प्रति ऐप के माध्यम से नए लंबे पथ व्यवहार को भी सक्षम कर सकते हैं:

<application xmlns="urn:schemas-microsoft-com:asm.v3">
    <windowsSettings xmlns:ws2="http://schemas.microsoft.com/SMI/2016/WindowsSettings">
        <ws2:longPathAware>true</ws2:longPathAware>
    </windowsSettings>
</application>

Comments

दुर्भाग्य से नवीनतम संस्करण Win10 में भी, फ़ाइल एक्सप्लोरर में अभी भी लंबे पथ के नाम से निपटने में समस्या है। यहां तक ​​कि संदर्भ मेनू में "कॉपी के रूप में पथ" उम्मीद के मुताबिक काम नहीं करता है; यह केवल पहले 260 वर्णों की प्रतिलिपि बनाता है। आप फ़ोल्डर, कॉपी / मूव / ओपन फाइल नहीं बना सकते ... मुझे आश्चर्य है कि इस बदलाव का क्या मतलब है।

— किरणमय ray

ध्यान दें कि सिस्टम सेटिंग मैनिफ़ेस्ट सेटिंग से स्वतंत्र होने का दावा गलत है। दोनों की आवश्यकता है। सिस्टम स्तर पर नीति को सक्षम करना पड़ता है और घोषणा को यह घोषित करना पड़ता है कि आवेदन लंबे समय से अवगत है।

— एर सन सन

मैंने पढ़ा कि इस परिवर्तन से पुराने 32-बिट अनुप्रयोगों के साथ संगतता समस्याएँ पैदा हो सकती हैं, लेकिन क्या इस प्रकार की समस्या सामान्य संगतता के साथ है? मैं खुद बदलाव लाना चाहता हूं। Lifehacker.com/ ...

— KDP

Answer 5

आप एक ड्राइव के रूप में एक फ़ोल्डर माउंट कर सकते हैं। कमांड लाइन से, यदि आपके पास एक रास्ता है C:\path\to\long\folderतो आप ड्राइव लेटर X:का उपयोग करके इसे मैप कर सकते हैं :

subst x: \path\to\long\folder

Comments

मैं "अवैध पैरामीटर जे:" प्राप्त कर रहा

— हूं

इसे एक प्रशासक (उन्नत) कमांड प्रॉम्प्ट से चलाने की आवश्यकता है।

— मृकुन

यह आगे की स्लैश के साथ विफल हो जाएगा, बैकस्लैश होने की आवश्यकता है।

— cchamberlain

मुझे यकीन नहीं है कि यह केवल विंडोज़ 10 पर लागू होता है, हालांकि मैंने अभी-अभी पाया कि जब इस कमांड को चलाने की कोशिश की जा रही है, अगर मैं एक प्रशासक के रूप में चलाऊं, जैसा कि ड्राइव के ऊपर सुझाया गया है, उपलब्ध नहीं है। ऐसा इसलिए है क्योंकि व्यवहार नेटवर्क ड्राइव को मैप करने के समान प्रतीत होता है और यह सत्र विशिष्ट आदि है, इसलिए जब मैंने एक व्यवस्थापक के रूप में भाग लिया और इस कमांड का उपयोग किया, तो वह सत्र x का उपयोग कर सकता है: TL; DR यदि आप ड्राइव को नहीं देख सकते हैं तो कोशिश करें; व्यवस्थापक मोड में होने के बिना कमांड चलाना।

— जेडी

substस्थानीय सत्र / खाता है - देखना superuser.com/questions/29072/... कैसे यह प्रणाली विस्तृत 'बनाने के लिए

— user2864740

Answer 6

पथ सीमा के साथ सामना करने का एक तरीका प्रतीकात्मक लिंक के साथ पथ प्रविष्टियों को छोटा करना है।

उदाहरण के लिए:

1. C:\pलंबे रास्तों के लिए छोटे लिंक रखने के लिए एक निर्देशिका बनाएँ
2. mklink /J C:\p\foo C:\Some\Crazy\Long\Path\foo
3. C:\p\fooलंबे पथ के बजाय अपने पथ में जोड़ें

Comments

पहले निर्देशिका बनाने के लिए नहीं था, इसलिए चरण 1 आवश्यक नहीं है।

— ओहल

यह ट्रिक हमेशा काम नहीं करती है क्योंकि कई एप्लिकेशन लिंक को हल करने की कोशिश करते हैं

— nponeccop

/jविकल्प के लिए एक स्थानीय मात्रा डिवाइस या एक स्थानीय वॉल्यूम पर एक पथ (एक यूनिक्स की तरह बाँध माउंट) के लिए एक जंक्शन माउंटप्वाइंट पैदा करता है। यह एक प्रतीकात्मक लिंक नहीं बनाता है। यह एक महत्वपूर्ण अंतर है क्योंकि जंक्शन माउंटपॉइंट का मूल्यांकन हमेशा सर्वर पर किया जाता है और इसे स्थानीय उपकरणों को लक्षित करना चाहिए, जबकि प्रतीकात्मक लिंक क्लाइंट पर मूल्यांकन किए जाते हैं और दूरस्थ पथ को लक्षित कर सकते हैं (यदि नीति द्वारा अनुमति दी गई है)। एक subst.exe ड्राइव (यानी DefineDosDeviceW) की तरह, एक जंक्शन लक्ष्य आमतौर पर लगभग 4K वर्णों तक सीमित होता है। यह वास्तव में 8K अक्षर है, स्थानापन्न पथ और प्रदर्शन पथ के बीच समान रूप से विभाजित।

— एरिक सन

Answer 7

आप PowerShell का उपयोग करके लंबे पथ नाम सक्षम कर सकते हैं:

Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem' -Name LongPathsEnabled -Type DWord -Value 1 

एक और संस्करण एक समूह नीति का उपयोग करने के लिए है में Computer Configuration/ Administrative Templates/ System/ Filesystem:

Comments

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

— एरिक सन

Answer 8

के रूप में क्यों यह अभी भी मौजूद है - एमएस इसे प्राथमिकता नहीं मानता है, और अपने ओएस को आगे बढ़ाने पर कम से कम संगतता का मान रखता है (कम से कम इस उदाहरण में)।

मेरे द्वारा उपयोग किया जाने वाला वर्कअराउंड पथ में निर्देशिकाओं के लिए "लघु नामों" का उपयोग करना है, बजाय उनके मानक, मानव-पठनीय संस्करणों के। इसलिए उदाहरण के लिए C:\Program Files\मैं का उपयोग करेंगे C:\PROGRA~1\ आप लघु नाम समकक्ष का उपयोग कर पा सकते हैं dir /x।

Comments

लघु पथ नाम को रजिस्ट्री में अक्षम किया जा सकता है (या क्या यह फ़ाइल सिस्टम ही था?), इसलिए यह वास्तव में भरोसेमंद समाधान नहीं है।

— रुबनेव

@rubenvb मुझे यकीन है कि सबसे अधिक नहीं अगर सभी विंडोज सुविधाओं को रजिस्ट्री में अक्षम किया जा सकता है तो _ \ _ (¯) _ / b

— कॉनरैड

संक्षिप्त नाम उत्पन्न करना NTFS के लिए अक्षम किया जा सकता है (और ऐसा होना चाहिए क्योंकि यह कई मामलों में अक्षम है), या तो पूरे सिस्टम या प्रति वॉल्यूम के लिए, इसलिए यह सिस्टम ड्राइव पर पथ के लिए भी एक अविश्वसनीय दृष्टिकोण है, जिसे NTFS होना चाहिए। NTFS में फ़ाइलों और निर्देशिकाओं पर मैन्युअल रूप से संक्षिप्त नाम सेट करना संभव है, लेकिन यह नए फ़ाइल सिस्टम का विस्तार नहीं करता है जो कम नामों का समर्थन नहीं करते हैं, जैसे कि exFAT और ReFS। लघु नामों को एक पदावनत सुविधा माना जाना चाहिए जो कि सीमित मामलों में अनुकूलता के लिए बरकरार है, जैसे कि पुराने ANSI / OEM एपीआई सिंगल-और बाइट कोडपे का उपयोग करते हैं।

— एरिक सन

@eryksun कृपया कम पथ नामों को अक्षम करने के बारे में मेरी पिछली टिप्पणी देखें। :) सिर्फ इसलिए कि आपको लगता है कि इसे पदावनत माना जाना चाहिए, इसका मतलब यह नहीं है कि यह वास्तव में है। MS की इस सुविधा को चित्रित करने की कोई योजना नहीं है। (इसके अलावा, आप exFAT / ReFS विभाजन पर Windows सॉफ़्टवेयर क्यों स्थापित कर रहे हैं?)

— कॉनराड

मैं अभी भी गैर-सामान्यीकृत डिवाइस पथ (यानी "\\? \" उपसर्ग) का उपयोग करने के लिए कहता हूं, क्योंकि वे हमेशा उपलब्ध और स्पष्ट हैं। उदाहरण के लिए, अनुवाद करें PATHऔर इसे पास करें SearchPathW। रनटाइम लाइब्रेरी वैसे भी NT के लिए "पथ! \" उपकरण पथ बनाने के बाद से यह कुशल है। नए फाइलसिस्टम के रूप में, हम शायद पोर्टेबल अनुप्रयोगों के अलावा किसी एक्सफ़ैट वॉल्यूम पर स्थापित सॉफ़्टवेयर नहीं देखेंगे, क्योंकि इसकी कोई सुरक्षा नहीं है, लेकिन मैं ReFS को खारिज नहीं करूंगा। उपयोगकर्ता सुविधा, स्थान या प्रदर्शन के कारणों के लिए गैर-मानक स्थानों में कार्यक्रम स्थापित करते हैं।

— एरिक सन

Answer 9

विंडोज पर पथ आकार सीमा का सामना करने के तरीके के रूप में - 7zip को पैक (और अनपैक) का उपयोग करके आपकी पथ-लंबाई संवेदनशील फ़ाइलें एक व्यवहार्य वर्कअराउंड की तरह लगती हैं। मैंने इसका इस्तेमाल कई आईडीई प्रतिष्ठानों (उन ग्रहण प्लगइन पथों, यॉकों!) और ऑटोजेनरेटेड प्रलेखन के ढेर के परिवहन के लिए किया है और अब तक एक भी समस्या नहीं हुई है।

वास्तव में यह निश्चित नहीं है कि यह विंडोज (तकनीकी PoV से) द्वारा निर्धारित 260 char सीमा को कैसे विकसित करता है, लेकिन हे, यह काम करता है!

उनके SourceForge पृष्ठ पर अधिक जानकारी यहाँ :

"NTFS वास्तव में लंबाई में 32,000 वर्णों तक के पथनामों का समर्थन कर सकता है।"

7-ज़िप भी ऐसे लंबे नामों का समर्थन करते हैं।

लेकिन यह SFX कोड में अक्षम है। कुछ उपयोगकर्ता लंबे रास्तों को पसंद नहीं करते हैं, क्योंकि वे यह नहीं समझते कि उनके साथ कैसे काम किया जाए। यही कारण है कि मैंने इसे SFX कोड में अक्षम कर दिया है।

और नोट जारी करें :

9.32 अल्फा 2013-12-01

• 260 से अधिक वर्णों के लिए फ़ाइल पथनाम के लिए बेहतर समर्थन।

4.44 बीटा 2007-01-20

• -जिप अब २६० वर्णों से अधिक लंबे फ़ाइल पथों का समर्थन करता है।

महत्वपूर्ण नोट: इसे ठीक से काम करने के लिए, आपको फ़ाइलों को खींचने और छोड़ने के बजाय सीधे इच्छित फ़ोल्डर में 7zip "एक्सट्रैक्ट" संवाद में गंतव्य पथ निर्दिष्ट करना होगा। अन्यथा "टेंप" फ़ोल्डर का उपयोग अंतरिम कैश के रूप में किया जाएगा और विंडोज एक्सप्लोरर एक बार फाइल को उनके "अंतिम विश्राम स्थान" पर ले जाना शुरू करने पर आपको उन्हीं 260 चार सीमाओं में उछाल देगा। अधिक जानकारी के लिए इस प्रश्न के उत्तर देखें ।

Comments

मैं गलत था, 7zip और WinRAR सभी फ़ोल्डर्स और फ़ाइलों को निकालने। यह सिर्फ इतना है कि विंडोज में एक फ़ोल्डर की संपत्ति केवल फ़ोल्डर और फ़ाइलों की संख्या की रिपोर्ट करती है जो सीमा का उल्लंघन नहीं करती हैं। यह ऐसा है जैसे कि Windows Explorer अधिकतम पथ तक पहुँचने पर फ़ोल्डरों की खोज करने के लिए किसी भी गहरी खुदाई नहीं करता है।

— ट्विस्टेड व्हिस्पर

शिफ्ट-डेल के साथ 7-ज़िप में एक लंबा रास्ता हटाना संभव है ।

— लॉरी स्टर्न

संक्षिप्त उत्तर - .zip फ़ाइल को अनज़िप करने के लिए 7zip का उपयोग करें .... मेरे लिए विंडोज 7 पर काम किया

— andrewcockerham

Answer 10

यह करता है, और यह किसी कारण के लिए डिफ़ॉल्ट है, लेकिन आप इस रजिस्ट्री कुंजी के साथ इसे आसानी से ओवरराइड कर सकते हैं:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem]
"LongPathsEnabled"=dword:00000001

देखें: https://blogs.msdn.microsoft.com/jeremykuhne/2016/07/30/net-4-6-2-and-long-paths-on-windows-10/

Answer 11

इसके साथ सामना करने का एक और तरीका साइग्विन का उपयोग करना है, इस पर निर्भर करता है कि आप फाइलों के साथ क्या करना चाहते हैं (यानी अगर साइगविन आपकी आवश्यकताओं के अनुरूप है)

उदाहरण के लिए यह उन फ़ाइलों को कॉपी करने, स्थानांतरित करने या नाम बदलने की अनुमति देता है, जो कि विंडोज एक्सप्लोरर भी नहीं कर सकता। या निश्चित रूप से उन की सामग्री से निपटें जैसे md5sum, grep, gzip, आदि।

इसके अलावा उन प्रोग्रामों के लिए जिन्हें आप कोडिंग कर रहे हैं, आप उन्हें साइग्विन डीएलएल से जोड़ सकते हैं और यह उन्हें लंबे रास्तों का उपयोग करने में सक्षम करेगा (मैंने हालांकि इसका परीक्षण नहीं किया है)