sv.phhsnews.com


sv.phhsnews.com / Varför rapporterar Windows den här mappen för länge att kopiera?

Varför rapporterar Windows den här mappen för länge att kopiera?


Om du arbetar tillräckligt med Windows tillräckligt länge, särskilt med mappar och filer med långa namn, kommer du att gå in i ett bisarrt fel : Windows rapporterar att mappvägen eller filnamnet är för långt för att flytta till en ny destination eller till och med radera. Vad är affären?

Hej hur-till-geek!

Så om dagen omorganiserades jag några filer på min dator, skapade mappar, sådana saker. Sedan när jag rörde vissa filer i en mapp får jag ett meddelande och anger att den resulterande mappbanan skulle vara för lång. Jag var förvirrad. Jag vet att varje operativsystem sedan DOS stöder Långa Filnamn, men Windows hävdar att banan är för lång? Varför händer detta?

Med vänlig hälsning,

Herr. Oorganiserad

Problemet du stöter på är ett olyckligt skärningspunkt mellan två system som i sådana fall ger ett fel. För att förstå exakt var felet kommer ifrån måste vi gräva in i Long File Name (LFN) och hur Windows interagerar med dem innan vi gräver till lösningar.

Långa filnamn introducerades genom den underliggande MS-DOS-arkitekturen , i Windows 95. Det nya LFN-systemet tillåts för fil- och katalognamn på upp till 255 tecken. Detta var en välkommen expansion av det tidigare filnamnssystemet, vanligtvis kallat 8.3 filnamn eftersom namnet var begränsat till åtta tecken och en tresiffrig förlängning, men även känd som kort filnamn (SFN). Som du kan tänka dig, då var det fortfarande många DOS-baserade appar runt och det fanns mer än några huvudvärk som försökte få de nyare LFN och de äldre SFN: erna att leka bra med varandra. Om du någonsin har stött på en äldre diskett eller CD-ROM med ojämnt avkortade filer på den (som abcdef ~ 1.txt) så klippdes filnamnet av vissa SFN-användande äldre program från något längre och icke-stödjande LFN (som abcdefghijk. txt).

Vi är dock långt från mitten av 1990-talet, och hela filen Long Fileename är (för det mesta) hårt utjämnad. Om du kör en version av Windows från de senaste 10 åren har du förmodligen aldrig kommit över en filnamnslängdskonflikt som vi brukade springa in i DOS / Windows 95-dagarna. Med det sagt fortsätter vi fortfarande med hicka, som du upptäckte med ditt diskrensningsprojekt. Men varför? Om Windows 'Long Filename-system stöder mappar och filnamn på upp till 255 tecken per komponent, vilken vägg kör du in? Vi kan inte skylla på NTFS (filsystemet som de allra flesta moderna Windows-maskiner använder) som NTFS kommer att stödja en kedjning av mappar och filnamn upp till en total banlängd på 32.767 tecken. Så långt överstiger den typiska katalogstrukturen de flesta användare någonsin behöver.

Om allt faller isär, är en artificiell begränsning av Windows-stackar ovanpå LFN / NTFS-systemet: MAX_PATH-variabeln. MAX_PATH-variabeln anger att en komplett katalogstruktur i Windows inte kan överstiga 260 totala tecken, inklusive drivbrevet, kolon, backslash och null backlash i slutet. Således har du bara en potentiell riktig MAX_PATH med 256 tecken, t ex C: din-256-tecken-sökvägen .

Så vad hände när du städade datorn är att du hade en katalog med en redan lång väg (antingen på grund av att mappnamnen var långa var filnamnen långa eller båda) och när du försökte flytta en eller flera av dessa kataloger till en annan katalog med en lång sökväg, var längden på banan Namnet översteg den 260 teckengränsen som infördes av MAX_PATH-variabeln.

Nu kanske du tänker "Ah-hah! Vi ändrar bara MAX_PATH-variabeln och löser problemet! "Okej, det är inte så enkelt. Inte bara är MAX_PATH-variabeln väsentligen svårkodad till Windows, men även om du gick igenom det enorma krånget för att ändra det, skulle du sluta bryta så mycket det skulle inte vara värt det. För många applikationer förväntar sig att variabeln är det som Windows länge har angett att det ska vara. Vi kan inte bara gå runt ändra det utan att skapa en enorm röra.

Var lämnar du dig? Jo, den enklaste lösningen är att bara redigera sökdata. Om du till exempel har massor av sparade artiklar där programmet / tillägget du brukade spara från webben skapade en katalog som var den fullständiga titeln på artikeln + artikeln, och då är filnamnet fullständigt titeln av artikeln + artikeln leder, skulle det vara riktigt enkelt att träffa eller överträffa MAX_PATH med en enda spara. Om du har ett stort antal filer med en lång väg och du inte vill redigera dem alla (eller om du har ett stort antal filer med en lång sökväg, är det enkelt att fixa problemet. du vill

radera ett ton gamla kataloger som är för långa för att Windows ska hantera när det är begränsat av MAX_PATH-variabeln), det finns en kommandorad som fungerar. Trots att Windows är begränsad av MAX_PATH-variabeln, insåg Windows ingenjörer att det skulle finnas situationer där användarna skulle behöva hantera längre sökvägar. Som sådan har Windows API en funktion för att hantera extremt långa vägar. För att kunna dra nytta av det API: n och använda kommandoradsverktyg på dina obehagliga mappar / filnamn behöver du bara lägga till katalognamnet med en några extra tecken. Om du till exempel hade en stor katalogstruktur som du vill radera (men fick ett fel på grund av banlängden när du försökte det) kan du ändra kommandot från:

rmdir c: documents some-really -super-lång-mapp-namn-schema

till:

rmdir \? c: documents some-really-super-long-mapp-namn-schema

Nyckeln är Tillägg av delen

\? före början av filbanan; Detta instruerar Windows att ignorera begränsningarna som införs av MAX_PATH-variabeln och att interagera med den sökväg du just har tillhandahållit som levereras / förstås direkt av det underliggande filsystemet (vilket tydligt kan stödja en längre bana). Som alltid, var försiktig vid kommandotolken för att undvika att oavsiktligt radera filer eller kataloger som du tänkt lämna intakt.Om vår översikt över det här problemet har du nyfiken, gräva dig definitivt i den här artikeln i biblioteket Microsoft Developer Network, Naming Files, Banor och Namnrymder, för mer information om vad som händer under huven.

Har du en snabb teknisk fråga? Skjut oss ett mail på och vi gör vårt bästa för att svara på det.



ÄR en dators CPU-aktiv när ett operativsystem är i viloläge?

ÄR en dators CPU-aktiv när ett operativsystem är i viloläge?

När du sätter operativsystemet i viloläge, hur mycket aktivitet är det faktiskt "under huven" med din dators hårdvara? Dagens SuperUser Q & A-tjänst har en bra förklaring till att hjälpa en nyfiken läsare att lära sig mer om hur hans system och dator fungerar. Dagens Frågor och svar sessions kommer till oss med tillstånd av SuperUser-en indelning av Stack Exchange, en community-driven gruppering av Q & A-webbplatser.

(how-to)

Så här återställer du skrivbordet och dokumenten efter att du avaktiverat iCloud-synkronisering i MacOS Sierra

Så här återställer du skrivbordet och dokumenten efter att du avaktiverat iCloud-synkronisering i MacOS Sierra

En ny funktion i MacOS Sierra låter dig synkronisera filer från skrivbordet och dokumentmappen till iCloud så att du kan komma åt dem på hela din enhet. Men om du gick för att inaktivera den här funktionen tar den bort från din dator. Frukt inte, men: de här filerna finns fortfarande. De flyttades helt enkelt från skrivbordet och dokumentmappen och lämnades i iCloud Drive.

(how-to)