nl.phhsnews.com


nl.phhsnews.com / Waarom meldt Windows Reporting dat deze map te lang is om te kopiëren?

Waarom meldt Windows Reporting dat deze map te lang is om te kopiëren?


Als u lang genoeg met Windows werkt, vooral met mappen en bestanden met lange namen, zult u een bizarre fout tegenkomen : Windows meldt dat het mappad of de bestandsnaam te lang is om naar een nieuwe bestemming te gaan of zelfs te verwijderen. Hoe zit het?

Hey How-To Geek! <> Zo, ik was onlangs een aantal bestanden op mijn computer aan het reorganiseren, mappen maken, dat soort dingen. Toen ik een aantal bestanden naar een map verplaatste, kreeg ik een bericht waarin stond dat het resulterende mappad te lang zou zijn. Ik was in de war. Ik weet dat elk besturingssysteem sinds DOS lange bestandsnamen ondersteunt, maar Windows beweert dat het pad te lang is? Waarom gebeurt dit?

Met vriendelijke groeten,

Mr. Ongeorganiseerd

Het probleem dat je tegenkomt is een ongelukkig kruispunt van twee systemen die, in gevallen als deze, een fout opleveren. Om precies te begrijpen waar de fout vandaan komt, moeten we ingaan op de geschiedenis van lange bestandsnamen (LFN) en de manier waarop Windows met hen samenwerkt voordat we in oplossingen duiken.

Lange bestandsnamen werden geïntroduceerd, via de onderliggende MS-DOS-architectuur , in Windows 95. Het nieuwe LFN-systeem toegestaan ​​bestands- en mapnamen van maximaal 255 tekens. Dit was een welkome uitbreiding van het vorige bestandsnaamsysteem, meestal 8.3 bestandsnaamgeving genoemd omdat de naam beperkt was tot acht tekens en een extensie van drie cijfers, maar ook bekend als Short Filename (SFN). Zoals je je wel kunt voorstellen, waren er toen nog steeds veel DOS-gebaseerde apps en er waren meer dan een paar hoofdpijnen die probeerden om de nieuwere LFN's en de oude SFN's leuk met elkaar te laten spelen. Als je ooit een oudere diskette of CD-ROM tegenkwam met vreemd geknipte bestanden erop (zoals abcdef ~ 1.txt), werd de bestandsnaam verkort door een SFN-gebruikende oude applicatie van wat langere en niet-ondersteunde LFN (zoals abcdefghijk. txt).

We zijn echter nog ver verwijderd van het midden van de jaren negentig en het hele lange-bestandsnaam-item is (voor het grootste deel) duidelijk gladgestreken. Als je een versie van Windows van de laatste 10 jaar gebruikt, heb je waarschijnlijk nog nooit een conflict over de duur van een bestandsnaam tegengekomen, zoals we in de DOS / Windows 95-dagen tegenkwamen. Dat gezegd hebbende, we lopen nog steeds tegen hikken aan, zoals je ontdekte met je schijfopruimingsproject. Maar waarom? Als Windows 'Long Filename-systeem mappen en bestandsnamen van maximaal 255 tekens per component ondersteunt, op welke plaats loop je dan tegen? We kunnen NTFS (het bestandssysteem dat de overgrote meerderheid van de moderne Windows-machines gebruiken) niet de schuld geven. NTFS ondersteunt namelijk het koppelen van mappen en bestandsnamen tot een totale padlengte van 32,767 tekens. Dat is veel groter dan de typische directorystructuur die de meeste gebruikers ooit nodig zouden hebben.

Waar het allemaal uit elkaar valt, is een kunstmatige beperking die Windows op het LFN / NTFS-systeem stapelt: de MAX_PATH-variabele. De variabele MAX_PATH geeft aan dat een volledige directorystructuur in Windows maximaal 260 tekens mag bevatten, inclusief de stationsletter, dubbele punt, backslash en nul-speling aan het einde. Dus je hebt alleen een potentieel reëel MAX_PATH van 256 tekens, bijvoorbeeld

C: jouw-256-karakter-pad . Dus wat er gebeurde toen je je computer aan het opruimen was, was dat je een map had met een reeds lang pad (ofwel omdat de mapnamen lang waren, de bestandsnamen lang waren of beide) en wanneer u probeerde een of meer van die mappen naar een andere map met een lang pad te verplaatsen, de totale lengte van het pad name heeft de limiet van 260 tekens overschreden die is opgelegd door de variabele MAX_PATH.

Nu denkt u misschien: "Ah-hah! We veranderen gewoon de MAX_PATH-variabele en lossen het probleem op! "Helaas is het niet zo eenvoudig. Niet alleen is de variabele MAX_PATH in feite hard gecodeerd in Windows, maar zelfs als je door het enorme gedoe ging om het te veranderen, zou je uiteindelijk zoveel breken dat het het niet waard zou zijn. Te veel toepassingen verwachten dat de padvariabele is wat Windows al lang heeft opgegeven. We kunnen er niet zomaar verandering in brengen zonder een enorme puinhoop te creëren.

Waar verlaat dat jou? Welnu, de eenvoudigste oplossing is om alleen de padgegevens te bewerken. Als u bijvoorbeeld een hoop opgeslagen artikelen hebt, waarbij de toepassing / extensie die u gebruikte om ze op te slaan van het web een map heeft gemaakt die de volledige titel van het artikel + de artikellead was, en de bestandsnaam zelf de volledige titel is van het artikel + de artikelstart, zou het heel eenvoudig zijn om de MAX_PATH te raken of te overschrijden met een enkele opslag. Het bewerken van die enorme map en artikeltitels tot een meer redelijke grootte is een gemakkelijke manier om het probleem op te lossen.

Als je een groot aantal bestanden hebt met een lang pad en je ze niet allemaal wilt bewerken (of als je wilt

een ton oude mappen verwijderen die te lang zijn voor Windows om mee om te gaan als deze wordt beperkt door de MAX_PATH-variabele), er is een opdrachtregel rond. Hoewel Windows wordt beperkt door de variabele MAX_PATH, realiseerden Windows-technici zich dat er situaties zouden zijn waarbij gebruikers langere padnamen zouden moeten verwerken. Als zodanig heeft de Windows API een functie voor het omgaan met extreem lange paden. Om te profiteren van die API en opdrachtregelprogramma's te gebruiken voor uw logge mappen / bestandsnamen, hoeft u alleen maar de mapnaam toe te voegen met een paar extra karakters. Als u bijvoorbeeld een enorme directorystructuur had die u wilde verwijderen (maar een fout ontving vanwege de padlengte toen u deze probeerde), kunt u de opdracht wijzigen van:

rmdir c: documents some-really -super-long-folder-name-scheme

to:

rmdir \? c: documents some-really-super-long-folder-name-scheme

De sleutel is de toevoeging van het

\? -gedeelte vóór het begin van het bestandspad; dit geeft Windows de opdracht de beperkingen te negeren die zijn opgelegd door de MAX_PATH-variabele en om te werken met het pad dat je zojuist hebt opgegeven, zoals rechtstreeks door het onderliggende bestandssysteem wordt geleverd / begrepen (wat een langer pad duidelijk kan ondersteunen). Wees zoals altijd voorzichtig bij de opdrachtprompt om te voorkomen dat per ongeluk bestanden of mappen worden verwijderd die u intact wilde laten.Als ons overzicht van dit probleem u nieuwsgierig maakt, moet u zeker ingaan op dit artikel uit de Microsoft Developer Network-bibliotheek, Bestanden benoemen, Paden en naamruimten voor meer informatie over wat er onder de motorkap gebeurt.

Heeft u een dringende technische vraag? Schiet ons een e-mail op en we zullen ons best doen om deze te beantwoorden.



Hoe u uw Ubuntu Linux-systeem terugzet in zijn eerdere staat

Hoe u uw Ubuntu Linux-systeem terugzet in zijn eerdere staat

Zou het niet fijn zijn om een ​​nieuwe versie van Ubuntu te kunnen uitproberen terwijl u weet dat u naar de vorige versie kunt terugkeren als u vind je het niet leuk? We laten u een hulpmiddel zien waarmee u op elk gewenst moment een momentopname van uw systeem kunt maken. TimeShift is een gratis tool die vergelijkbaar is met de functie Systeemherstel in Windows.

(how-to)

Waarom zou een SSD intern gegevens zonder wachtwoord coderen?

Waarom zou een SSD intern gegevens zonder wachtwoord coderen?

Hoewel veel mensen actief kiezen om hun gegevens te coderen, kunnen anderen verrast zijn dat hun huidige schijf dit automatisch doet zonder invoer van hen. Waarom is dat? De SuperUser Q & A-post van vandaag biedt de antwoorden op een nieuwsgierige lezer. De Question & Answer-sessie van vandaag komt tot ons dankzij SuperUser - een onderdeel van Stack Exchange, een door de gemeenschap gestuurde groep van Q & A-websites.

(how-to)