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


390

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


8
@Artelius: W rzeczywistości system Windows (przynajmniej od wersji Win2K) obsługuje punkty połączeń ( en.wikipedia.org/wiki/NTFS_junction_point ), a system Vista obsługuje łącza symboliczne NT ( en.wikipedia.org/wiki/NTFS_symbolic_link ). W każdym razie, chociaż dowiązania symboliczne mogą pomóc w uczynieniu dłuższych / zagnieżdżonych ścieżek bardziej przyjaznymi, nie mogę myśleć, w jaki sposób dowiązania symboliczne mogłyby pomóc, jeśli osiągniesz limit długości ścieżki.
Ashutosh Mehra,

8
Nawet jeśli ten limit nie istniał, zawsze istnieje wiele innych limitów, a każdy z nich może w pewnym momencie być denerwujący. Chodzi o to, dlaczego ten limit jest tak niski? Po erze 8.3 i przy sprzęcie o rozmiarze mega / giga ścieżka powinna być teraz dynamicznie przydzielanym ciągiem o praktycznie nieograniczonym rozmiarze.
Roland,

12
Microsoft wreszcie rozwiązuje ten problem w Windows 10 Build 14352.
Warren P

3
Tak i wygląda na to, że musisz zmodyfikować manifest aplikacji, aby był on świadomy długiej ścieżki.
Warren P

3
@PatrickSzalapski niestety zostało to naprawione visualstudio.uservoice.com/forums/121579-visual-studio/…
phuclv

Odpowiedzi:


230

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.


21
Interfejs API systemu Windows ogranicza długość, nawet w najnowszym systemie operacyjnym. Microsoft boi się zniszczyć setki milionów używanych obecnie systemów operacyjnych, gdyby to się zmieniło, ponieważ nie mają już dla nich geniuszy, którzy rozumieją API wewnątrz i na zewnątrz, tak jak to robili w latach 80. i 90. XX wieku. Ryzyko nie jest warte zmiany. serverfault.com/questions/163419/…
MacGyver

77
@MacGyver Przepraszamy, ale to kompletny nonsens. Microsoft nie chce rozbić milionów źle napisanych aplikacji, które zakładają , że system nigdy nie był gwarantowany. Niestety, tak długo było tak samo, że programiści zaczęli na nich polegać, więc zmiana teraz złamałaby aplikacje innych firm, a MS zostałoby obwinione.
Podstawowy

25
przy okazji nie ma dowodów na to, że Gates kiedykolwiek powiedział, że „640K Ram wystarcza dla wszystkich” computerworld.com/article/2534312
Patrick Favre

11
@Basic Limit 260 znaków był gwarantowany przez system Windows. Stała została zadeklarowana jako stała , w plikach nagłówkowych Windows zadeklarowano strukturę, która ma miejsce tylko na 260 znaków. Nie ma sposobu, aby to zmienić.
Ian Boyd

35
@Basic Stała nie zmienia się po skompilowaniu w mojej aplikacji. Uruchomiłem aplikację, która została ostatnio zbudowana w 1994 roku i nadal działa w systemie Windows 10. Microsoft obiecał pewien rozmiar binarny bloku pamięci, a programista przestrzegał tej zasady. Gdyby Microsoft zmienił stałą, wówczas każda istniejąca aplikacja, która poprawnie postępowała zgodnie z API programowania, zostałaby zepsuta . Nie można złamać kompatybilności binarnej.
Ian Boyd

150

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.


4
W porządku, ale oznacza to, że musisz używać P / Invoke w wielu miejscach, a to, moim zdaniem, zmniejsza przenośność twojego kodu .Net. Co jeśli chciałbym zachować kompatybilność z mono?
Jeffrey Cameron,

1
Chodzi mi o to, że jeśli naprawdę chcesz, możesz skorzystać z długiej ścieżki. Ale zgadzam się, że to jest ból i osobiście bym tego również unikał.
softveda,

5
To powinna być wybrana odpowiedź. Właściwie odpowiada na pytanie zadane przez użytkownika DLACZEGO ten limit istnieje ORAZ zapewnia obejście.
Głosowanie

2
Wydaje mi się, że Microsoft musi naprawić swoje interfejsy API i myślę, że nie jest to priorytet. Byłem zaskoczony, że ten limit nadal istnieje w systemie Windows 8.
Mas

3
@Mas Wymagana „poprawka” została wykonana z powrotem do systemu Windows XP. Wywołanie wersji API unicode pozwoli ci uzyskać dostęp do „rozszerzonej ścieżki”. Wierzę, że odkrywca automatycznie to obsługuje. Oto jedna taka funkcja, która ją obsługuje - msdn.microsoft.com/en-us/library/windows/desktop/… .
Natalie Adams

108

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


4
@JosiahKeller Jeśli to zrobi, zerwie umowę pierwotnie zdefiniowaną dla tej metody, co może zastąpić niezamierzoną pamięć i otwarcie luki bezpieczeństwa. Jedynym sposobem, aby to naprawić, jest zaoferowanie nowego ulepszonego interfejsu API (takiego jak warianty obsługujące Unicode) i mam nadzieję , że wszyscy ponownie skompilują / ponownie wydadzą wszystkie swoje aplikacje przy użyciu nowszego interfejsu API.
Rowland Shaw,

2
@Ryios Nie sądzę, aby moje istniejące aplikacje Windows działały w systemie Linux.
Ian Boyd

9
Kompatybilność wsteczna jest dobra. Ale myślę, że unikanie dziś takich (często naprawdę paskudnych) problemów jest ważniejsze niż obsługa aplikacji Windows 3.1. Ilu ludzi ma problemy z długimi ścieżkami? A ile osób nadal korzysta z aplikacji Windows 3.1? Anulowali nawet obsługę systemu Windows XP. Dlaczego więc nie ogłosiły, że z systemu Windows [x] i późniejszych aplikacji, które zakładają, że ścieżka nie będzie dłuższa niż 260 znaków, nie będą działać zgodnie z oczekiwaniami, gdy napotkają ścieżkę, która jest długa? Nasze ograniczenia prędkości również nie dotyczą powozów.
JuSchu

2
@JuSchu To nie tylko aplikacje Windows 3.1. Aplikacje napisane dzisiaj przy użyciu poprawnego interfejsu API nie będą działać.
Ian Boyd,


62

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>

15
Niestety nawet w najnowszej wersji Win10 sam Eksplorator plików nadal ma problem z długą nazwą ścieżki. Nawet „Kopiuj jako ścieżkę” w menu kontekstowym nie działa zgodnie z oczekiwaniami; kopiuje tylko pierwsze 260 znaków. Nie możesz utworzyć folderu, skopiować / przenieść / otworzyć pliku ... Zastanawiam się, jaki jest sens tej zmiany.
raymai97

Zauważ, że twierdzenie, że ustawienie systemowe jest niezależne od ustawienia manifestu, jest błędne. Oba są wymagane. Zasady muszą być włączone na poziomie systemu, a manifest musi zadeklarować, że aplikacja obsługuje długą ścieżkę.
Eryk Sun

Czytałem, że wprowadzenie tej zmiany może powodować problemy ze zgodnością ze starszymi aplikacjami 32-bitowymi, ale czy ten typ problemu ze zgodnością jest powszechny? Chciałbym dokonać zmiany osobiście. lifehacker.com/…
KDP

32

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

otrzymuję komunikat „Nieprawidłowy parametr j:” podczas próby wykonania tego polecenia
barrypicker

Należy to uruchomić z wiersza polecenia Administratora (z podwyższonym poziomem uprawnień).
Mrchief

To nie powiedzie się z ukośnikami, muszą być odwrotnymi ukośnikami.
cchamberlain

1
Nie jestem pewien, czy dotyczy to tylko systemu Windows 10, jednak właśnie odkryłem, że podczas próby uruchomienia tego polecenia, jeśli działam jako administrator, jak sugerowano powyżej, napęd nie wydaje się dostępny. Wynika to z tego, że zachowanie wydaje się być podobne do mapowania dysku sieciowego i jest specyficzne dla sesji itp., Więc gdy uruchomiłem się jako administrator i użyłem tego polecenia, sesja może używać x: TL; DR Jeśli nie widzisz dysku, spróbuj uruchomienie polecenia bez przejścia w tryb administratora.
Jaddie

substjest lokalnym sesji / konto - patrz superuser.com/questions/29072/... dla jak zrobić to „system wide”
user2864740

18

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

3
Nie musiałem najpierw tworzyć katalogu, więc krok 1 nie jest konieczny.
ohaal

2
Ta sztuczka nie zawsze działa, ponieważ wiele aplikacji próbuje rozwiązać łącza
nponeccop

Ta /jopcja tworzy punkt podłączenia węzła dla lokalnego urządzenia woluminu lub ścieżkę na woluminie lokalnym (np. Podłączenie powiązania Unix). Nie tworzy dowiązania symbolicznego. Jest to ważne rozróżnienie, ponieważ punkty montowania połączeń są zawsze oceniane na serwerze i muszą być kierowane na urządzenia lokalne, podczas gdy dowiązania symboliczne są oceniane na kliencie i mogą być ukierunkowane na ścieżki zdalne (jeśli pozwalają na to zasady). Podobnie jak dysk subst.exe (tj. DefineDosDeviceW), Miejsce docelowe połączenia jest zwykle ograniczone do około 4K znaków. To właściwie 8 000 znaków, podzielonych mniej więcej równo między ścieżkę zastępczą i ścieżkę wyświetlania.
Eryk Sun

12

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:

Edytor zasad grupy


2
Każda aplikacja musi jeszcze zadeklarować, że jest świadoma długiej ścieżki. Microsoft wykonał słabą robotę, komunikując to, ponieważ wydaje się, że manifest aplikacji jest tylko innym sposobem włączenia tej funkcji, zamiast jasno wyjaśniać, że jest to umowa między systemem operacyjnym (polityką na poziomie systemu) a aplikacją, w której oba muszą się zgodzić.
Eryk Sun

8

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.


1
Krótkie nazwy ścieżek można wyłączyć w rejestrze (a może sam system plików?), Więc to naprawdę nie jest niezawodne obejście.
rubenvb

3
@rubenvb Jestem pewien, że większość, jeśli nie wszystkie funkcje systemu Windows można wyłączyć w rejestrze, więc ¯ \ _ (ツ) _ / ¯
Conrad

Generowanie krótkich nazw można wyłączyć dla NTFS (i powinno być tak, ponieważ w wielu przypadkach jest nieefektywne), albo dla całego systemu, albo dla woluminu, więc jest to niewiarygodne podejście nawet dla ścieżek na dysku systemowym, którym musi być NTFS. Możliwe jest ręczne ustawienie krótkich nazw plików i katalogów w NTFS, ale nie obejmuje to nowszych systemów plików, które w ogóle nie obsługują krótkich nazw, takich jak exFAT i ReFS. Krótkie nazwy należy uznać za przestarzałą funkcję, która zachowuje zgodność w ograniczonych przypadkach, podobnie jak stary interfejs API ANSI / OEM wykorzystujący jedno- i dwubajtowe strony kodowe.
Eryk Sun

@eryksun Proszę zobaczyć mój poprzedni komentarz na temat wyłączania krótkich nazw ścieżek. :) To, że uważasz, że powinno być uważane za przestarzałe, nie oznacza, że ​​tak naprawdę jest. MS nie planuje wycofać tej funkcji. (Ponadto, dlaczego instalujesz oprogramowanie Windows na partycjach exFAT / ReFS?)
Conrad

Nadal mówię, aby po prostu używać niestandardowych ścieżek urządzeń (tj. Przedrostek „\\? \”), Ponieważ są one zawsze dostępne i oczywiste. Na przykład przetłumacz go PATHi przekaż SearchPathW. Jest także wydajny, ponieważ biblioteka środowiska wykonawczego i tak tworzy ścieżki urządzeń „\\? \” Dla systemu NT. Co do nowszych systemów plików, prawdopodobnie nie widzielibyśmy oprogramowania zainstalowanego na woluminie exFAT, innym niż aplikacje przenośne, ponieważ nie ma ono zabezpieczeń, ale nie wykluczałbym ReFS. Użytkownicy instalują programy w niestandardowych lokalizacjach ze względu na wygodę, przestrzeń lub wydajność.
Eryk Sun,

7

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 .


3
Myliłem się, 7zip i WinRAR rozpakowują wszystkie foldery i pliki. Po prostu właściwość folderu w systemie Windows zgłasza tylko liczbę folderów i plików, które nie naruszają ograniczenia. To tak, jakby ten Eksplorator Windows nie kopał głębiej, aby odkryć foldery po osiągnięciu maksymalnej ścieżki.
Twisted Whisper

Możliwe jest usunięcie długiej ścieżki w 7-zip za pomocą shift-del.
Laurie Stearn

Krótka odpowiedź - użyj 7zip do rozpakowania pliku .zip .... działał dla mnie w systemie Windows 7
andrewcockerham


2

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)

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.