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

Kilka razy spotkałem się z tym problemem w nieodpowiednich momentach:

• Próbowanie pracy nad projektami Java typu open source z głębokimi ścieżkami
• Przechowywanie głębokich drzew wiki Fitnesse pod kontrolą źródła
• Błąd podczas próby użycia Bazaar do importowania mojego drzewa kontroli źródła

Dlaczego ten limit istnieje?

Dlaczego nie został jeszcze usunięty?

Jak radzisz sobie z ograniczeniem ścieżki? I nie, przejście na system Linux lub Mac OS X nie jest prawidłową odpowiedzią na to pytanie;)

Cytując ten artykuł https://docs.microsoft.com/en-us/windows/desktop/FileIO/naming-a-file#maximum-path-length-limitation

Ograniczenie maksymalnej długości ścieżki

W interfejsie API systemu Windows (z pewnymi wyjątkami omówionymi w poniższych akapitach) maksymalna długość ścieżki wynosi MAX_PATH , która jest zdefiniowana jako 260 znaków. Ścieżka lokalna jest uporządkowana w następującej kolejności: litera dysku, dwukropek, ukośnik odwrotny, składniki nazwy oddzielone ukośnikami odwrotnymi i kończący znak null. Na przykład maksymalna ścieżka na dysku D to „D: \ jakiś 256-znakowy ciąg ścieżki <NUL>”, gdzie „<NUL>” reprezentuje niewidoczny kończący znak null dla bieżącej strony kodowej systemu. (Znaki <> są tutaj używane dla przejrzystości wizualnej i nie mogą być częścią prawidłowego ciągu ścieżki.)

Teraz widzimy, że jest to 1 + 2 + 256 + 1 lub [dysk] [: \] [ścieżka] [null] = 260. Można założyć, że 256 to rozsądna stała długość łańcucha z dni DOS. Wracając do interfejsów API DOS, zdajemy sobie sprawę, że system śledził bieżącą ścieżkę na dysk i mamy 26 (32 z symbolami) maksymalnej liczby dysków (i bieżących katalogów).

INT 0x21 AH = 0x47 mówi „Ta funkcja zwraca opis ścieżki bez litery dysku i początkowego ukośnika odwrotnego”. Widzimy więc, że system przechowuje CWD jako parę (dysk, ścieżka) i pytasz o ścieżkę, określając dysk (1 = A, 2 = B,…), jeśli określisz 0, wówczas zakłada ona ścieżkę dla dysk zwrócony przez INT 0x21 AH = 0x15 AL = 0x19. Teraz wiemy, dlaczego jest to 260, a nie 256, ponieważ te 4 bajty nie są przechowywane w ciągu ścieżki.

Dlaczego 256-bajtowy ciąg ścieżki, ponieważ 640K wystarcza pamięci RAM.

Nie jest to do końca prawdą, ponieważ system plików NTFS obsługuje ścieżki do 32 000 znaków. Możesz użyć interfejsu win32 i \\?\prefiksu ścieżki, aby użyć więcej niż 260 znaków.

Szczegółowe wyjaśnienie długiej ścieżki z bloga zespołu .Net BCL .
Mały fragment podkreśla problem długimi ścieżkami

Innym problemem jest niespójne zachowanie, które spowodowałoby ujawnienie obsługi długiej ścieżki. Długich ścieżek z \\?\prefiksem można używać w większości interfejsów API Windows związanych z plikami, ale nie we wszystkich interfejsach API Windows. Na przykład LoadLibrary, która mapuje moduł na adres procesu wywołującego, kończy się niepowodzeniem, jeśli nazwa pliku jest dłuższa niż MAX_PATH. Oznacza to, że MoveFile pozwoli Ci przenieść bibliotekę DLL do lokalizacji, w której jej ścieżka jest dłuższa niż 260 znaków, ale próba załadowania biblioteki DLL zakończy się niepowodzeniem. Istnieją podobne przykłady w interfejsach API systemu Windows; istnieją pewne obejścia, ale dotyczą one poszczególnych przypadków.

Pytanie brzmi, dlaczego ograniczenie wciąż istnieje. Z pewnością nowoczesny system Windows może zwiększyć stronę, MAX_PATHaby umożliwić dłuższe ścieżki. Dlaczego ograniczenie nie zostało usunięte?

• Nie można go usunąć dlatego, że Windows obiecał, że nigdy się nie zmieni.

Dzięki umowie interfejsu API system Windows gwarantuje wszystkim aplikacjom, że standardowe interfejsy API plików nigdy nie zwrócą ścieżki dłuższej niż 260 znaki.

Rozważ następujący poprawny kod:

WIN32_FIND_DATA findData;

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

Windows zagwarantował programowi, że zapełni moją WIN32_FIND_DATAstrukturę:

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 , tak jak Windows API. Moja aplikacja wykorzystała tę zdefiniowaną wartość.

Moja struktura jest poprawnie zdefiniowana i przydziela tylko 592bajty ogółem. Oznacza to, że mogę otrzymać tylko nazwę pliku składającą się z mniej niż 260znaków. Windows obiecał mi, że jeśli poprawnie napisam moją aplikację, będzie ona nadal działać w przyszłości.

Gdyby system Windows zezwolił na nazwy plików dłuższe niż 260 znaki, moja istniejąca aplikacja (która prawidłowo używała poprawnego interfejsu API) nie działałaby.

Każdy, kto wzywa Microsoft do zmiany MAX_PATHstałej, musi najpierw upewnić się, że żadna istniejąca aplikacja nie uległa awarii. 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 systemie Windows 10. Właśnie to zapewnia kompatybilność wsteczna.

Microsoft zrobił stworzyć drogę do korzystania z pełnych 32.768 nazw ścieżek; ale musieli stworzyć nową umowę API, aby to zrobić. Po pierwsze, powinieneś użyć Shell API do wyliczenia plików (ponieważ nie wszystkie pliki istnieją na dysku twardym lub w udziale sieciowym).

Ale nie muszą również łamać istniejących aplikacji użytkownika. Zdecydowana większość aplikacji nie używa interfejsu API powłoki do pracy z plikami. Wszyscy tylko dzwonią FindFirstFile/ FindNextFilei dzwonią na jeden dzień.

W systemie Windows 10. możesz usunąć to ograniczenie , modyfikując klucz rejestru.

Wskazówka Począwszy od systemu Windows 10, wersja 1607, ograniczenia MAX_PATH zostały usunięte ze wspólnych 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(Typ:) REG_DWORD. Wartość klucza zostanie zbuforowana przez system (na proces) po pierwszym wywołaniu do pliku lub funkcji katalogu systemu Win32, którego dotyczy problem (lista znajduje się poniżej). Klucz rejestru nie zostanie ponownie załadowany w trakcie trwania procesu. Aby wszystkie aplikacje w systemie rozpoznawały wartość klucza, konieczne może być ponowne uruchomienie komputera, ponieważ niektóre procesy mogły zostać uruchomione przed ustawieniem klucza. Kluczem rejestru można również sterować za pomocą zasad grupy pod adresem Computer Configuration > Administrative Templates > System > Filesystem > Enable NTFS long paths. Możesz także włączyć nowe zachowanie długiej ścieżki dla aplikacji za pomocą manifestu:

<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. Jeśli masz ścieżkę z wiersza poleceń, C:\path\to\long\foldermożesz zmapować ją na literę dysku X:za pomocą:

subst x: \path\to\long\folder

Jednym ze sposobów radzenia sobie z ograniczeniem ścieżki jest skrócenie wpisów ścieżki za pomocą dowiązań symbolicznych.

Na przykład:

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

Możesz włączyć długie nazwy ścieżek za pomocą PowerShell:

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

Inną wersją jest użycie zasad grupy w Computer Configuration/ Administrative Templates/ System/ Filesystem:

Jak się dlaczego to, nadal istnieje - MS nie uważa tego za priorytet i ceni kompatybilność wsteczną zamiast ulepszania swojego systemu operacyjnego (przynajmniej w tym przypadku).

Obejściem, którego używam, jest użycie „krótkich nazw” dla katalogów na ścieżce, zamiast ich standardowych, czytelnych dla człowieka wersji. Tak np. Dla C:\Program Files\chciałbym użyć C:\PROGRA~1\ Możesz znaleźć odpowiedniki krótkiej nazwy za pomocą dir /x.

Jeśli chodzi o sposób radzenia sobie z ograniczeniem rozmiaru ścieżki w systemie Windows - użycie 7zip do pakowania (i rozpakowywania) plików wrażliwych na długość ścieżki wydaje się realnym obejściem. Użyłem go do transportu kilku instalacji IDE (tych ścieżek wtyczek Eclipse, tak!) I stosów dokumentacji generowanej automatycznie i do tej pory nie miałem żadnego problemu.

Nie bardzo wiem, jak omija limit 260 znaków ustawiony przez Windows (z technicznego PoV), ale hej, to działa!

Więcej informacji na stronie SourceForge tutaj :

„NTFS może w rzeczywistości obsługiwać ścieżki o długości do 32 000 znaków.”

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

Ale jest wyłączone w kodzie SFX. Niektórzy użytkownicy nie lubią długich ścieżek, ponieważ nie rozumieją, jak z nimi pracować. Właśnie dlatego wyłączyłem go w kodzie SFX.

i informacje o wersji :

9.32 alfa 01.12.2013

• Poprawiona obsługa ścieżek plików dłuższych niż 260 znaków.

4.44 beta 2007-01-20

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

WAŻNA UWAGA: Aby to działało poprawnie, musisz bezpośrednio określić ścieżkę docelową w oknie dialogowym „Wyodrębnij” 7zip , zamiast przeciągania i upuszczania plików do zamierzonego folderu. W przeciwnym razie folder „Temp” zostanie użyty jako tymczasowa pamięć podręczna, a po przywróceniu plików do ich „ostatecznego miejsca spoczynku” nastąpi odbicie do tego samego ograniczenia 260 znaków. Aby uzyskać więcej informacji, zobacz odpowiedzi na to pytanie .

Tak, i z jakiegoś powodu jest to ustawienie domyślne, ale można go łatwo zastąpić za pomocą tego klucza 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/

Innym sposobem radzenia sobie z tym jest użycie Cygwin, w zależności od tego, co chcesz zrobić z plikami (tj. Czy polecenia Cygwin odpowiadają Twoim potrzebom)

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

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