A file path is a textual representation of the location of a file or other filesystem object within a directory hierarchy or namespace. It tells an operating system, application or user how to identify a particular object by traversing directories or other namespace components. A path can be absolute, such as /home/alex/report.txt on a Unix-like system or C:\Users\Alex\Documents\report.txt on Windows, or relative, such as Documents/report.txt when interpreted from an appropriate current directory. Paths are fundamental to filesystem access because a filename alone is usually insufficient to identify an object uniquely. Thousands of directories can contain files with the same name, whereas the combination of directory hierarchy and filename normally provides a specific reference.
An absolute path identifies an object from a defined root or namespace starting point. Unix-like systems normally use a single root represented by /, from which paths descend through directories. Windows commonly has drive-letter namespaces such as C:, although modern Windows also supports other namespaces, UNC paths and device-related paths. A relative path instead depends on context. If the current working directory is /home/alex/project, then a relative path such as src/main.c refers to /home/alex/project/src/main.c. Relative paths are useful because software can operate independently of a fixed installation location, but they can also create ambiguity or security problems when the current directory is unexpected.
Path syntax differs between operating systems and filesystems. Unix-like systems conventionally use the forward slash as a separator, while Windows traditionally uses the backslash. Windows APIs and many programming environments also accept forward slashes in some circumstances, but applications should follow the semantics of the relevant API rather than assuming that all path strings are interchangeable. Windows supports drive letters such as C:, network UNC paths such as \server\share, and various special path namespaces. Unix-like systems can also use mount points, symbolic links and virtual filesystems, meaning that a path's apparent hierarchy does not necessarily correspond directly to physical disk organisation. Cross-platform software therefore needs deliberate path handling rather than simply concatenating strings containing platform-specific separators.
Paths can contain special components. The single-dot component commonly represents the current directory, while two dots represent the parent directory in conventional Unix-like and Windows path semantics. Thus, ../image.png means that image.png is located in the parent directory relative to the current location. Path normalisation can resolve such components and remove redundant separators, but symbolic links complicate the concept because a syntactically normalised path is not necessarily equivalent to resolving every symbolic link in the filesystem.
A path can also refer to a symbolic link rather than directly to the target object, and applications may need to distinguish lexical path normalisation from filesystem-aware resolution. These distinctions are important in security-sensitive software because careless path handling can permit traversal outside an intended directory.
File paths are used by shells, graphical file managers, programming languages, APIs, configuration files, databases and web applications. A command-line utility may accept a path as an argument, while a programming API might provide functions for opening a path, creating a directory or enumerating its contents.
Web URLs can resemble filesystem paths but are not necessarily filesystem paths; a URL identifies a resource within a web addressing system, while a filesystem path identifies an object within a local or mounted namespace. Some web servers map URL paths to filesystem paths, but this is an application-level mapping rather than a universal equivalence. Confusing URLs and filesystem paths can cause both programming errors and security vulnerabilities.
Path security is particularly important when software handles user-supplied filenames. A path traversal attack can occur when an application accepts a path such as .. /../secret.txt and uses it without ensuring that the resulting target remains inside an authorised directory. Secure applications commonly canonicalise or otherwise safely resolve paths, restrict permitted locations and avoid treating untrusted strings as unrestricted filesystem references. Security also requires consideration of symbolic links, alternate path syntaxes, case sensitivity, device namespaces, mount points and race conditions. Checking a path and subsequently using it can be unsafe if an attacker can alter the filesystem between those operations, so security-sensitive code may need operating-system facilities that bind access to specific directory handles or file descriptors.
Paths also have different meanings depending on whether they refer to local storage, network resources or virtual namespaces. A Unix mount point can make a remote or separate filesystem accessible beneath an ordinary directory path. Windows UNC paths can identify network shares rather than local disks. Containers can provide processes with a restricted filesystem namespace in which / may represent a container-specific root rather than the host's root filesystem. Virtual environments and sandboxing mechanisms can similarly alter what a process can see. Consequently, an identical textual path can identify different objects in different execution contexts, and a path should always be interpreted relative to the namespace in which it is being used.
A file path should therefore be distinguished from a filename, a directory and the physical location of data. A filename is one name component, a directory is an organisational namespace object, and a path combines components to identify an object. The physical blocks containing the object's data may be scattered across a storage device, stored on an SSD, provided by a virtual disk or located on another machine. The path does not encode those physical details. Understanding paths is essential for file management, software development, operating-system administration and security because paths form the bridge between human-readable filesystem organisation and the operating system interfaces that locate and manipulate filesystem objects.
