ทำไมขีดจำกัดความยาวของเส้นทางอักขระ 260 ตัวใน Windows

390

ฉันได้เจอปัญหานี้สองสามครั้งในช่วงเวลาที่ไม่เหมาะสม:

  • พยายามทำงานกับโปรเจ็กต์ Java แบบโอเพนซอร์สที่มีพา ธ ลึก
  • การจัดเก็บต้นวิกิ Fitnesse ที่ลึกลงไปในแหล่งควบคุม
  • มีข้อผิดพลาดในการพยายามใช้ Bazaar เพื่อนำเข้าแผนภูมิการควบคุมแหล่งที่มาของฉัน

ทำไมขีด จำกัด นี้ถึงมีอยู่?

ทำไมมันยังไม่ถูกลบ?

คุณรับมือกับขีด จำกัด เส้นทางได้อย่างไร และไม่การเปลี่ยนเป็น Linux หรือ Mac OS X ไม่ใช่คำตอบที่ถูกต้องสำหรับคำถามนี้;)

windows  path  limit 
— Jeffrey Cameron
แหล่งที่มา
8
@Artelius: จริง ๆ แล้ว Windows (อย่างน้อยจาก Win2K เป็นต้นไป) รองรับจุดเชื่อมต่อ ( en.wikipedia.org/wiki/NTFS_junction_point ) และ Vista เป็นต้นไปสนับสนุนการเชื่อมโยงสัญลักษณ์ NT ( en.wikipedia.org/wiki/NTFS_symbolic_link ) อย่างไรก็ตามในขณะที่ symlinks สามารถช่วยให้เส้นทางที่ยาวขึ้น / ซ้อนกันเป็นมิตรมากขึ้นฉันไม่สามารถคิดได้ว่า symlinks จะช่วยคุณได้อย่างไรหากคุณกดขีดจำกัดความยาวของเส้นทาง
— Ashutosh Mehra
8
แม้ว่าขีด จำกัด นี้จะไม่มีอยู่จริง แต่ก็มีข้อ จำกัด อื่น ๆ อีกมากมายและทุก ๆ ข้ออาจน่ารำคาญในบางจุด ประเด็นคือทำไมขีด จำกัด นี้ต่ำมาก หลังจากยุคของ 8.3 และด้วยฮาร์ดแวร์ขนาด mega / giga ตอนนี้เส้นทางควรเป็นสตริงที่จัดสรรแบบไดนามิกที่มีขนาดไม่ จำกัด อย่างแท้จริง
— Roland
12
Microsoft กำลังจัดการปัญหานี้ใน Windows 10 Build 14352 ในที่สุด
— Warren P
3
ใช่และดูเหมือนว่าคุณจะต้องแก้ไขรายการแอปเพื่อให้ทราบเส้นทางได้นาน
— Warren P
3
@PatrickSzalapski โชคร้ายที่มันได้รับการแก้ไขvisualstudio.uservoice.com/forums/121579-visual-studio/...
— phuclv

คำตอบ:

231

การอ้างถึงบทความนี้https://docs.microsoft.com/en-us/windows/desktop/FileIO/naming-a-file#maximum-path-length-limitation

ข้อจำกัดความยาวเส้นทางสูงสุด

ใน Windows API (โดยมีข้อยกเว้นบางอย่างที่กล่าวถึงในย่อหน้าต่อไปนี้) ความยาวสูงสุดสำหรับพา ธ คือMAX_PATHซึ่งกำหนดเป็น 260 ตัวอักษร เส้นทางโลคัลถูกจัดโครงสร้างตามลำดับต่อไปนี้: ตัวอักษรชื่อไดรฟ์เครื่องหมายแบ็กสแลชคอมโพเนนต์ชื่อคั่นด้วยเครื่องหมายแบ็กสแลชและอักขระโมฆะสิ้นสุด ตัวอย่างเช่นพา ธ สูงสุดในไดรฟ์ D คือ "D: \ สตริงอักขระพา ธ 256 ตัวอักษร <NUL>" โดยที่ "<NUL>" แสดงถึงอักขระ null สิ้นสุดที่มองไม่เห็นสำหรับเพจรหัสระบบปัจจุบัน (อักขระ <> ใช้ที่นี่เพื่อความชัดเจนที่มองเห็นและไม่สามารถเป็นส่วนหนึ่งของสตริงพา ธ ที่ถูกต้อง)

ตอนนี้เราเห็นแล้วว่ามันคือ 1 + 2 + 256 + 1 หรือ [drive] [: \] [path] [null] = 260. หนึ่งอาจสันนิษฐานได้ว่า 256 เป็นความยาวสตริงคงที่ที่สมเหตุสมผลจาก DOS วัน และกลับไปที่ DOS APIs เราทราบว่าระบบติดตามเส้นทางปัจจุบันต่อไดรฟ์และเรามีไดรฟ์สูงสุด 26 (32 พร้อมสัญลักษณ์) สูงสุด (และไดเรกทอรีปัจจุบัน)

INT 0x21 AH = 0x47 บอกว่า“ ฟังก์ชั่นนี้จะคืนค่าคำอธิบายพา ธ โดยไม่มีอักษรระบุไดรฟ์และแบ็กสแลชเริ่มต้น” ดังนั้นเราจะเห็นว่าระบบจัดเก็บ CWD เป็นคู่ (ไดรฟ์เส้นทาง) และคุณขอเส้นทางโดยระบุไดรฟ์ (1 = A, 2 = B, …) ถ้าคุณระบุ 0 มันจะถือว่าเป็นเส้นทางสำหรับ ไดรฟ์ส่งคืนโดย INT 0x21 AH = 0x15 AL = 0x19 ตอนนี้เรารู้แล้วว่าทำไมมันถึง 260 ไม่ใช่ 256 เพราะ 4 ไบต์เหล่านั้นไม่ได้ถูกจัดเก็บไว้ในสตริงพา ธ

ทำไมสตริงพา ธ 256 ไบต์เนื่องจาก 640K เพียงพอสำหรับ RAM

— Valli
แหล่งที่มา
21
Windows API จำกัดความยาวแม้ในระบบปฏิบัติการล่าสุด Microsoft กลัวที่จะทำลายระบบปฏิบัติการหลายร้อยล้านที่ใช้กันทุกวันนี้หากนี่เป็นการเปลี่ยนแปลงเพราะพวกเขาไม่มีอัจฉริยะทำงานให้พวกเขาอีกต่อไปที่เข้าใจ API ทั้งในและนอกเหมือนกับที่พวกเขาทำในช่วงปี 1980 และ 1990 ความเสี่ยงนั้นไม่คุ้มที่จะเปลี่ยนแปลง serverfault.com/questions/163419/…
— MacGyver
77
@ MacGyver ขออภัย แต่นั่นไร้สาระที่สุด Microsoft ไม่ต้องการแบ่งแอปพลิเคชั่นที่เขียนไม่ดีออกเป็นล้าน ๆ ใบซึ่งถือว่าสิ่งต่าง ๆ เกี่ยวกับระบบที่ไม่เคยรับประกัน น่าเสียดายที่สิ่งต่าง ๆ เป็นไปในลักษณะเดียวกันมานานแล้วที่นักพัฒนาต้องพึ่งพาพวกเขาดังนั้นการเปลี่ยนแปลงในตอนนี้จะทำให้แอปพลิเคชันของบุคคลที่สามเสียหายและ MS จะได้รับโทษ
— พื้นฐาน
25
btw ไม่มีข้อพิสูจน์ว่า Gates เคยพูดว่า "640K Ram นั้นเพียงพอสำหรับทุกคน" computerworld.com/article/2534312
— Patrick Favre
11
@Basic การจำกัดความยาวของอักขระ 260 ตัวถูกรับรองโดย Windows ค่าคงที่ถูกประกาศเป็นค่าคงที่มีการประกาศโครงสร้างในไฟล์ส่วนหัวของ Windows ที่มีที่ว่างเพียง 260 ตัวอักษร ไม่มีวิธีการเปลี่ยนแปลง
— Ian Boyd
35
@Basic ค่าคงที่ไม่เปลี่ยนแปลงเมื่อคอมไพล์ในแอปพลิเคชันของฉัน ฉันใช้งานแอพพลิเคชั่นที่สร้างขึ้นครั้งสุดท้ายในปี 1994 และยังคงทำงานได้ในวันนี้ใน Windows 10 Microsoft สัญญากับไบนารีขนาดหนึ่งของบล็อกหน่วยความจำและโปรแกรมเมอร์ทำตามกฎนั้น หาก Microsoft ต้องเปลี่ยนค่าคงที่ดังนั้นแอปพลิเคชันที่มีอยู่ทุกคนที่ติดตามการเขียนโปรแกรม API อย่างถูกต้องจะใช้งานไม่ได้ คุณไม่สามารถทำลายความเข้ากันได้ของไบนารี
— เอียนบอยด์
150

สิ่งนี้ไม่เป็นความจริงอย่างแน่นอนเนื่องจากระบบไฟล์ NTFS รองรับพา ธ ที่มีความยาวสูงสุด 32k อักขระ คุณสามารถใช้ win32 api และ " \\?\" นำหน้าเส้นทางเพื่อใช้อักขระมากกว่า 260 ตัว

คำอธิบายรายละเอียดของเส้นทางยาวจากสุทธิบล็อกของทีม BCL
ส่วนที่ตัดตอนมาเล็ก ๆ ไฮไลท์ปัญหาด้วยเส้นทางยาว

ข้อกังวลอีกประการคือพฤติกรรมที่ไม่สอดคล้องซึ่งอาจเกิดขึ้นจากการเปิดเผยการสนับสนุนเส้นทางที่ยาว เส้นทางที่ยาวพร้อม\\?\คำนำหน้าสามารถใช้ใน Windows APIs ที่เกี่ยวข้องกับไฟล์ส่วนใหญ่ แต่ไม่ใช่ Windows APIs ทั้งหมด ตัวอย่างเช่น LoadLibrary ซึ่งแมปโมดูลเข้ากับที่อยู่ของกระบวนการเรียกใช้ล้มเหลวหากชื่อไฟล์ยาวกว่า MAX_PATH ดังนั้นนี่หมายความว่า MoveFile จะช่วยให้คุณย้าย DLL ไปยังตำแหน่งที่มีเส้นทางยาวกว่า 260 ตัวอักษร แต่เมื่อคุณพยายามโหลด DLL มันจะล้มเหลว มีตัวอย่างที่คล้ายกันทั่วทั้ง Windows APIs; วิธีแก้ไขปัญหาบางอย่างมีอยู่ แต่จะเป็นกรณี ๆ ไป

— softveda
แหล่งที่มา
4
ยุติธรรมเพียงพอ แต่หมายความว่าคุณต้องใช้ P / Invoke ในหลาย ๆ ที่และสิ่งนี้ในใจของฉันช่วยลดความสะดวกในการพกพาของรหัส. Net ของคุณ ถ้าฉันต้องการรักษาความเข้ากันได้ของโมโน
— Jeffrey Cameron
1
ประเด็นของฉันคือคุณสามารถใช้เส้นทางยาวหากคุณต้องการจริงๆ แต่ฉันยอมรับว่ามันเป็นความเจ็บปวดและโดยส่วนตัวฉันจะหลีกเลี่ยงปัญหานี้เช่นกัน
— softveda
5
นี่ควรเป็นคำตอบที่เลือก ตอบคำถามที่ผู้ใช้โพสต์จริง ๆ แล้วเหตุใดจึงมีข้อ จำกัด นี้และให้การแก้ไข
— โหวตขึ้นจาก
2
ฟังดูแล้วว่า Microsoft จำเป็นต้องแก้ไข API ของพวกเขาและฉันคิดว่านี่ไม่ใช่ลำดับความสำคัญ ฉันรู้สึกประหลาดใจว่าขีด จำกัด นี้ยังคงมีอยู่ใน Windows 8
— Mas
3
@Mas "แก้ไข" ที่คุณต้องการทำเสร็จแล้วกลับไปเป็น Windows XP การเรียกใช้เวอร์ชัน unicode ของ API จะทำให้คุณสามารถเข้าถึง "เส้นทางที่ขยาย" ฉันเชื่อว่า explorer จะจัดการสิ่งนี้โดยอัตโนมัติ นี่คือหนึ่งในฟังก์ชั่นดังกล่าวที่สนับสนุนมัน - msdn.microsoft.com/en-us/library/windows/desktop/...
— Natalie Adams
108

คำถามคือทำไมข้อ จำกัด ยังคงมีอยู่ Windows ที่ทันสมัยอย่างแท้จริงสามารถเพิ่มด้านของMAX_PATHการอนุญาตเส้นทางที่ยาวขึ้น ทำไมข้อ จำกัด จึงไม่ถูกลบออก?

  • เหตุผลที่ไม่สามารถลบได้คือ Windows สัญญาว่าจะไม่เปลี่ยนแปลง

ด้วยสัญญา API, Windows รับประกันแอปพลิเคชันทั้งหมดว่า API ไฟล์มาตรฐานจะไม่ส่งคืนพา ธ ที่ยาวกว่า260อักขระ

พิจารณารหัสที่ถูกต้องต่อไปนี้:

WIN32_FIND_DATA findData;

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

Windows รับประกันโปรแกรมของฉันว่าจะเติมWIN32_FIND_DATAโครงสร้างของฉัน:

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

แอปพลิเคชันของฉันไม่ได้ประกาศค่าคงที่MAX_PATHซึ่ง Windows API ทำได้ แอปพลิเคชันของฉันใช้ค่าที่กำหนดไว้

โครงสร้างของฉันถูกกำหนดอย่างถูกต้องและจัดสรร592ผลรวมไบต์เท่านั้น นั่นหมายความว่าฉันสามารถรับชื่อไฟล์ที่น้อยกว่า260ตัวอักษรเท่านั้น Windows สัญญากับฉันว่าถ้าฉันเขียนแอปพลิเคชันของฉันถูกต้องแอปพลิเคชันของฉันจะยังคงทำงานต่อไปในอนาคต

หาก Windows อนุญาตให้มีชื่อไฟล์ยาวกว่า260ตัวอักษรดังนั้นแอปพลิเคชันที่มีอยู่ของฉัน (ซึ่งใช้ API ที่ถูกต้องอย่างถูกต้อง) จะล้มเหลว

สำหรับใครก็ตามที่เรียกร้องให้ Microsoft เปลี่ยนMAX_PATHค่าคงที่พวกเขาต้องแน่ใจก่อนว่าไม่มีแอปพลิเคชันที่มีอยู่ล้มเหลว ตัวอย่างเช่นฉันยังเป็นเจ้าของและใช้แอปพลิเคชัน Windows ที่เขียนขึ้นเพื่อใช้งานบน Windows 3.11 มันยังทำงานบน Windows 64 บิต 64 นั่นคือสิ่งที่เข้ากันได้กับคุณ

Microsoft ได้สร้างวิธีการใช้ชื่อพา ธ แบบเต็ม 32,768 ชื่อ แต่พวกเขาต้องสร้างสัญญา API ใหม่เพื่อทำ สำหรับหนึ่งคุณควรใช้Shell APIเพื่อระบุไฟล์ (เนื่องจากไม่มีไฟล์ทั้งหมดที่มีอยู่ในฮาร์ดไดรฟ์หรือเครือข่ายที่ใช้ร่วมกัน)

แต่พวกเขายังต้องไม่ทำลายแอปพลิเคชันผู้ใช้ที่มีอยู่ แอปพลิเคชั่นส่วนใหญ่ไม่ได้ใช้ shell api สำหรับงานไฟล์ ทุกคนแค่โทรFindFirstFile/ FindNextFileและเรียกมันต่อวัน

— Ian Boyd
แหล่งที่มา
4
@JosiahKeller ถ้าเป็นเช่นนั้นก็จะผิดสัญญาที่กำหนดไว้สำหรับวิธีการนั้น แต่เดิมและการทำเช่นนั้นสามารถเขียนทับหน่วยความจำที่ไม่ได้ตั้งใจและเปิดช่องโหว่ด้านความปลอดภัย วิธีเดียวในการแก้ไขปัญหานี้คือการนำเสนอ API ที่ได้รับการปรับปรุงใหม่ (เช่นชุดการรับรู้ของ Unicode) และหวังว่าทุกคนจะคอมไพล์ซ้ำ / รีโหลดแอปพลิเคชันทั้งหมดโดยใช้ API ที่ใหม่กว่า
— Rowland Shaw
2
@Ryios ฉันไม่คิดว่าแอพพลิเคชัน Windows ที่มีอยู่ของฉันจะทำงานบน Linux
— เอียนบอยด์
9
ความเข้ากันได้ย้อนหลังเป็นสิ่งที่ดี แต่วันนี้ฉันคิดว่าการหลีกเลี่ยงปัญหา (บ่อยครั้งน่ารังเกียจจริงๆ) มีความสำคัญมากกว่าการรองรับแอปพลิเคชัน Windows 3.1 มีกี่คนที่พบปัญหาเกี่ยวกับเส้นทางยาว? และมีคนกี่คนที่ยังใช้แอปพลิเคชัน Windows 3.1 อยู่ พวกเขายังยกเลิกการรองรับ Windows XP เหตุใดพวกเขาจึงไม่เพียงแค่ทำการประกาศว่าจาก Windows [x] และแอปพลิเคชันในภายหลังซึ่งสมมติว่าจะไม่มีเส้นทางยาวเกิน 260 ตัวอักษรจะไม่ทำงานตามที่คาดไว้เมื่อพวกเขาพบเส้นทางที่ยาว? การ จำกัด ความเร็วของเรายังไม่คำนึงถึงรถม้า
— JuSchu
2
@JuSchu ไม่ใช่แค่แอปพลิเคชั่น Windows 3.1 แอปพลิเคชันที่เขียนวันนี้โดยใช้ API ที่ถูกต้องจะไม่ทำงาน
— Ian Boyd
2
@TheincredibleJan MSDN เอกสารสัญญาสร้างซึ่งเป็นเหตุผลที่คุณจะต้องระมัดระวังเป็นอย่างมากสิ่งที่คุณทำเอกสาร
— Ian Boyd
62

จาก Windows 10. คุณสามารถลบข้อ จำกัด ได้ด้วยการแก้ไขรีจิสตรีคีย์

เคล็ดลับการ เริ่มต้นใน Windows 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>
— Root Root
แหล่งที่มา
15
น่าเศร้าแม้ใน Win10 เวอร์ชันล่าสุดตัว File Explorer เองยังคงมีปัญหาในการจัดการกับชื่อพา ธ แบบยาว แม้กระทั่ง "คัดลอกเป็นเส้นทาง" ในเมนูบริบทไม่ทำงานอย่างที่คาดไว้ คัดลอก 260 ตัวอักษรแรกเท่านั้น คุณไม่สามารถสร้างโฟลเดอร์คัดลอก / ย้าย / เปิดไฟล์ ... ทำให้ฉันสงสัยว่าอะไรคือจุดเปลี่ยนแปลงนี้
— raymai97
โปรดทราบว่าการอ้างสิทธิ์ว่าการตั้งค่าระบบเป็นอิสระจากการตั้งค่ารายการไม่ถูกต้อง จำเป็นต้องใช้ทั้งคู่ ต้องเปิดใช้งานนโยบายในระดับระบบและรายการจะต้องประกาศว่าแอปพลิเคชันนั้นต้องทราบเส้นทางที่ยาว
— Eryk Sun
ฉันอ่านว่าการเปลี่ยนแปลงนี้อาจทำให้เกิดปัญหาความเข้ากันได้กับแอปพลิเคชันรุ่น 32 บิตที่เก่ากว่า แต่เป็นปัญหาประเภทนี้ที่เกิดจากความเข้ากันได้ทั่วไปหรือไม่ ฉันต้องการเปลี่ยนแปลงตัวเอง lifehacker.com/…
— KDP
32

คุณสามารถต่อเชื่อมโฟลเดอร์เป็นไดรฟ์ จากบรรทัดคำสั่งหากคุณมีเส้นทางC:\path\to\long\folderคุณสามารถแมปกับไดรฟ์ตัวอักษรX:โดยใช้:

subst x: \path\to\long\folder
— jonchang
แหล่งที่มา
ฉันได้รับ "พารามิเตอร์ตัว j ไม่ถูกต้อง" เมื่อพยายามคำสั่งนี้
— barrypicker
จำเป็นต้องเรียกใช้จากพรอมต์คำสั่งผู้ดูแลระบบ (ระดับสูง)
— Mrchief
สิ่งนี้จะล้มเหลวด้วยเครื่องหมายสแลชต้องเป็นแบ็กสแลช
— cchamberlain
1
ฉันไม่แน่ใจว่าสิ่งนี้ใช้ได้กับ windows 10 เท่านั้น แต่ฉันเพิ่งพบว่าเมื่อพยายามเรียกใช้คำสั่งนี้หากฉันเรียกใช้ในฐานะผู้ดูแลระบบตามคำแนะนำด้านบนไดรฟ์จะไม่ปรากฏให้ใช้งาน นี่เป็นเพราะพฤติกรรมดูเหมือนจะคล้ายกับการแมปไดรฟ์เครือข่ายและเป็นช่วงที่เฉพาะเจาะจง ฯลฯ ดังนั้นเมื่อฉันวิ่งเป็นผู้ดูแลระบบและใช้คำสั่งนี้เซสชันนั้นอาจใช้ x: TL; DR ถ้าคุณไม่เห็นไดรฟ์ลอง เรียกใช้คำสั่งโดยไม่อยู่ในโหมดผู้ดูแลระบบ
— Jaddie
substเป็นเซสชั่นท้องถิ่น / บัญชี - ดูsuperuser.com/questions/29072/…สำหรับวิธีการทำให้เป็น 'ทั้งระบบ'
— 2864740
18

วิธีหนึ่งในการจัดการกับขีด จำกัด พา ธ คือการย่อรายการพา ธ ด้วยลิงก์สัญลักษณ์

ตัวอย่างเช่น:

  1. สร้างC:\pไดเรกทอรีเพื่อให้ลิงก์สั้น ๆ ไปยังเส้นทางยาว
  2. mklink /J C:\p\foo C:\Some\Crazy\Long\Path\foo
  3. เพิ่มC:\p\fooเส้นทางของคุณแทนเส้นทางยาว
— JDiMatteo
แหล่งที่มา
3
ไม่จำเป็นต้องสร้างไดเรกทอรีก่อนดังนั้นขั้นตอนที่ 1 จึงไม่จำเป็น
— ohaal
2
เคล็ดลับนี้ใช้ไม่ได้กับแอปพลิเคชั่นจำนวนมากที่พยายามแก้ไขลิงก์
— nponeccop
/jตัวเลือกสร้างจุดเชื่อมทางแยกสำหรับอุปกรณ์ปริมาณท้องถิ่นหรือเส้นทางบนไดรฟ์ในท้องถิ่น (เช่น Unix ผูกติด) มันไม่ได้สร้างลิงค์สัญลักษณ์ มันเป็นความแตกต่างที่สำคัญเนื่องจากจุดเชื่อมต่อจะถูกประเมินบนเซิร์ฟเวอร์เสมอและต้องกำหนดเป้าหมายอุปกรณ์ภายในเครื่องในขณะที่ลิงก์สัญลักษณ์จะถูกประเมินบนไคลเอนต์และอาจกำหนดเป้าหมายเส้นทางระยะไกล (หากได้รับอนุญาตจากนโยบาย) เช่นเดียวกับไดรฟ์ subst.exe (เช่นDefineDosDeviceW) โดยทั่วไปเป้าหมายการเชื่อมต่อจะถูก จำกัด ไว้ที่ประมาณ 4K อักขระ จริงๆแล้วมันเป็นอักขระ 8K แยกจากกันระหว่างพา ธ สำรองกับพา ธ การแสดงผลเท่า ๆ กัน
— Eryk Sun
12

คุณสามารถเปิดใช้งานชื่อพา ธ แบบยาวโดยใช้ PowerShell: 

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

รุ่นอื่นคือการใช้นโยบายกลุ่มในComputer Configuration/ Administrative Templates/ System/ Filesystem:

ตัวแก้ไขนโยบายกลุ่ม

— MovGP0
แหล่งที่มา
2
แต่ละแอปพลิเคชันยังคงมีการประกาศว่ามันเป็นเส้นทางยาวตระหนัก Microsoft ทำงานที่ไม่ดีในการสื่อสารโดยทำให้ดูเหมือนว่าแอปพลิเคชันรายการเป็นอีกวิธีหนึ่งในการเปิดใช้งานคุณลักษณะนี้แทนที่จะอธิบายอย่างชัดเจนว่าเป็นสัญญาระหว่าง OS (นโยบายระดับระบบ) และแอปพลิเคชันที่ทั้งสองต้องยอมรับ
— Eryk Sun
8

ในฐานะที่เป็นเหตุผลที่นี้ยังคงมีอยู่ - MS ไม่ได้คิดว่ามันมีความสำคัญและคุณค่าหลังเข้ากันได้มากกว่าความก้าวหน้าของระบบปฏิบัติการของพวกเขา (อย่างน้อยในกรณีนี้)

วิธีแก้ปัญหาที่ฉันใช้คือใช้ "ชื่อย่อ" สำหรับไดเรกทอรีในเส้นทางแทนที่จะเป็นรุ่นมาตรฐานที่มนุษย์อ่านได้ ดังนั้นเช่นสำหรับC:\Program Files\ผมจะใช้คุณสามารถค้นหาเทียบเท่าชื่อสั้นใช้C:\PROGRA~1\ dir /x

— คอนราด
แหล่งที่มา
1
ชื่อเส้นทางแบบสั้นสามารถปิดการใช้งานในรีจิสทรี (หรือเป็นระบบไฟล์เอง) ดังนั้นนี่จึงไม่ใช่วิธีแก้ปัญหาที่เชื่อถือได้
— rubenvb
3
@rubenvb ฉันแน่ใจว่าส่วนใหญ่ถ้าไม่สามารถปิดใช้งานคุณลักษณะ Windows ทั้งหมดในรีจิสทรีดังนั้น¯ \ _ (ツ) _ / ¯
— Conrad
การสร้างชื่อย่อสามารถปิดการใช้งานสำหรับ NTFS (และควรเป็นเพราะมันไม่มีประสิทธิภาพในหลายกรณี) ไม่ว่าจะเป็นทั้งระบบหรือต่อปริมาณจึงเป็นวิธีการที่ไม่น่าเชื่อถือแม้กระทั่งเส้นทางบนไดรฟ์ระบบซึ่งต้องเป็น NTFS เป็นไปได้ที่จะตั้งชื่อย่อแบบแมนนวลในไฟล์และไดเรกทอรีใน NTFS แต่สิ่งนี้จะไม่ขยายไปถึงระบบไฟล์ที่ใหม่กว่าซึ่งไม่สนับสนุนชื่อแบบสั้นเลยเช่น exFAT และ ReFS ชื่อแบบสั้นควรได้รับการพิจารณาว่าเป็นคุณสมบัติที่ไม่รองรับซึ่งยังคงใช้งานร่วมกันได้ในกรณีที่ จำกัด เช่น ANSI / OEM API เก่าโดยใช้โค้ดเพจเดี่ยวและไบต์คู่
— Eryk Sun
@eryksun โปรดดูความคิดเห็นก่อนหน้าของฉันเกี่ยวกับการปิดใช้งานชื่อเส้นทางสั้น ๆ :) เพียงเพราะคุณคิดว่าควรถือว่าเลิกใช้แล้วไม่ได้หมายความว่าจริง ๆ แล้วคือ MS ไม่มีแผนที่จะเลิกใช้งานฟีเจอร์นี้ (นอกจากนี้ทำไมคุณถึงติดตั้งซอฟต์แวร์ Windows บน exFAT / ReFS พาร์ติชั่น)
— Conrad
ฉันยังคงบอกว่าจะใช้เส้นทางอุปกรณ์ที่ไม่ได้มาตรฐาน (เช่นคำนำหน้า "\\? \") เนื่องจากพวกมันพร้อมใช้งานและชัดเจนอยู่เสมอ ยกตัวอย่างเช่นแปลและผ่านมันไปPATH SearchPathWมีประสิทธิภาพเช่นกันเนื่องจากไลบรารีรันไทม์สร้างเส้นทางอุปกรณ์ "\\? \" สำหรับ NT สำหรับระบบไฟล์ที่ใหม่กว่าเราอาจจะไม่เห็นซอฟต์แวร์ที่ติดตั้งในปริมาณ exFAT นอกเหนือจากแอปพลิเคชั่นแบบพกพาเนื่องจากไม่มีความปลอดภัย แต่ฉันจะไม่ออกกฎ ReFS ผู้ใช้ติดตั้งโปรแกรมในสถานที่ที่ไม่ได้มาตรฐานเพื่อความสะดวกพื้นที่หรือประสิทธิภาพ
— Eryk Sun
7

วิธีจัดการกับข้อ จำกัด ขนาดพา ธ บน Windows - การใช้7zipเพื่อแพ็ค (และคลายไฟล์) ไฟล์ที่มีความยาวพา ธ ของคุณดูเหมือนจะเป็นวิธีแก้ปัญหา ฉันใช้มันเพื่อขนส่งการติดตั้ง IDE หลายรายการ (เส้นทางปลั๊กอิน Eclipse, yikes!) และกองเอกสารที่สร้างอัตโนมัติและไม่เคยมีปัญหาเดียวจนถึงตอนนี้

ไม่แน่ใจจริงๆว่ามันจะ จำกัด จำนวนถ่าน 260 ตัวที่ Windows ตั้งไว้ (จาก PoV ทางเทคนิค) ได้อย่างไร แต่ก็ใช้งานได้!

รายละเอียดเพิ่มเติมเกี่ยวกับหน้า SourceForge ได้ที่นี่ :

"NTFS สามารถรองรับชื่อพา ธ ได้สูงสุด 32,000 ตัวอักษร"

7-zip ยังรองรับชื่อยาว ๆ

แต่มันถูกปิดการใช้งานในรหัส SFX ผู้ใช้บางคนไม่ชอบเส้นทางยาวเนื่องจากพวกเขาไม่เข้าใจวิธีการทำงานกับพวกเขา นั่นคือเหตุผลที่ฉันปิดใช้งานในรหัส SFX

และบันทึกประจำรุ่น :

9.32 อัลฟา 2013-12-01

  • ปรับปรุงการรองรับชื่อพา ธ ของไฟล์ที่ยาวเกิน 260 ตัวอักษร

เบต้า 4.44 2007-01-20

  • 7-Zip รองรับชื่อพา ธ ไฟล์ที่ยาวเกิน 260 ตัวอักษร

หมายเหตุสำคัญ:เพื่อให้ทำงานได้อย่างถูกต้องคุณจะต้องระบุเส้นทางปลายทางในกล่องโต้ตอบ "แยก" 7zipโดยตรงแทนที่จะลากและวางไฟล์ลงในโฟลเดอร์ที่ต้องการ ไม่เช่นนั้นโฟลเดอร์ "Temp" จะถูกใช้เป็นแคชชั่วคราวและคุณจะเด้งกลับไปในข้อ จำกัด char 260 เหมือนเดิมเมื่อ Windows Explorer เริ่มย้ายไฟล์ไปยัง "ที่พักสุดท้าย" ดูคำตอบของคำถามนี้สำหรับข้อมูลเพิ่มเติม

— Priidu Neemre
แหล่งที่มา
3
ฉันผิด 7zip และ WinRAR ทำการแยกโฟลเดอร์และไฟล์ทั้งหมด เป็นเพียงคุณสมบัติของโฟลเดอร์ใน Windows เท่านั้นที่รายงานจำนวนโฟลเดอร์และไฟล์ที่ไม่ละเมิดข้อ จำกัด ราวกับว่า Windows Explorer ไม่ขุดลึกลงไปอีกเพื่อค้นหาโฟลเดอร์เมื่อถึงเส้นทางสูงสุด
— Twisted Whisper
เป็นไปได้ที่จะลบเส้นทางยาวใน 7-zip ด้วย shift-del
— Laurie Stearn
คำตอบสั้น ๆ - ใช้ 7zip เพื่อคลายซิปไฟล์. zip .... ทำงานให้ฉันบน Windows 7
— andrewcockerham
5

มันทำและมันเป็นค่าเริ่มต้นด้วยเหตุผลบางอย่าง แต่คุณสามารถแทนที่มันได้อย่างง่ายดายด้วยคีย์รีจิสทรีนี้:

[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/

— Sergey Dryganets
แหล่งที่มา
2

อีกวิธีในการรับมือกับมันคือการใช้ Cygwin ขึ้นอยู่กับสิ่งที่คุณต้องการจะทำกับไฟล์ (เช่นถ้าคำสั่ง Cygwin เหมาะสมกับความต้องการของคุณ)

ตัวอย่างเช่นช่วยให้สามารถคัดลอกย้ายหรือเปลี่ยนชื่อไฟล์ที่แม้แต่ Windows Explorer ก็ไม่สามารถทำได้ หรือแน่นอนจัดการกับเนื้อหาของพวกเขาเช่น md5sum, grep, gzip ฯลฯ

นอกจากนี้สำหรับโปรแกรมที่คุณกำลังเขียนโค้ดคุณสามารถลิงก์ไปยัง Cygwin DLL และมันจะทำให้พวกเขาใช้เส้นทางที่ยาว (ฉันยังไม่ได้ทดสอบสิ่งนี้)

— eliblanco87
แหล่งที่มา
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.