Windows i ścieżki, którymi podąża

W

Słowem wstępu

Dawno, dawno temu została stworzona stała MAX_PATH, decydująca o tym jak długie mogą być ścieżki do plików i katalogów w systemie Windows. Jest to setting na poziomie Windows API. Ostatnio w pracy dotknął mnie ten problem.

Niefortunne było to, że problem objawił się podczas modyfikowania pliku projektu jenkinsa, w celu utworzenia joba releasowego. Problem był o tyle uciążliwy, że przecież nie zmienię nagle całej struktury projektu i źródeł które zamierzam budować, ani tez nie będę przenosił całego jenkinsowego workspacea.

Zatem opcje były trzy:

  1. Instalacja odpowiedniej poprawki do systemu Windows.
  2. Zmiana ustawienia w systemie, tak aby mnie nie blokowało.
  3. Sprawienie że Windows będzie „widział” ścieżki jako prawidłowe, lub po prostu będzie je akceptować.

 

Łaty i bilety

Opcja nr. 1. Najłatwiejsza ze wszystkich proponowanych. Niestety nie zawsze działa. Link do patcha – PATCH

Jest to patch do systemu Windows Server 2012 R2 i zawiera m.in. poprawki do tego ticketu – TICKET

Tak jak wspomniałem, nie zawsze działa. W moim przypadku nie zadziałała. Ponad to, umówmy się, jeśli potrzebujesz stworzyć jenkinsowego joba na serwerze, gdzie masz odpalone multum usług, własnych serwisów itp. itd., nie chcesz instalować poprawek i restartować maszyny, tylko po to żeby sobie zbudować paczkę. Ja na szczęście nie musiałem próbować. Łatka wpadła z którymś windows updejtem i nie zmieniło to stanu rzeczy. Nie poddałem się…

 

Rejestry i inne settingi

Opcja nr. 2. Opcja ta od razu mi się spodobała ze względu na to, że zadziała globalnie i przy następnej „okazji” problem nie zaistnieje. Jak tego dokonać? Cóż, zależy w jakim systemie chcemy dokonać zmiany. Jeśli jest to Windows Server 2012 R2, tak jak to było w moim przypadku, rozwiązanie odpada, bo jest dostępne tylko dla systemów od wersji Windows Server 2016. Dlatego też, nie będę się zbytnio rozpisywać.

Trzeba sobie odpalić konsolę Group Policy Management (nie podejmuję się tłumaczenia tej nazwy 😉 ) (gpedit.msc).

Potem w drzewie wklikujemy się do:

Computer Configuration > Policies > Administrative Templates > System > Filesystem

I tam aktywujemy opcję: Enable Win32 logn paths.

 

Inna możliwością w tym względzie jest jeszcze zmiana wartości klucza w rejestrze.

W przypadku Windows 10…

HKLM\SYSTEM\CurrentControlSet\Control\FileSystem\LongPathsEnabled

…ustawiamy na 1.

W przypadku Windows Server 2012 R2…

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy Objects\{48981759-12F2-42A6-A048-028B3973495F}Machine\System\CurrentControlSet\Policies\LongPathsEnabled

…ustawiamy na 1.

 

Zamiast klikać po edytorze rejestru polecam się pobawić konsolą PowerShell. Wygląda to tak:

Windows 10…

Set-ItemProperty -Path Registry::HKLM\SYSTEM\CurrentControlSet\Control\FileSystem -Name LongPathsEnabled -Value 1

Windows Server 2012 R2…

Set-ItemProperty -Path Registry::HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy Objects\{48981759-12F2-42A6-A048-028B3973495F}Machine\System\CurrentControlSet\Policies -Name LongPathsEnabled -Value 1

 

Co jeśli nie ma którejś z tych opcji? Cóż… Znowu. Od czego jest PowerShell?!

Pokażę na przykładzie Windows 10.

Najpierw tworzymy ścieżkę do naszego klucza (jeśli jej nie ma, oczywiście):

New-Item -Path Registry::HKLM\SYSTEM\CurrentControlSet\Control\FileSystem

Potem, dodajemy potrzebny klucz rejestru:

New-ItemProperty -Path Registry::HKLM\SYSTEM\CurrentControlSet\Control\FileSystem -Name LongPathsEnabled -Value 1 -PropertyType DWord -Force

Wartość: 1.

Typ zmiennej: DWord.

Modyfikator: -Force – (w razie gdyby jednak klucz istniał, jesteśmy pewni, że go nadpiszemy)

 

iiiiiiiiii…voilà!  Restart maszyny i powinno działać. Jeśli nie, robimy smutną minkę i jedziemy dalej…

 

Unicode lub UNC

Opcja nr. 3. Generalnie NTFS jest w stanie obsłużyć ścieżki długości 32,767 znaków. żeby skorzystać z tej możliwości należy używać ścieżek w wersji unicode, czyli przed literą dysku podajemy „\\?\„:

\\?\D:\sciezka ktora jest dluga\a teraz jest jeszcze dluzsza niz Ci sie wydaje i niz sie spodziewasz\jeszcze troche znaczkow akg48utq9348gj\chyba starczy

 

Można też użyć ścieżki w wersji UNC czyli Uniwersal Naming Convention. Przed ścieżką trzeba wstawić „\\?\UNC\„:

\\?\UNC\kolejna sciezka ktora jest dluga\znowu przez to przechodzimy\razem\dzięki Tobie jest latwiej

 

Po więcej informacji odsyłam tutaj: Naming Files, Paths and Namespaces.

Niestety,lub stety, musiałem użyć metody ze ścieżkami typu Unicode, bo żadna z powyższych, oprócz właśnie unicode paths, w moim przypadku nie zadziałała. Nie wiem czym jest to spowodowane. Domyślam się, że stała MAX_PATH jest tak głęboko „zakorzeniona” w aplikacjach które używają WinAPI, że zmiany tego jak NTFS obsługuje ścieżki nic nie daje.

Jeśli macie jakiś inny sposób za pomocą którego radzicie sobie z tym problemem, proszę Was! P.R.O.S.Z.Ę! Podzielcie się nim ze mną w komentarzach, na fejsbuczku, w mejlu. Gdziekolwiek!

Jeśli podoba Ci się to co czytasz, i masz ochotę na więcej, zapraszam do przeczytania innych moich postów, jak i do subskrypcji newslettera!

Czołem!

 



 

About the author

4 komentarze

  • Nie wiem jakie masz potrzeby i gdzie dokładnie generuje się problem ale może warto stworzyć symlink (typu hard) do folderu że zbyt długą ścieżką?

    • Temat był na tapecie i odpadł na rzecz rozwiązań AdHoc, ale po Twoim komentarzu uznaję, że rozwiązanie będzie dobre w razie gdy problem będzie się powtarzać. I coś mi mówi, że będzie.

  • Dzięki za przypomnienie o tym problemie. Myślałem że już to poprawili, ale okazuje się że on nadal istnieje. Total Commander obsługuje długie nazwy ale krzyczy przy każdej operacji, że większość aplikacji będzie miała z tym problem. No i się nie myli.

    • Zauważam ostatnio takie typowe dla MS problemy, które nie występują nigdzie indziej oprócz produktów MS. Mogę się mylić, ze względu na to, że pracuję głównie w środowisku MS.

By Patryk

Autor serwisu

Patryk

Społecznościowe

Instagram

Newsletter



Historycznie

Tagi