Dlaczego w systemie Windows istnieje limit długości ścieżki 260 znaków?

Nie jest to ściśle prawdą, ponieważ system plików NTFS obsługuje ścieżki do 32K znaków. Możesz użyć interfejsu API win32 i przedrostka" \\?\", aby użyć ścieżki większej niż 260 znaków.

Kolejnym problemem jest niespójne zachowanie, które spowodowałoby ujawnienie wsparcia dla długich ścieżek. Długie ścieżki z prefiksem \\?\ mogą być używane w większości interfejsy API systemu Windows związane z plikami, ale nie wszystkie. Na przykład LoadLibrary, która mapuje moduł na adres procesu wywołującego, nie powiedzie się, jeśli nazwa pliku jest dłuższa niż MAX_PATH. Oznacza to, że MoveFile pozwoli Ci przenieść bibliotekę DLL do lokalizacji takiej, że jej ścieżka jest dłuższa niż 260 znaków, ale gdy spróbujesz załadować bibliotekę DLL, to się nie powiedzie. Istnieją podobne przykłady w interfejsach API systemu Windows; istnieją pewne obejścia, ale są one ustalane indywidualnie.

Pytanie brzmi Dlaczego czy ograniczenie nadal istnieje. Z pewnością nowoczesne okna mogą zwiększyć Stronę MAX_PATH, aby umożliwić dłuższe ścieżki. Dlaczego ograniczenie nie zostało usunięte?

• powodem, dla którego nie można go usunąć, Jest to, że Windows obiecał, że nigdy się nie zmieni.

Poprzez umowę API System Windows zagwarantował wszystkim aplikacjom, że standardowe API plików nigdy nie zwrócą ścieżki dłuższej niż znaki 260.

Rozważmy następujące poprawny kod:

WIN32_FIND_DATA findData;

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

Windows gwarantuje mój program, że będzie wypełniał moją WIN32_FIND_DATA strukturę:

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

Moja aplikacja nie zadeklarowała wartości stałej MAX_PATH, tylko Windows API. Moja aplikacja użyła tej zdefiniowanej wartości.

Moja struktura jest poprawnie zdefiniowana i przydziela 592 bajty ogółem. Oznacza to, że mogę otrzymać tylko nazwę pliku, która jest mniejsza niż 260 znaków. Windows obiecał mi, że jeśli napiszę moja aplikacja poprawnie, moja aplikacja będzie nadal działać w przyszłości.

Gdyby System Windows zezwalał na nazwy plików dłuższe niż znaki 260, moja istniejąca aplikacja (która poprawnie używała poprawnego API) zawiedzie.

Każdy, kto wzywa Microsoft do zmiany stałej MAX_PATH, musi najpierw upewnić się, że żadna istniejąca aplikacja nie zawiedzie. Na przykład nadal posiadam i używam aplikacji Windows, która została napisana do działania w systemie Windows 3.11. Nadal działa na 64-bitowym Windows 10. To właśnie zapewnia kompatybilność wsteczna.

Microsoft stworzył sposób użycia pełnych 32 768 nazw ścieżek, ale aby to zrobić, musiał utworzyć nowy kontrakt API. Po pierwsze, powinieneś użyć API powłoki do wyliczenia plików (ponieważ nie wszystkie pliki istnieją na dysku twardym lub udziale sieciowym).

Ale nie muszą też niszczyć istniejących aplikacji użytkowników. Zdecydowana większość aplikacji nie używa API powłoki do pracy z plikami. Wszyscy po prostu połączenia FindFirstFile/FindNextFile i koniec z tym.

Z Windows 10. możesz usunąć ograniczenie, modyfikując klucz rejestru.

Wskazówka począwszy od systemu Windows 10, w wersji 1607, ograniczenia MAX_PATH zostały usunięte z popularnych funkcji plików i katalogów Win32. Musisz jednak wyrazić zgodę na nowe zachowanie.

Klucz rejestru pozwala włączyć lub wyłączyć nowe zachowanie długiej ścieżki. Aby włączyć zachowanie długiej ścieżki, Ustaw klucz rejestru na HKLM\SYSTEM\CurrentControlSet\Control\FileSystem LongPathsEnabled (Type: REG_DWORD). Wartość klucza będzie buforowana przez system (na proces) po pierwszym wywołaniu funkcji pliku lub katalogu Win32 (lista poniżej). Klucz rejestru nie zostanie przeładowany w trakcie trwania procesu. Aby wszystkie aplikacje w systemie mogły rozpoznać wartość klucza, konieczne może być ponowne uruchomienie, ponieważ niektóre procesy mogły rozpocząć się przed ustawieniem klucza. Klucz rejestru może być również kontrolowany za pomocą Polityki grupy w Computer Configuration > Administrative Templates > System > Filesystem > Enable NTFS long paths. Możesz również włączyć nowe zachowanie długiej ścieżki dla aplikacji za pomocą "manifest": {]}

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

Możesz zamontować folder jako dysk. Z linii poleceń, jeśli masz ścieżkę C:\path\to\long\folder możesz odwzorować ją na literę X: używając:

subst x: \path\to\long\folder

Jednym ze sposobów radzenia sobie z limitem ścieżek jest skracanie wpisów ścieżek za pomocą dowiązań symbolicznych.

Na przykład:

1. utwórz katalog C:\p, aby zachować krótkie linki do długich ścieżek
2. mklink /J C:\p\foo C:\Some\Crazy\Long\Path\foo
3. dodaj C:\p\foo do swojej ścieżki zamiast długiej ścieżki

Co do Dlaczego to nadal istnieje - MS nie uważa tego za priorytet i ceni kompatybilność wsteczną nad rozwojem ich systemu operacyjnego (przynajmniej w tym przypadku).

Obejściem, którego używam, jest użycie "krótkich nazw" dla katalogów w ścieżce, zamiast ich standardowych, czytelnych dla człowieka wersji. Tak więc np. dla C:\Program Files\ użyłbym C:\PROGRA~1\ można znaleźć odpowiedniki skróconej nazwy używając dir /x.

Jak poradzić sobie z ograniczeniem rozmiaru ścieżki w systemie Windows-użycie 7zip do spakowania (i rozpakowania) wrażliwych plików o długości ścieżki wydaje się realnym obejściem. Użyłem go do transportu kilku instalacji IDE (te ścieżki wtyczki Eclipse, yikes!) i sterty autogenerowanej dokumentacji i do tej pory nie miałem ani jednego problemu.

Nie bardzo wiem, jak to wymyka się limitowi 260 znaków ustawionemu przez Windows( z technicznego PoV), ale hej, to działa!

Więcej szczegółów na ich SourceForge page here :

" NTFS może faktycznie obsługiwać ścieżki do 32 000 znaków w długość."

7-zip obsługuje również takie długie nazwy.

Ale jest wyłączony w kodzie SFX. Niektórzy użytkownicy nie lubią długich ścieżek, ponieważ nie rozumieją, jak z nimi pracować. Dlatego mam wyłączony w kodzie SFX.

I uwagi do wydania :

9.32 Alfa 2013-12-01

• Ulepszone wsparcie dla nazwy plików dłuższe niż 260 znaków.

4.44 beta 2007-01-20

• 7-Zip obsługuje teraz ścieżki plików dłuższe niż 260 znaków.

WAŻNA UWAGA: aby to działało poprawnie, musisz określić ścieżkę docelową w oknie dialogowym 7zip "Rozpakuj" bezpośrednio, zamiast przeciągać i upuszczać pliki do docelowego folderu. W przeciwnym razie folder "Temp" zostanie użyty jako tymczasowy bufor i będziesz odbijać w tym samym ograniczeniu znaków 260, gdy Eksplorator Windows zacznie przenosić pliki do "ostatecznego miejsca spoczynku". Zobacz odpowiedzi na to pytanie aby uzyskać więcej informacji.

Innym sposobem radzenia sobie z tym jest użycie Cygwina, w zależności od tego, co chcesz zrobić z plikami (np. jeśli polecenia Cygwin odpowiadają twoim potrzebom)

Na przykład pozwala kopiować, przenosić lub zmieniać nazwy plików, których nie potrafi nawet Eksplorator Windows. lub oczywiście zajmować się ich zawartością jak md5sum, grep, gzip, itp.

Również dla programów, które kodujesz, możesz połączyć je z biblioteką Cygwin DLL i umożliwi to im korzystanie z długich ścieżek (nie testowałem tego jednak)

Działa i z jakiegoś powodu jest domyślna, ale możesz ją łatwo zastąpić tym kluczem rejestru:

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

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

Możesz włączyć długie nazwy ścieżek używając PowerShell:

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

Inna wersja to użycie Polityki grupy w Computer Configuration/Administrative Templates/System/Filesystem:

Podczas gdy wszyscy płaczą, że 260 znaków jest okropnych w 2017 roku, jakoś nikt nie płacze, że większość GNU psuje się, jeśli napotyka spacje w ścieżkach. Nawet unicode. A propos funkcji z natury zepsutych-pomyśl o swoim ulubionym strcpy Bez n. Nawet malloc jest zepsute na Linuksie, ponieważ polega na błędach strony, aby faktycznie zatwierdzić zarezerwowaną przestrzeń adresową (która jest powolna i podatna na błędy). Nikt nie jest doskonały, a ignorancja nie jest ważnym powodem do marudzenia.

Komentatorzy jakoś nie mów, co dokładnie jest zepsute.

Są 3 rzeczy, które są zepsute:

• Niektóre wywołania (wiem tylko o Get/SetCurrentDirectoryW) są ograniczone do pojedynczego wątku i 260 znaków bez względu na wszystko. Tak więc zasadniczo ścieżki względne są łamane w systemie Windows, Emuluj je tak, jak emulujesz fork, jeśli jesteś do tego zmuszony.

• Oprogramowanie przeniesione z nie-windows, które z natury opiera się na pojęciach nie-windows (w tym koncepcji bieżącego dir / ścieżki względne, patrz wyżej)

• Oprogramowanie, które jest napisane od podstaw dla systemu Windows, ale nadal używa starożytnego API (patrz wyżej - chociaż istnieją API dla ogólnego dostępu do systemu plików, nie ma API dla bieżącego katalogu w systemie Windows, który działa po MAX_PATH)

Co do tego, dlaczego nadal jest zepsuty - moim zdaniem MS naprawił wszystko, co da się naprawić. Myślę, że to dziedziczenie bieżącego katalogu przez procesy potomne nie pozwala GetCurrentDirectoryW do być naprawione.