Home
Pathwinder redirects file operations from one location to another in a way that is completely transparent to the application. It does so by hooking low-level Windows system calls and modifying them, subject to the control of the user-supplied redirection rules with which it is configured.
The application itself sees a completely consistent, but potentially illusionary, view of the filesystem. It continues to issue its file operation requests as usual, and Pathwinder will apply the redirection rules and potentially redirect these requests to other filesystem locations without the application being aware.
Pathwinder is implemented as a hook module and needs to be loaded into an application using Hookshot. It acts on existing 32-bit (x86) and 64-bit (x64) Windows applications.
A natural question after reading a basic description of Pathwinder's functionality is, "how is this different from something like a symbolic link?"
Pathwinder can behave in a way that is similar to using a filesystem link, such as a symbolic link, but that is the simplest and most basic way of configuring it. Even then, Pathwinder is different:
-
On Windows, creating filesystem links generally requires administrative privileges. Pathwinder does not impose this requirement.
- Windows might demand administrative privileges when writing Pathwinder's configuration file, depending on where it is located.
-
Pathwinder works where filesystem links do not. Because filesystem links themselves are special objects that require support from the underlying filesystem, they are not suitable for all situations. For example, the filesystems typically used on removable storage devices like USB keys do not support filesystem links, but Pathwinder would work without issue in that setting.
-
Making a filesystem link is a system-wide change, visible to all applications that access it. Pathwinder, on the other hand, does not make any persistent changes to the filesystem, nor does it make any system-wide changes whatsoever. Pathwinder only redirects file operations for those applications that the end user has configured, and even then, only while they are running.
Pathwinder additionally offers several features that cannot be replicated by using filesystem links alone.
-
A filesystem link for a directory redirects all filesystem operations that access that directory. This is not necessarily true for Pathwinder; it supports file patterns so that only those filenames that match the patterns are redirected.
-
Pathwinder supports an "overlay" mode that has the effect of merging the contents of multiple directories so they all appear to be part of the same directory.
- This is very similar to how an overlay filesystem works, except that Pathwinder is not limited to merging just two directories.
-
Unlike filesystem links, which use a fixed origin and target path, Pathwinder determines the origin and target of redirections dynamically and at run-time.
- This means that, if Pathwinder is configured correctly, two different users logged into the same machine could run the same program at the exact same time and Pathwinder would be able to redirect file operations differently for each (such as to their own per-user locations).
Pathwinder supports all of the 32-bit (x86) and 64-bit (x64) Windows applications that Hookshot supports. It offers the ability to:
- Redirect entire directories from one location to another
- Redirect only specific files within a directory from one location to another
- Overlay the partial or complete contents of one directory onto another
- Present illusionary directories to applications that do not actually exist in the real filesystem
Applications are presented with a consistent view of the filesystem regardless of the type of filesystem requests they make, including:
- Direct requests for a specific file by name (for example, open the file C:\SomeDirectory\File.txt)
- Enumeration of directory contents (for example, list all the files that are present in C:\SomeDirectory)
All of Pathwinder's functionality is configurable via a configuration file. Because Pathwinder hooks low-level Windows system calls, the affected application is not aware of the changes Pathwinder is making. Pathwinder makes no persistent or system-wide changes, including to the filesystem, in order to implement redirection.
As a hook module, Pathwinder is subject to the same limitations as Hookshot. Pathwinder cannot operate in any way whatsoever on existing, already-running processes. Pathwinder is also limited in scope to just those applications into which it is loaded with the explicit permission of the end user. It makes no attempts to hide its presence (in fact, as a hook module, it does the opposite), and it is incapable of making system-wide or persistent changes. All of these limitations are by design.
Pathwinder uses filesystem rules, which are defined in a configuration file, to know how and when it should redirect a file operation from one location to another. Filesystem rules themselves are identified by name and defined using an origin directory, a target directory, and an optional set of file patterns.
The easiest way to understand how a filesystem rule functions is this: if the application issues a file operation for a path that is located in the origin directory then the file operation is redirected to the target directory. The term origin directory refers to the point of origin, or the source location, of a possible redirection, and the term target directory accordingly refers to the destination location of a possible redirection. File accesses issued by an application are checked against origin directories and, if they match, they are redirected to the equivalent hierarchy location rooted at the target directory.
Filesystem rules are additionally allowed to use file patterns to limit their scope to a subset of files in the origin directory instead of acting on the entire directory. A filesystem rule that uses one or more file patterns would only redirect filesystem operations from the origin directory to the target directory if their names match any of the defined file patterns.
We begin with the filesystem hierarchy shown below.
The application is located at C:\MyApp\App.exe. Suppose we use Pathwinder, and we define a filesystem rule as follows.
- Origin directory = C:\MyApp\DataSubdir (note that this directory does not need to exist)
- Target directory = C:\MyDataFolder
When executed with this configuration, the application's view of the filesystem, which is an illusion created by Pathwinder, is as shown below.
Here, the entire contents of C:\MyDataFolder are presented to the application as existing in C:\MyApp\DataSubdir. The application can still access the same files inside C:\MyDataFolder (Pathwinder does not hide the target-side files).
To illustrate the role of file patterns defined as part of filesystem rules, suppose we revisit the same filesystem hierarchy but change the filesystem rule configuration slightly:
- Origin directory = C:\MyApp\DataSubdir
- Target directory = C:\MyDataFolder
- File pattern = *.txt
The application's view of the filesystem is as below.
In this case, the filesystem rule only acts on files that match the file pattern. As a result, Pathwinder only presents TextFile.txt to the application as being located in C:\MyApp\DataSubdir.