Windows'da 260 karakter yolu uzunluk sınırı neden var?

Bu sorunla birkaç kez uygunsuz anlarda karşılaştım:

• Derin yollara sahip açık kaynaklı Java projeleri üzerinde çalışmaya çalışmak
• Derin Fitnesse wiki ağaçlarının kaynak kontrolünde depolanması
• Kaynak kontrol ağacımı içe aktarmak için Bazaar'ı kullanmaya çalışırken bir hata oluştu

Bu sınır neden var?

Neden henüz kaldırılmadı?

Yol sınırıyla nasıl başa çıkıyorsunuz? Ve hayır, Linux veya Mac OS X'e geçmek bu soruya geçerli bir cevap değildir;)

Bu makaleden alıntı yapmak https://docs.microsoft.com/en-us/windows/desktop/FileIO/naming-a-file#maximum-path-length-limitation

Maksimum Yol Uzunluğu Sınırlaması

Windows API'sinde (aşağıdaki paragraflarda ele alınan bazı istisnalar hariç), bir yol için maksimum uzunluk 260 karakter olarak tanımlanan MAX_PATH'dir . Yerel bir yol şu sırayla yapılandırılır: sürücü harfi, iki nokta üst üste işareti, ters eğik çizgi, ters eğik çizgilerle ayrılmış ad bileşenleri ve bir son boş karakter. Örneğin, D sürücüsündeki maksimum yol "D: \ 256 karakterlik bir <NUL> karakter dizesidir " burada "<NUL>", geçerli sistem kod sayfası için görünmeyen sonlandırma boş karakterini temsil eder. (Burada <> karakterleri görsel netlik için kullanılır ve geçerli bir yol dizesinin parçası olamaz.)

Şimdi bunun 1 + 2 + 256 + 1 veya [sürücü] [: \] [path] [null] = 260 olduğunu görüyoruz. 256, DOS günlerinden makul bir sabit dize uzunluğu olduğunu varsayabiliriz. DOS API'lerine geri dönersek, sistemin sürücü başına geçerli yolu izlediğini ve 26 (sembollü 32) maksimum sürücüye (ve mevcut dizinlere) sahip olduğumuzu anlıyoruz .

INT 0x21 AH = 0x47 “Bu işlev, sürücü harfi ve ilk ters eğik çizgi olmadan yol açıklamasını döndürür.” Böylece sistemin CWD'yi bir çift (sürücü, yol) olarak sakladığını görüyoruz ve sürücüyü (1 = A, 2 = B,…) belirterek yolu soruyorsunuz, eğer bir 0 belirtirseniz, INT 0x21 AH = 0x15 AL = 0x19 tarafından döndürülen sürücü. Şimdi neden 256 değil 260 olduğunu biliyoruz, çünkü bu 4 bayt yol dizesinde saklanmaz.

Neden 256 bayt yol dizesi, çünkü 640K yeterli RAM.

NTFS dosya sistemi 32k karaktere kadar yolları desteklediğinden bu kesinlikle doğru değildir. \\?\260 karakterden fazla kullanmak için win32 api ve " " önekini kullanabilirsiniz.

Net BCL takım blogundan uzun yolun ayrıntılı bir açıklaması .
Küçük bir alıntı, uzun yollarla ilgili sorunu vurgular

Başka bir endişe, uzun yol desteğinin ortaya çıkmasıyla sonuçlanacak tutarsız davranıştır. Ön \\?\ek içeren uzun yollar , dosyayla ilişkili Windows API'larının çoğunda kullanılabilir, ancak tüm Windows API'larında kullanılamaz. Örneğin, bir dosya çağıran işlemin adresiyle eşlenen LoadLibrary, dosya adı MAX_PATH değerinden uzunsa başarısız olur. Yani bu, MoveFile'ın DLL dosyasını yolu 260 karakterden daha uzun olacak bir konuma taşımanıza izin vereceği anlamına gelir, ancak DLL dosyasını yüklemeye çalıştığınızda başarısız olur. Windows API'lerinde benzer örnekler vardır; bazı geçici çözümler mevcuttur, ancak bunlar her durum için ayrı ayrıdır.

Soru şu ki, sınırlama hala neden var. Elbette modern Windows, MAX_PATHdaha uzun yollara izin vermek için tarafını artırabilir . Sınırlama neden kaldırılmadı?

• Kaldırılmamasının nedeni, Windows'un asla değişmeyeceğine söz vermesidir.

API sözleşmesi aracılığıyla, Windows tüm uygulamalara standart dosya API'lerinin 260karakterlerden daha uzun bir yol döndürmeyeceğini garanti etmiştir .

Aşağıdaki doğru kodu göz önünde bulundurun :

WIN32_FIND_DATA findData;

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

Windows, programıma yapımı dolduracağını garanti etti WIN32_FIND_DATA:

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

Uygulamam sabitin değerini açıklamadı MAX_PATH, Windows API yaptı. Uygulamam bu tanımlı değeri kullandı.

Yapım doğru bir şekilde tanımlandı ve yalnızca 592toplam bayt ayırdı . Bu, yalnızca 260karakterlerden daha az bir dosya adı alabildiğim anlamına gelir . Windows , uygulamamı doğru yazsaydım, uygulamamın gelecekte de çalışmaya devam edeceğine söz verdi .

Windows 260karakterlerden daha uzun dosya adlarına izin verseydi, mevcut uygulamam (doğru API'yi doğru kullanan) başarısız olur.

Microsoft'un MAX_PATHsabiti değiştirmesini isteyen herkes için , öncelikle mevcut uygulamanın başarısız olmadığından emin olmaları gerekir. Örneğin, hala sahip ve Windows 3.11 üzerinde çalıştırmak için yazılmış bir Windows uygulaması kullanın. Hala 64-bit Windows 10 üzerinde çalışıyor.

Microsoft , 32.768 yol adının tamamını kullanmak için bir yol oluşturdu; ancak bunu yapmak için yeni bir API sözleşmesi oluşturmaları gerekiyordu. Birincisi, dosyaları numaralandırmak için Shell API'sini kullanmalısınız (tüm dosyalar bir sabit sürücüde veya ağ paylaşımında bulunmadığından).

Ancak mevcut kullanıcı uygulamalarını da kırmamak zorundalar. Uygulamaların büyük çoğunluğu do not dosya çalışmaları için kabuk API kullanmak. Herkes sadece arar FindFirstFile/ FindNextFileve bir gün arar.

Windows 10'dan bir kayıt defteri anahtarını değiştirerek sınırlamayı kaldırabilirsiniz .

İpucu Windows 10'dan itibaren, sürüm 1607, MAX_PATH sınırlamaları yaygın Win32 dosya ve dizin işlevlerinden kaldırılmıştır. Ancak, yeni davranışı kabul etmelisiniz.

Kayıt defteri anahtarı, yeni uzun yol davranışını etkinleştirmenizi veya devre dışı bırakmanızı sağlar. Uzun yol davranışını etkinleştirmek için kayıt defteri anahtarını HKLM\SYSTEM\CurrentControlSet\Control\FileSystem LongPathsEnabled(Tür :) olarak ayarlayın REG_DWORD. Etkilenen bir Win32 dosyasına veya dizin işlevine yapılan ilk çağrıdan sonra anahtarın değeri sistem tarafından (işlem başına) önbelleğe alınır (liste aşağıdadır). Kayıt defteri anahtarı, işlemin ömrü boyunca yeniden yüklenmez. Sistemdeki tüm uygulamaların anahtarın değerini tanıması için, anahtar ayarlanmadan önce bazı işlemler başlamış olabileceğinden yeniden başlatma gerekebilir. Kayıt defteri anahtarı adresindeki Grup İlkesi aracılığıyla da denetlenebilir Computer Configuration > Administrative Templates > System > Filesystem > Enable NTFS long paths. Manifest aracılığıyla uygulama başına yeni uzun yol davranışını da etkinleştirebilirsiniz:

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

Bir klasörü sürücü olarak bağlayabilirsiniz. Komut satırından, bir yolunuz C:\path\to\long\foldervarsa bunu X:kullanarak harfi sürücü ile eşleyebilirsiniz :

subst x: \path\to\long\folder

Yol sınırıyla başa çıkmanın bir yolu, yol girişlerini sembolik bağlantılarla kısaltmaktır.

Örneğin:

1. C:\puzun yollara kısa bağlantılar tutmak için bir dizin oluşturun
2. mklink /J C:\p\foo C:\Some\Crazy\Long\Path\foo
3. C:\p\foouzun yol yerine yolunuza ekleyin

PowerShell kullanarak uzun yol adlarını etkinleştirebilirsiniz:

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

Başka bir Sürüm Computer Configuration/ Administrative Templates/ System/ altında Grup İlkesi kullanmaktır Filesystem:

Bunun neden hala var olduğuna gelince - MS bunu bir öncelik olarak görmüyor ve işletim sistemlerini ilerletmeye (en azından bu örnekte) göre geriye dönük uyumluluğa değer veriyor.

Kullandığım geçici çözüm, yoldaki dizinler için standart, insan tarafından okunabilir sürümleri yerine "kısa adlar" kullanmaktır. Yani örneğinC:\Program Files\ ben kullanmak için C:\PROGRA~1\ kullanarak kısa ad eşdeğerlerini bulabilirsiniz dir /x.

Windows'ta yol boyutu sınırlamasıyla nasıl başa çıkılacağı konusunda - yol uzunluğuna duyarlı dosyalarınızı paketlemek (ve paketinden çıkarmak) için 7zip kullanmak uygun bir geçici çözüm gibi görünüyor. Birkaç IDE yüklemesini (bu Eclipse eklenti yolları, yikes!) Ve otomatik olarak oluşturulmuş doküman yığınlarını taşımak için kullandım ve şimdiye kadar tek bir sorun yaşamadım.

Windows tarafından belirlenen teknik karakter sınırından (teknik bir PoV'dan) nasıl kurtulacağından emin değilim, ama işe yarıyor!

SourceForge sayfalarında daha fazla ayrıntı bulabilirsiniz :

"NTFS, uzunluğu 32.000 karaktere kadar olan yol adlarını destekleyebilir."

7-zip ayrıca bu uzun isimleri de destekler.

Ancak SFX kodunda devre dışı bırakılmıştır. Bazı kullanıcılar uzun yollardan hoşlanmazlar, çünkü onlarla nasıl çalışacaklarını anlamıyorlar. Bu yüzden SFX kodunda devre dışı bıraktım.

ve sürüm notları :

9.32 alfa 2013-12-01

• 260 karakterden uzun dosya yol adları için geliştirilmiş destek.

4.44 beta 2007-01-20

• 7-Zip artık 260 karakterden uzun dosya yol adlarını desteklemektedir.

ÖNEMLİ NOT: Bunun düzgün çalışması için , dosyaları istenen klasöre sürükleyip bırakmak yerine 7zip "Ayıkla" iletişim kutusunda doğrudan hedef yolunu belirtmeniz gerekir . Aksi takdirde, "Temp" klasörü geçici bir önbellek olarak kullanılır ve Windows Gezgini dosyaları "son dinlenme yerlerine" taşımaya başladığında aynı 260 karakter sınırlamasına geri dönersiniz. Daha fazla bilgi için bu soruya verilen yanıtlara bakın .

Bunu yapar ve bir nedenden dolayı varsayılan değerdir, ancak bu kayıt defteri anahtarıyla kolayca geçersiz kılabilirsiniz:

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

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

Bununla başa çıkmanın bir başka yolu, dosyalarla ne yapmak istediğinize bağlı olarak Cygwin'i kullanmaktır (yani, Cygwin komutları ihtiyaçlarınıza uygunsa)

Örneğin, Windows Gezgini'nin bile yapamadığı dosyaları kopyalamaya, taşımaya veya yeniden adlandırmaya izin verir. Veya elbette md5sum, grep, gzip vb.Gibi içeriklerle ilgilenin.

Ayrıca kodladığınız programlar için bunları Cygwin DLL dosyasına bağlayabilirsiniz ve uzun yollar kullanmasını sağlar (Bunu test etmedim)