Dela via

Namngivning av filer, sökvägar och namnområden

  • Artikel

Filsystemen som stöds av Windows använder begreppet filer och kataloger för att komma åt data som lagras på en disk eller enhet. Windows-utvecklare som arbetar med Windows-API:er för fil- och enhets-I/O bör förstå regler, konventioner och begränsningar för namn för filer och kataloger.

Data kan nås från diskar, enheter och nätverksresurser med hjälp av fil-I/O-API:er. Filer och kataloger, tillsammans med namnområden, är en del av begreppet sökväg, vilket är en strängrepresentation av var data ska hämtas oavsett om de kommer från en disk eller en enhet eller en nätverksanslutning för en viss åtgärd.

Vissa filsystem, till exempel NTFS, stöder länkade filer och kataloger, som också följer namngivningskonventioner och regler för filer precis som en vanlig fil eller katalog skulle göra. För ytterligare information, se Hårda länkar och länkar och Ommonteringpunkter och filoperationer.

Mer information om hur du konfigurerar Windows för att stödja långa filsökvägar finns i Begränsning av maximal sökvägslängd.

Fil- och katalognamn

Alla filsystem följer samma allmänna namngivningskonventioner för en enskild fil: ett basfilnamn och ett valfritt tillägg, avgränsat med en punkt. Varje filsystem, till exempel NTFS, CDFS, exFAT, UDFS, FAT och FAT32, kan dock ha specifika och olika regler om bildandet av enskilda komponenter i sökvägen till en katalog eller fil. Observera att en katalog helt enkelt är en fil med ett särskilt attribut som anger den som en katalog, men annars måste följa samma namngivningsregler som en vanlig fil. Eftersom termen katalog bara refererar till en särskild typ av fil när det gäller filsystemet, använder vissa referensmaterial den allmänna termen fil för att omfatta både begreppen kataloger och datafiler som sådana. På grund av detta, om inget annat anges, bör alla namngivnings- eller användningsregler eller exempel för en fil också gälla för en katalog. Termen sökväg refererar till en eller flera kataloger, backstreck och eventuellt ett volymnamn. Mer information finns i avsnittet Sökvägar.

Begränsningar för antal tecken kan också vara olika och kan variera beroende på vilket filsystem och sökvägsnamnsprefixformat som används. Detta kompliceras ytterligare av stöd för bakåtkompatibilitetsmekanismer. Till exempel stöder det äldre MS-DOS FAT-filsystemet högst 8 tecken för basfilnamnet och 3 tecken för tillägget, för totalt 12 tecken, inklusive punktavgränsaren. Detta kallas ofta för ett 8.3-filnamn. Windows FAT- och NTFS-filsystemen är inte begränsade till 8.3-filnamn, eftersom de har långt filnamnsstöd, men de stöder fortfarande 8.3-versionen av långa filnamn.

Namngivning

Följande grundläggande regler gör det möjligt för program att skapa och bearbeta giltiga namn för filer och kataloger, oavsett filsystem:

  • Använd en punkt för att separera basfilnamnet från tillägget i namnet på en katalog eller fil.

  • Använd ett omvänt snedstreck (\) för att separera -komponenterna i en sökväg. Backslash delar filnamnet från dess sökväg och ett katalognamn från ett annat katalognamn i en sökväg. Du kan inte använda ett omvänt snedstreck i namnet på den faktiska filen eller katalogen eftersom det är ett reserverat tecken som separerar namnen i komponenter.

  • Använd ett omvänt snedstreck som krävs som en del av volymnamn, till exempel "C:\" i "C:\path\file" eller "\\server\share" i "\\server\share\path\file" för UNC-namn (Universal Naming Convention). Mer information om UNC-namn finns i avsnittet Maximal banlängdsbegränsning.

  • Anta inte skiftlägeskänslighet. Tänk till exempel på att namnen OSCAR, Oscar och Oscar är desamma, även om vissa filsystem (till exempel ett POSIX-kompatibelt filsystem) kan betrakta dem som olika. Observera att NTFS stöder POSIX-semantik för skiftlägeskänslighet, men detta är inte standardbeteendet. Mer information finns i CreateFile.

  • Volymbeteckningar (drivbokstäver) är i likhet med skiftlägesokänsliga. Till exempel refererar "D:\" och "d:\" till samma volym.

  • Använd alla tecken på den aktuella kodsidan för ett namn, inklusive Unicode-tecken och tecken i den utökade teckenuppsättningen (128–255), förutom följande:

    • Följande reserverade tecken:

      • < (mindre än)
      • > (större än)
      • : (kolon)
      • " (dubbelt citattecken)
      • / (snedstreck)
      • \ (omvänt snedstreck)
      • | (lodrät stapel eller rör)
      • ? (frågetecken)
      • * (asterisk)

    • Heltalsvärde noll, kallas ibland ASCII NUL- tecken.

    • Tecken vars heltalsrepresentationer finns i intervallet 1 till 31, förutom alternativa dataströmmar där dessa tecken tillåts. Mer information om filströmmar finns i File Streams.

    • Andra tecken som målfilsystemet inte tillåter.

  • Använd en punkt som en katalog komponent i en sökväg för att representera den aktuella katalogen, till exempel ".\temp.txt". Mer information finns i Sökvägar.

  • Använd två efterföljande perioder (..) som en katalog komponent i en sökväg för att representera den överordnade katalogen, till exempel "..\temp.txt". Mer information finns i Sökvägar.

  • Använd inte följande reserverade namn för namnet på en fil:

    CON, PRN, AUX, NUL, COM0, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, COM¹, COM², COM³, LPT0, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, LPT9, LPT¹, LPT² och LPT³. Undvik också dessa namn följt omedelbart av ett tillägg; till exempel är NUL.txt och NUL.tar.gz båda likvärdiga med NUL. Mer information finns i Namnområden.

    Obs

    Windows identifierar 8-bitars ISO/IEC 8859-1 upphöjda siffror ¹, ² och ³ som siffror och behandlar dem som giltiga delar av COM# och LPT#-enhetsnamn, vilket gör dem reserverade i varje katalog. echo test > COM¹ kan till exempel inte skapa en fil.

  • Avsluta inte ett fil- eller katalognamn med ett blanksteg eller en punkt. Även om det underliggande filsystemet kan ha stöd för sådana namn, gör inte Windows-gränssnittet och användargränssnittet det. Det är dock accepterat att ange en punkt som det första tecknet i ett namn. Till exempel ".temp".

Korta eller långa namn

Ett långt filnamn anses vara ett filnamn som överskrider den korta MS-DOS (kallas även 8.3) formatnamnskonvention. När du skapar ett långt filnamn kan Windows också skapa en kort 8.3-form av namnet, som kallas 8.3-alias eller kort namn och lagra det på disk också. Detta 8.3-alias kan inaktiveras av prestandaskäl, antingen systemomfattande eller för en angiven volym, beroende på det specifika filsystemet.

Windows Server 2008, Windows Vista, Windows Server 2003 och Windows XP: 8.3-alias kan inte inaktiveras för angivna volymer förrän Windows 7 och Windows Server 2008 R2.

I många filsystem innehåller ett filnamn en tilde (~) inom varje komponent i namnet som är för långt för att följa namngivningsreglerna 8.3.

Not

Alla filsystem följer inte tilde-ersättningskonventionen och system kan konfigureras för att inaktivera 8.3 aliasgenerering även om de normalt stöder det. Anta därför inte att 8.3-aliaset redan finns på disken.

Om du vill begära 8.3-filnamn, långa filnamn eller den fullständiga sökvägen för en fil från systemet bör du överväga följande alternativ:

  • Om du vill hämta 8.3-formen av ett långt filnamn använder du funktionen GetShortPathName.
  • Om du vill hämta den långa filnamnsversionen av ett kort namn använder du funktionen GetLongPathName.
  • Om du vill hämta den fullständiga sökvägen till en fil använder du funktionen GetFullPathName.

I nyare filsystem, till exempel NTFS, exFAT, UDFS och FAT32, lagrar Windows de långa filnamnen på disken i Unicode, vilket innebär att det ursprungliga långa filnamnet alltid bevaras. Detta gäller även om ett långt filnamn innehåller utökade tecken, oavsett vilken kodsida som är aktiv under en diskläsnings- eller skrivåtgärd.

Filer med långa filnamn kan kopieras mellan NTFS-filsystempartitioner och Windows FAT-filsystempartitioner utan att förlora någon filnamnsinformation. Detta gäller kanske inte för äldre MS-DOS FAT och vissa typer av CDFS-filsystem (CD-ROM) beroende på det faktiska filnamnet. I det här fallet ersätts det korta filnamnet om möjligt.

Sökvägar

Den sökvägen till en angiven fil består av en eller flera komponenter, avgränsade med ett specialtecken (ett omvänt snedstreck), där varje komponent vanligtvis är ett katalognamn eller filnamn, men med några viktiga undantag som beskrivs nedan. Det är ofta viktigt för systemets tolkning av en sökväg hur början, eller prefixet, för sökvägen ser ut. Det här prefixet avgör namnrymd sökvägen använder, och dessutom vilka specialtecken som används i vilken position inom sökvägen, inklusive det sista tecknet.

Om en komponent i en sökväg är ett filnamn måste den vara den sista komponenten.

Varje komponent i en sökväg begränsas också av den maximala längd som anges för ett visst filsystem. I allmänhet finns dessa regler i två kategorier: korta och långa. Observera att katalognamn lagras av filsystemet som en särskild typ av fil, men namngivningsregler för filer gäller även för katalognamn. Sammanfattningsvis är en sökväg bara strängrepresentationen av hierarkin mellan alla kataloger som finns för ett visst fil- eller katalognamn.

Fullständigt kvalificerade kontra relativa sökvägar

För Windows API-funktioner som manipulerar filer kan filnamn ofta vara relativa till den aktuella katalogen, medan vissa API:er kräver en fullständigt kvalificerad sökväg. Ett filnamn är relativt till den aktuella katalogen om det inte börjar med något av följande:

  • Ett UNC-namn för valfritt format, som alltid börjar med två omvänt snedstreck ("\\"). Mer information finns i nästa avsnitt.
  • En diskdesignator med ett backslash, till exempel "C:\" eller "d:\".
  • Ett enda omvänt snedstreck, till exempel "\directory" eller "\file.txt". Detta kallas även för en absolut sökväg.

Om ett filnamn bara börjar med en diskdesignator men inte omvänt snedstreck efter kolonet tolkas det som en relativ sökväg till den aktuella katalogen på enheten med den angivna bokstaven. Observera att den aktuella katalogen kanske inte är rotkatalogen beroende på vad den har angetts till under den senaste åtgärden "ändra katalog" på disken. Exempel på det här formatet är följande:

  • "C:tmp.txt" refererar till en fil med namnet "tmp.txt" i den aktuella katalogen på enhet C.
  • "C:tempdir\tmp.txt" refererar till en fil i en underkatalog till den aktuella katalogen på enhet C.

En sökväg sägs också vara relativ om den innehåller "dubbelpunkt"; det vill säga: två punkter tillsammans i en komponent av sökvägen. Den här specialspecificeraren används för att ange katalogen ovanför den aktuella katalogen, även kallad "överordnad katalog". Exempel på det här formatet är följande:

  • "..\tmp.txt" anger en fil med namnet tmp.txt som finns i den överordnade katalogen.
  • "..\..\tmp.txt" anger en fil som är två kataloger ovanför den aktuella katalogen.
  • "..\tempdir\tmp.txt" anger en fil med namnet tmp.txt som finns i en katalog med namnet tempdir som är en peer-katalog till den aktuella katalogen.

Relativa sökvägar kan kombinera båda exempeltyperna, till exempel "C:..\tmp.txt". Detta är användbart eftersom även om systemet håller reda på den aktuella enheten tillsammans med den aktuella katalogen på enheten, håller det också reda på de aktuella katalogerna i var och en av de olika enhetsbeteckningarna (om systemet har fler än en), oavsett vilken enhetsdesignator som anges som den aktuella enheten.

Begränsning av maximal sökvägslängd

I utgåvor av Windows före Windows 10 version 1607 är den maximala längden för en sökväg MAX_PATH, som definieras som 260 tecken. I senare versioner av Windows måste du ändra en registernyckel eller använda grupprincipverktyget för att ta bort gränsen. Se Maximal sökvägslängdsbegränsning för fullständig information.

Namnområden

Det finns två huvudkategorier av namnområdeskonventioner som används i Windows-API:erna, som vanligtvis kallas NT-namnområden och Win32-namnområden. NT-namnområdet utformades för att vara den lägsta nivåns namnområde där andra undersystem och namnområden kunde finnas, inklusive Win32-undersystemet och, i tillägg, Win32-namnrymderna. POSIX är ett annat exempel på ett undersystem i Windows som är byggt ovanpå NT-namnområdet. Tidiga versioner av Windows definierade också flera fördefinierade eller reserverade namn för vissa särskilda enheter, till exempel kommunikationsportar (seriell och parallell) och standardvisningskonsolen som en del av det som nu kallas NT-enhetens namnområde, och stöds fortfarande i aktuella versioner av Windows för bakåtkompatibilitet.

Win32-filnamnområden

Prefixet och konventionerna för Win32-namnområdet sammanfattas i det här avsnittet och i följande avsnitt, med beskrivningar av hur de används. Observera att de här exemplen är avsedda att användas med Windows API-funktionerna och att alla inte nödvändigtvis fungerar med Windows-gränssnittsprogram som Utforskaren i Windows. Därför finns det ett bredare utbud av möjliga sökvägar än vad som vanligtvis är tillgängligt från Windows-gränssnittsprogram, och Windows-program som drar nytta av detta kan utvecklas med hjälp av dessa namnområdeskonventioner.

För fil-I/O anger prefixet "\\?\" till en sökvägssträng att Windows-API:erna inaktiverar all strängparsning och skickar strängen som följer den direkt till filsystemet. Om filsystemet till exempel stöder stora sökvägar och filnamn kan du överskrida de MAX_PATH gränser som annars tillämpas av Windows-API:erna.

Eftersom den inaktiverar automatisk utökning av sökvägssträngen tillåter prefixet "\\?\" även användning av ".." och "." i sökvägsnamnen, vilket kan vara användbart om du försöker utföra åtgärder på en fil med dessa annars reserverade relativa sökvägsspecificerare som en del av den fullständigt kvalificerade sökvägen.

Många men inte alla fil-I/O-API:er stöder "\\?\"; Du bör titta på referensavsnittet för varje API för att vara säker.

Observera att Unicode-API:er ska användas för att kontrollera att prefixet "\\?\" tillåter att du överskrider MAX_PATH.

Win32-enhetsnamnområden

Prefixet "\\.\" kommer åt Win32-enhetens namnområde i stället för Win32-filnamnområdet. Det är så här åtkomsten till fysiska diskar och volymer uppnås direkt, utan att gå igenom filsystemet, om API:et stöder den här typen av åtkomst. Du kan komma åt många andra enheter än diskar på det här sättet (med hjälp av funktionerna CreateFile och DefineDosDevice).

Om du till exempel vill öppna systemets seriekommunikationsport 1 kan du använda "COM1" i anropet till funktionen CreateFile. Detta fungerar eftersom COM1–COM9 är en del av de reserverade namnen i NT-namnområdet, även om prefixet "\\.\" också fungerar med dessa enhetsnamn. Om du har ett 100-portars serieexpansionskort installerat och vill öppna COM56 kan du inte öppna det med "COM56" eftersom det inte finns någon fördefinierad NT-namnrymd för COM56. Du måste öppna den med "\\.\COM56" eftersom "\\.\" går direkt till enhetens namnområde utan att försöka hitta ett fördefinierat alias.

Ett annat exempel på hur du använder Win32-enhetens namnområde är funktionen CreateFile med funktionen "\\.\PhysicalDriveX" (där X är ett giltigt heltalsvärde) eller "\\.\CdRomX". På så sätt kan du komma åt enheterna direkt och kringgå filsystemet. Detta fungerar eftersom dessa enhetsnamn skapas av systemet eftersom dessa enheter räknas upp, och vissa drivrutiner skapar även andra alias i systemet. Enhetsdrivrutinen som implementerar namnet "C:\" har till exempel ett eget namnområde som också råkar vara filsystemet.

API:er som går igenom funktionen CreateFile fungerar vanligtvis med prefixet "\\.\" eftersom CreateFile är funktionen som används för att öppna både filer och enheter, beroende på vilka parametrar du använder.

Om du arbetar med Windows API-funktioner bör du använda prefixet "\\.\" för att endast komma åt enheter och inte filer.

De flesta API:er stöder inte "\\.\"; endast de som är utformade för att fungera med enhetens namnområde kommer att känna igen den. Kontrollera alltid referensavsnittet för varje API för att vara säker.

NT-namnområden

Det finns också API:er som tillåter användning av NT-namnområdeskonventionen, men Windows Object Manager gör det onödigt i de flesta fall. För att illustrera är det användbart att bläddra i Windows-namnrymderna i systemobjektets webbläsare med hjälp av verktyget Windows Sysinternals WinObj. När du kör det här verktyget ser du NT-namnområdet som börjar vid roten eller "\". Undermappen "Global??" är den plats där Win32-namnområdet finns. Namngivna enhetsobjekt finns i NT-namnområdet i underkatalogen "Enhet". Här kan du också hitta Serial0 och Serial1, enhetsobjekten som representerar de två första COM-portarna om de finns i systemet. Ett enhetsobjekt som representerar en volym skulle likna "HarddiskVolume1", även om det numeriska suffixet kan variera. Namnet "DR0" under underkatalogen "Harddisk0" är ett exempel på enhetsobjektet som representerar en disk och så vidare.

För att göra dessa enhetsobjekt tillgängliga för Windows-program skapar enhetsdrivrutinerna en symbolisk länk (symlink) i Win32-namnområdet, "Global??", till sina respektive enhetsobjekt. COM0 och COM1 under underkatalogen "Global??" är till exempel bara symlänkar till Serial0 och Serial1, "C:" är en symlink till HarddiskVolume1, "Physicaldrive0" är en symlink till DR0 och så vidare. Utan en symlink kommer en angiven enhet "Xxx" inte att vara tillgänglig för något Windows-program som använder Win32-namnområdeskonventioner enligt beskrivningen tidigare. Ett handtag kan dock öppnas för enheten med hjälp av api:er som stöder den absoluta sökvägen för NT-namnområdet i formatet "\Device\Xxx".

Med tillägg av stöd för flera användare via Terminal Services och virtuella datorer har det blivit nödvändigt att virtualisera den systemomfattande rotenheten i Win32-namnområdet. Detta uppnåddes genom att lägga till symlinken med namnet "GLOBALROOT" i Win32-namnområdet, som du kan se i underkatalogen "Global??" i WinObj-webbläsarverktyget som tidigare diskuterats och kan komma åt via sökvägen "\\?\GLOBALROOT". Det här prefixet ser till att sökvägen efter den hittas i det riktiga rotvägen för systemobjekthanteraren och inte en sessionsberoende sökväg.

Se även