Understanding File Paths
Here, you will go-through series points which depicits different file-paths formats which is needed to understand in arranging the different types of folder(s) {file(s) inside the folders} whenever you're going to install the external softwares for your project mainly for Programming/Coding Perspectives.
In your coding, these paths formats will make your work a lot-easier and you can structure your Project-Folders as-per your choice and moreover like REACT.js NODE.js ANGULAR.ts ANDROID when you wants to create your project then through command-shell you could downlaod them and also sometimes from the link associated with softwares and it will save automatically or tooks time in downloading-&-installation, to the desired location in your computer-system (THIS IS THE CONFIGURATION, which is in-built) and with the help of Opearting-System you can easily reach to those locations and you obsever the path in your OSs ADDRESS-BAR, that path is the way to connect your project with download software(s) of your choice.
I'm also covering Types of Folders created when someone desired to install desired FRAMEWORK OR LIBRARY for his/her project from the Server(Internet).
Lets go through the points now,
C:" drive.Both specify the optional volume specifier (C: in both cases), but the first begins with the root of the specified volume, whereas the second does not. As result, the first is an absolute path from the root directory of drive C:, whereas the second is a relative path from the current directory of drive C:. Use of the second form when the first is intended is a common source of bugs that involve Windows file paths.
UNC Paths (Universal Naming Convention) are standard network path formats, like \\server\share\folder\file.txt, used in Windows to locate shared resources (files, folders, printers) on a local network by specifying the server name and the shared resource's path, crucial for network access without needing mapped drives. They begin with two backslashes (\\), followed by the computer/server name, then the shared folder name, and finally the file or subfolder, enabling direct access to network resources across different applications.
Anatomy of a UNC Path
\\ : Double backslash indicates the start of a UNC path.server : The name of the computer hosting the shared resource.sharedfolder : The name of the folder shared on the network.file.txt / subfolder : The specific file or subfolder within the share. Examples
\\MyFileServer\Documents\Report.docx\\BackupNAS\Photos\\PrintServer\OfficePrinter (printers also use UNC) Key Uses & Benefits
Where They're Used
A Universal Naming Convention (UNC) path is a standard format for specifying the location of resources, such as shared files and printers, on a local area network (LAN). It provides a consistent, network-wide address that does not rely on local, user-specific mapped drive letters.
UNC Path Format and Structure
A UNC path uses the following syntax, utilizing double backslashes to begin the path on Windows systems:
\\\\<server-name>\\<share-name>\\<optional-path-to-resource>
Key components include:
\\<server-name>: The hostname or IP address of the computer hosting the resource on the network.\\<share-name>: The name of the specific folder or resource (like a printer) that has been explicitly shared on the host machine.\\<optional-path-to-resource>: Any subsequent directories and the final filename, if applicable. For example, a file named test.txt in a folder Reports within a share MyShare on a server named FileServer would have the UNC path: \\\\FileServer\\MyShare\\Reports\\test.txt.
Key Characteristics and Use Cases
C:\Folder\File.txt) is the absence of a drive letter. Finding a UNC Path
If you have a mapped drive and need its corresponding UNC path, you can use the command prompt in Windows:
net use and press Enter.We can explore how to set up a shared folder on your computer so that it can be accessed by a UNC path on your network.
A Universal Naming Convention (UNC) path is a standardized format used in Windows to specify the location of shared resources, such as files, folders, or printers, on a local area network (LAN). UNC paths provide a consistent and reliable way to access network resources without relying on user-specific drive mappings.
UNC Path Format and Examples
The standard format for a UNC path is \\ServerName\ShareName\Path\FileName.
| Component | Description |
|---|---|
\\ |
Indicates the start of a UNC path. |
ServerName |
The name or IP address of the computer hosting the resource. |
ShareName |
The name assigned to the specific folder or resource that has been shared on the network. |
Path\FileName |
The optional directory path and file name within the shared folder. |
Examples:
report.docx in a shared folder named Documents on a server named HQ-Server, the UNC path would be \\HQ-Server\Documents\report.docx.Printer1 on a server named PrintServer, the UNC path would be \\PrintServer\Printer1. Key Differences from Mapped Drives
While users often access network resources via a mapped network drive (e.g., N:), which is a local drive letter assigned to a network location, the underlying addressing uses a UNC path.
How to Find a UNC Path
You can find the UNC path corresponding to a mapped drive using the Command Prompt:
cmd in the Windows search bar and press Enter).net use and press Enter.Would you like some tips on how to set up a shared folder on your network to use UNC paths? We can walk through those steps next.
| Path | Description |
|---|---|
\\system07\C$\ |
The root directory of the C: drive on system07. |
\\Server2\Share\Test\Foo.txt |
The Foo.txt file in the Test directory of the \\Server2\Share volume. |
UNC paths must always be fully qualified. They can include relative directory segments (. and ..), but these must be part of a fully qualified path. You can use relative paths only by mapping a UNC path to a drive letter.
DOS device paths are special path formats in Windows that access the underlying object manager namespace, bypassing standard file path parsing. They are primarily used to interact directly with hardware devices, bypass file path length limits, or perform operations on legacy DOS device names.
Standard DOS Paths
Traditional DOS paths consist of a volume, directory names, and an optional filename, using a backslash (\) as a separator.
C:\Documents\Newsletters\Summer2018.pdf..\Publications\TravelBrochure.pdf (moves up one level) or 2018\January.xlsxCON (console), LPT1 (printer port), COM1 (serial port), and NUL (nowhere). DOS Device Path Syntax
The special syntax, often referred to as the "extended-length path" or "Win32 device namespace" syntax, starts with a specific specifier.
| Prefix | Description |
|---|---|
\\.\ |
Accesses the device namespace; typically used for direct hardware access (e.g., \\.\PhysicalDrive1). Paths with this prefix are subject to standard path normalization (e.g., resolving . and ..). |
\\?\ |
Accesses the file namespace and bypasses all automatic path string parsing and normalization. This prefix allows for paths exceeding the traditional 260-character MAX_PATH limit and permits operations on files with otherwise illegal names (e.g., a folder named CON). |
Key Characteristics
. or ..).\\?\Volume{b75e2c83-0000-0000-0000-602f00000000}\Test\Foo.txt.UNC specifier: \\?\UNC\Server\Share\path\file.txt.The DOS device path consists of the following components:
The device path specifier (\\.\ or \\?\), which identifies the path as a DOS device path.
A symbolic link to the "real" device object (C: in the case of a drive name, or Volume{b75e2c83-0000-0000-0000-602f00000000} in the case of a volume GUID).
The first segment of the DOS device path after the device path specifier identifies the volume or drive. (For example, \\?\C:\ and \\.\BootPartition\.)
There is a specific link for UNCs that is called, not surprisingly, UNC. For example:
\\.\UNC\Server\Share\Test\Foo.txt \\?\UNC\Server\Share\Test\Foo.txt
For device UNCs, the server/share portion forms the volume. For example, in \\?\server1\utilities\\filecomparer\, the server/share portion is server1\utilities. This is significant when calling a method such as Path.GetFullPath(String, String) with relative directory segments; it is never possible to navigate past the volume. DOS device paths are fully qualified by definition and can't begin with a relative directory segment (. or ..). Current directories never enter into their usage.
Almost all paths passed to Windows APIs are normalized. During normalization, Windows performs the following steps:
. for the current directory and .. for the parent directory).The first step in path normalization is identifying the type of path. Paths fall into one of a few categories:
\\? or \\.).C:\).CON, LPT1).\).C:).temp\testfile.txt).The type of the path determines whether or not a current directory is applied in some way. It also determines what the "root" of the path is.
If the path is a legacy DOS device such as CON, COM1, or LPT1, it is converted into a device path by prepending \\.\ and returned.
Prior to Windows 11, a path that begins with a legacy device name is always interpreted as a legacy device by the Path.GetFullPath(String) method. For example, the DOS device path for CON.TXT is \\.\CON, and the DOS device path for COM1.TXT\file1.txt is \\.\COM1. Because this no longer applies with Windows 11, specify the full path to the legacy DOS device, such as \\.\CON.
If a path isn't fully qualified, Windows applies the current directory to it. UNCs and device paths don't have the current directory applied. Neither does a full drive with separator C:\.
If the path starts with a single component separator, the drive from the current directory is applied. For example, if the file path is \utilities and the current directory is C:\temp\, normalization produces C:\utilities.
If the path starts with a drive letter, volume separator, and no component separator, the last current directory set from the command shell for the specified drive is applied. If the last current directory wasn't set, the drive alone is applied. For example, if the file path is D:sources, the current directory is C:\Documents\, and the last current directory on drive D: was D:\sources\, the result is D:\sources\sources. These "drive relative" paths are a common source of program and script logic errors. Assuming that a path beginning with a letter and a colon isn't relative is obviously not correct.
If the path starts with something other than a separator, the current drive and current directory are applied. For example, if the path is filecompare and the current directory is C:\utilities\, the result is C:\utilities\filecompare\.
All forward slashes (/) are converted into the standard Windows separator, the back slash (\). If they are present, a series of slashes that follow the first two slashes are collapsed into a single slash.
As the path is processed, any components or segments that are composed of a single or a double period (. or ..) are evaluated:
For a single period, the current segment is removed, since it refers to the current directory.
For a double period, the current segment and the parent segment are removed, since the double period refers to the parent directory.
Parent directories are only removed if they aren't past the root of the path. The root of the path depends on the type of path. It is the drive (C:\) for DOS paths, the server/share for UNCs (\\Server\Share), and the device path prefix for device paths (\\?\ or \\.\).
Along with the runs of separators and relative segments removed earlier, some additional characters are removed during normalization:
If a segment ends in a single period, that period is removed. (A segment of a single or double period is normalized in the previous step. A segment of three or more periods isn't normalized and is actually a valid file/directory name.)
If the path doesn't end in a separator, all trailing periods and spaces (U+0020) are removed. If the last segment is simply a single or double period, it falls under the relative components rule above.
This rule means that you can create a directory name with a trailing space by adding a trailing separator after the space.
Normally, any path passed to a Windows API is (effectively) passed to the GetFullPathName function and normalized. There is one important exception: a device path that begins with a question mark instead of a period. Unless the path starts exactly with \\?\ (note the use of the canonical backslash), it is normalized.
Why would you want to skip normalization? There are three major reasons:
To get access to paths that are normally unavailable but are legal. A file or directory called hidden., for example, is impossible to access in any other way.
To improve performance by skipping normalization if you've already normalized.
On .NET Framework only, to skip the MAX_PATH check for path length to allow for paths that are greater than 259 characters. Most APIs allow this, with some exceptions.
Skipping normalization and max path checks is the only difference between the two device path syntaxes; they are otherwise identical. Be careful with skipping normalization, since you can easily create paths that are difficult for "normal" applications to deal with.
Paths that start with \\?\ are still normalized if you explicitly pass them to the GetFullPathName function.
You can pass paths of more than MAX_PATH characters to GetFullPathName without \\?\. It supports arbitrary length paths up to the maximum string size that Windows can handle.
A peculiarity of the Windows file system that non-Windows users and developers find confusing is that path and directory names are case-insensitive. That is, directory and file names reflect the casing of the strings used when they are created. For example, the method call
C#
Directory.Create("TeStDiReCtOrY");
creates a directory named TeStDiReCtOrY. If you rename a directory or file to change its case, the directory or file name reflects the case of the string used when you rename it. For example, the following code renames a file named test.txt to Test.txt:
C#
using System.IO;
class Example3
{
static void Main()
{
var fi = new FileInfo(@".\test.txt");
fi.MoveTo(@".\Test.txt");
}
}
However, directory and file name comparisons are case-insensitive. If you search for a file named "test.txt", .NET file system APIs ignore case in the comparison. "Test.txt", "TEST.TXT", "test.TXT", and any other combination of uppercase and lowercase letters will match "test.txt".
Now, I'm writing pseudo-code(s) and algorithm(s) to see how many steps are their for PATH-NORMALIZATION.