Miért túl hosszú a Windows jelentéskészítés Ez a mappa túl hosszú a másoláshoz?

Ha elég hosszú ideig dolgozik a Windows rendszerrel, különösen a hosszú nevekkel rendelkező mappák és fájlok esetében, bizarr hiba lép fel: a Windows jelzi, hogy a mappa elérési útja vagy a fájlnév túl hosszú ahhoz, hogy új célállomásra vagy akár törlésre kerüljön. Mi a helyzet?

Hé How-To Geek!

Tehát a másik nap, néhány olyan fájlt átrendeztem a számítógépemre, amelyek mappákat hoztak létre. Aztán, amikor néhány fájlt mozgattam egy mappába, üzenetet kapok, és megállapítottam, hogy a kapott mappaút túl hosszú lesz. Össze voltam zavarodva. Tudom, hogy minden egyes operációs rendszer, mivel a DOS támogatja a hosszú fájlneveket, a Windows azt állítja, hogy az útvonal túl hosszú? Miért történik ez?

Sincerly,

Mr. Disorganized

Az a probléma, amellyel fut, két rendszer szerencsétlen metszéspontja, amelyek ilyen esetekben hibát okoznak. Ahhoz, hogy pontosan megértsük, honnan származik a hiba, meg kell ásnunk a hosszú fájlnevek (LFN) történetét, és azt, hogy a Windows hogyan m ködik velük, mielőtt beleolvadnánk a megoldásokba.

Hosszú fájlneveket vezettek be a mögöttes MS-DOS architektúrán keresztül a Windows 95 rendszerben. Az új LFN-rendszer legfeljebb 255 karakteres fájl- és könyvtárnevekhez használható. Ez volt az előző fájlnév rendszer üdvözlő bővítése, általában 8,3 fájlnevezésnek nevezett, mert a név nyolc karakterre és háromjegyű kiterjesztésre korlátozódott, de rövid fájlnévként (SFN) is ismert. Amint el tudod képzelni, akkor még mindig sok DOS-alapú alkalmazás volt, és több mint néhány fejfájás próbálkozott az újabb LFN-ek és az örökölt SFN-ek kipróbálásával. Ha valaha is találsz egy régebbi hajlékonylemezt vagy CD-ROM-ot, amely furcsán csonkolt fájlokat tartalmazott (mint például az abcdef ~ 1.txt), a fájlnevet néhány SFN-t használó örökölt alkalmazás csökkentette néhány hosszabb és nem támogatott LFN-től (mint az abcdefghijk. txt).

Az 1990-es évek közepétől hosszú utat tartunk, és az egész hosszú fájlnév dolog (nagyrészt) szilárdan ki van zárva. Ha Windows-verziót futtat az elmúlt 10 év során, akkor valószínűleg soha nem találkozhatsz olyan fájlnév-hosszú konfliktusokkal, mint amilyeneket a DOS / Windows 95 napjaiban használtunk vissza. Ez azt jelenti, hogy még mindig zaklatásokba ütköztünk, amint felfedezted a lemeztisztító projektedet. De miért? Ha a Windows hosszú fájlnév-rendszere összetevőnként legfeljebb 255 karakterből álló mappákat és fájlneveket támogat, milyen falat futtat? Nem hibáztathatjuk az NTFS-t (a modern Windows-gépek nagy része által használt fájlrendszert), mivel az NTFS támogatja a mappák és fájlnevek láncolását, összesen 32.767 karakter hosszú elérési útig. Ez messze meghaladja a tipikus könyvtárstruktúrát, amelyre a legtöbb felhasználónak szüksége lenne.

Ahol az egész szétesik, egy mesterséges korlátozás, amelyet a Windows az LFN / NTFS rendszer tetején halad: a MAX_PATH változó. A MAX_PATH változó azt határozza meg, hogy a Windows teljes könyvtárstruktúrája nem haladhatja meg a 260 teljes karaktert, beleértve a meghajtóbetűjelet, a kettőspontot, a hátlapot és a null hátteret a végén. Így csak potenciális valódi MAX_PATH értéke 256 karakter, pl. C: \ z-256-karakteres path \.

Tehát, mi történt a számítógép tisztításakor, hogy már egy hosszú útvonallal rendelkezett (mert a mappanevek hosszúak voltak, a fájlnevek hosszúak voltak, vagy mindkettő), és amikor egy vagy többet próbált áthelyezni ezeknek a könyvtáraknak egy másik hosszú útvonallal rendelkező könyvtárába, az útvonalnév teljes hossza meghaladta a MAX_PATH változó által előírt 260 karakteres korlátot.

Most már gondolkodhatsz „Ah-hah! Csak módosítjuk a MAX_PATH változót és megoldjuk a problémát! ”Sajnos, ez nem olyan egyszerű. Nem csak a MAX_PATH változó lényegében kemény a Windows-ba kódolva, de még akkor is, ha végigment a hatalmas változás miatt, végül annyira elszakadna, hogy nem lenne megéri. Túl sok alkalmazás elvárja, hogy az útváltozó legyen a Windows által régóta megadott. Nem tudunk csak úgy változtatni, hogy hatalmas rendetlenséget hoznánk létre.

Hol hagy ez? Nos, a legegyszerűbb megoldás az útvonaladatok szerkesztése. Például, ha van egy tonna elmentett cikked, ahol az alkalmazás / kiterjesztés, amelyet a weben mentettél, létrehozott egy olyan könyvtárat, amely a cikk teljes címe + a cikk vezetője, és maga a fájlnév a teljes cím. a cikk + a cikk ólom, valóban egyszerű lenne megtakarítani vagy meghaladni a MAX_PATH-ot egyetlen mentéssel. Ezeknek a hatalmas mappáknak és cikkcímeknek az ésszerűbb méretre történő szerkesztése egyszerű módja a probléma megoldásának.

Ha van egy nagy számú, hosszú útvonallal rendelkező fájlja, és nem akarja azokat szerkeszteni (vagy ha szeretné) töröl egy régi könyvtár, amely túl hosszú ahhoz, hogy a Windows kezelje a MAX_PATH változó által korlátozott értékeket), van egy parancssoros munka. Annak ellenére, hogy a Windows a MAX_PATH változó által korlátozott, a Windows mérnökei rájöttek, hogy vannak olyan helyzetek, ahol a felhasználóknak hosszabb útvonalakkal kell foglalkozniuk. Mint ilyen, a Windows API funkciója rendkívül hosszú útvonalak kezelésére szolgál.

Annak érdekében, hogy kihasználhassuk ezt az API-t és használjuk a parancssori eszközöket a nehézkes mappákban / fájlnevekben, egyszerűen csak néhány extra karakterrel kell hozzáadni a könyvtárnevet. Például, ha egy hatalmas könyvtárstruktúrával rendelkezett, amelyet törölni szeretne (de hiba történt az elérési utatól, amikor megpróbálta), megváltoztathatja a parancsot:

rmdir c: dokumentumok egy igazán szuper-hosszú mappa-név-séma

nak nek:

rmdir c: dokumentumok egy-nagyon-hosszú-mappa-név-séma

A kulcs az \\? \ a fájl elérési útja előtt; ez utasítja a Windows-t, hogy hagyja figyelmen kívül a MAX_PATH változó által meghatározott korlátozásokat, és lépjen kapcsolatba az éppen beszerzett útvonallal, amelyet közvetlenül az alapul szolgáló fájlrendszer (amely egyértelműen hosszabb útvonalat támogat) nyújt. Mint mindig, ügyeljen a parancssorra, hogy ne véletlenül törölje azokat a fájlokat vagy könyvtárakat, amelyeket érintetlenül hagyott.

Ha a kérdésünk áttekintése kíváncsi, határozottan belekerül a cikkbe a Microsoft Developer Network könyvtárából, a fájlok, útvonalak és névterek elnevezéséről, további információkért arról, hogy mi történik a motorháztető alatt.

Van egy sürgető technikai kérdés? Légy minket e-mailben a [email protected] címen, és mindent megteszünk, hogy válaszoljunk rá.