Published 2024-11-21.
Last modified 2024-11-28.
Time to read: 6 minutes.
posts
collection.
File aliasing eliminates the need to duplicate the contents of files that need to appear in more than one directory. It is often desirable to alias directories as well. Aliasing helps manage files and directories by reducing duplication. This also reduces storage consumption.
All Linux file systems support directory and file aliases.
The ext4
file system is the most common Linux file system today,
and is the default for Ubuntu.
Windows directory and file aliasing requires volumes to be formatted with the NTFS file system. NTFS is the default file system for Windows hard drives and NVMe drives.
In contrast, the various flavors of the FAT file system (FAT12, FAT16, FAT32, and exFAT) used by flash drives, SSDs, and CD-ROMs do not support directory or file aliasing.
Spoiler
The primary fact that was discovered while researching this article is that Ubuntu on WSL can create a
bidirectional link for files between NTFS file systems and ext4
file systems.
This is possible because Ubuntu on WSL uses the
WSL2-Linux-Kernel
developed by Microsoft.
Once the link is created, both native Windows and Linux programs can create, read, write, update and delete aliased files.
Impatient readers can skip to the summary at the end of this article.
Motivation
I was motivated to research this article because I use several native Windows programs (including Ableton Live, Pro Tools, and DaVinci Resolve) to create media files, and some of those media files needed to be incorporated into a Linux program (Jekyll) running on WSL2. These media files can be quite large, and over time a project can accumulate many of them.
Jekyll copies all the contents of directories that it processes to an output directory, which is then uploaded to this website. I needed to minimize the quantity of media files created on Windows and exposed to the Linux program; otherwise they would bloat the website generated by Jekyll.
My choices were either to copy the required files from Windows NTFS to WSL ext4
,
or to somehow alias (link) them.
Making a file alias between two operating systems can be tricky.
In general, this is rather problematic, but happily Microsoft has done an excellent job in how
they have stiched Windows Subsystem for Linux together with Ubuntu Linux.
As previously mentioned aliasing files is preferred to copying them because that reduces disk space consumption,
and reduces the possibility of confusing file versions.
Detailed Requirements
-
Two environment variables are defined in my bash shell's initialiation:
media=/mnt/e/media
songs=$media/songs
E:\media
E:\media\songs
-
The media for a music video project that I am working on resides in
$songs/
. I call this the project directory, and it contains files used by DaVinci Resolve as well as the DAW(s) used for this music video project.one_year_older/ -
I need to be able to archive these files so each version of the DaVinci Resolve project is saved separately.
Because DaVinci Resolve can only archive projects within a small directory structure,
the other media files that are required should also reside within the project directory.
Similarly, each version of the Pro Tools project must be separately archived, and saved within this music video project structre. -
The directories containing additional media created by Pro Tools are
(see the diagram at the top of Production Infrastructure Overview):
E:\
media\ songs\ one_year_older\ outputs\mp3s\ E:\
media\ songs\ one_year_older\ outputs\stems\
U:\
var\ sitesUbuntu\ www.mslinn.com\ site\ songs\ mp3s\ U:\
var\ sitesUbuntu\ www.mslinn.com\ site\ songs\ stems\
\\wsl$\Ubuntu\
var\ sitesUbuntu\ www.mslinn.com\ site\ songs\ mp3s\ \\wsl$\Ubuntu\
var\ sitesUbuntu\ www.mslinn.com\ site\ songs\ stems\
-
The files in the directory that contains the additional media have names like
One Year Older (136 bpm, landscape, long, lyrics, take 7; 2024-11-20).mp4
. -
The directory containing the additional media should be aliased as
E:\
media\ songs\ one_year_older\ renders\
NTFS
NTFS supports the following types of file and directory aliasing:
- Hard links: aliases files; only works within a single volume.
- Junctions: aliases directories; can work across volumes.
- Volume mountpoints – points to the root directory of another volume.
- Symbolic links: aliases files and directories; most flexible option.
For an in-depth discussion, see this SuperUser explanation.
Windows shortcuts are known as shell links, and are merely files that the Windows Explorer shell treats specially. No other software processes shell links, so this article will not mention shell links again.
UNC Paths
Support for directory and UNC paths was added in NTFS 3.1,
which was released in October 2001.
My Windows system drive, C:
, has the required version of NTFS to support UNC paths.
c:\Users\Mike Slinn>fsutil fsinfo ntfsinfo c: NTFS Volume Serial Number : 0x2e02747f02744e39 NTFS Version : 3.1 LFS Version : 2.0 Total Sectors : 3,904,531,483 ( 1.8 TB) Total Clusters : 488,066,435 ( 1.8 TB) Free Clusters : 231,696,370 (883.9 GB) Total Reserved Clusters : 1,097,766 ( 4.2 GB) Reserved For Storage Reserve : 1,076,491 ( 4.1 GB) Bytes Per Sector : 512 Bytes Per Physical Sector : 4096 Bytes Per Cluster : 4096 Bytes Per FileRecord Segment : 1024 Clusters Per FileRecord Segment : 0 Mft Valid Data Length : 2.92 GB Mft Start Lcn : 0x00000000000c0000 Mft2 Start Lcn : 0x0000000000000002 Mft Zone Start : 0x000000000624aea0 Mft Zone End : 0x00000000062576c0 MFT Zone Size : 200.13 MB Max Device Trim Extent Count : 256 Max Device Trim Byte Count : 0xffffffff Max Volume Trim Extent Count : 62 Max Volume Trim Byte Count : 0x40000000 Resource Manager Identifier : E8B6726E-9DB0-11EE-A6D0-009337B28314
Unmapped UNC Paths
Unmapped UNC paths like \\wsl$\Ubuntu
are supported,
with or without administrator privilege:
c:\Users\Mike Slinn>dir /a:d \\wsl$\Ubuntu\var\sitesUbuntu\www.mslinn.com\collections\_songs Volume in drive \\wsl$\Ubuntu has no label. Volume Serial Number is 0000-0000
Directory of \\wsl$\Ubuntu\var\sitesUbuntu\www.mslinn.com\collections\_songs
2024-10-31 12:35 PM <DIR> guitar_pro 2024-11-05 12:58 PM <DIR> mp3s 2024-10-31 12:33 PM <DIR> pdfs 2024-05-07 12:56 PM <DIR> musescore 2024-10-29 02:41 PM <DIR> musicxml 2024-11-23 09:37 AM <DIR> stems 2024-10-24 06:58 AM <DIR> images 2024-11-02 01:30 PM <DIR> .. 2024-11-02 01:30 PM <DIR> . 0 File(s) 0 bytes 9 Dir(s) 259,885,223,936 bytes free
PowerShell works exactly the same.
Mapped UNC Paths
Windows can map UNC paths two ways: by using the Windows File Explorer as discussed above
and via the NET USE
command, described next.
Although the results appear to be similar, they are actually different in a subtle but significant way.
I do not know how to tell them apart, except by testing them.
Let’s explore what I mean in detail.
Mapped Via File Explorer
Both Windows CMD.EXE
and PowerShell cannot recognize UNC paths mapped to Windows drive letter
by using Windows File Explorer.
c:\Users\Mike Slinn>dir u: The system cannot find the drive specified.
PS C:\WINDOWS\system32>dir u: Set-Location : Cannot find drive. A drive with the name 'U' does not exist. At line:1 char:1 + Set-Location $MyInvocation.MyCommand.Name + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : ObjectNotFound: (U:String) [Set-Location], DriveNotFoundException + FullyQualifiedErrorId : DriveNotFound,Microsoft.PowerShell.Commands.SetLocationCommand
Other Windows applications might be able to recognize Linux ext4
file systems
mapped to a Windows drive letters in this way, but because these two Windows shells fail in this regard,
all Windows command-line programs that rely on file systems mapped in this fashion to perform I/O also cannot work with
mapped Linux ext4
file systems.
Mapped Via net use
The cmd.exe
shell can work with UNC paths mapped via the net use
command.
c:\Users\Mike Slinn>net use x: \\wsl$\Ubuntu
c:\Users\Mike Slinn>dir x:\var\sitesUbuntu\www.mslinn.com\collections\ Volume in drive X has no label. Volume Serial Number is 0000-0000
Directory of x:\var\sitesUbuntu\www.mslinn.com\collections
2023-02-27 06:40 PM <DIR> _ancientWarmth 2023-01-19 03:28 PM <DIR> _scalaCourses 2024-10-22 08:24 PM <DIR> _mainframe 2024-11-20 07:52 AM <DIR> _av_studio 2024-07-26 08:14 AM <DIR> _ruby 2024-08-31 04:00 PM <DIR> _jekyll_plugins 2024-11-16 10:40 AM <DIR> _drafts 2024-01-13 10:32 AM <DIR> _posts 2024-06-25 08:28 AM <DIR> _llm 2024-08-03 12:21 PM <DIR> _jekyll 2023-12-17 08:49 AM <DIR> _expertArticles 2024-02-19 09:14 AM <DIR> _evelyn 2024-11-02 01:30 PM <DIR> _songs 2024-05-23 12:04 PM <DIR> _git 2024-04-11 06:25 PM <DIR> .. 2024-08-03 12:21 PM <DIR> _dead 2024-08-03 12:21 PM <DIR> _django 2024-04-11 06:25 PM <DIR> . 0 File(s) 0 bytes 18 Dir(s) 259,883,159,552 bytes free
PowerShell works exactly the same.
MkLink
Mklink
creates various types of links.
It is not a standalone program.
Instead, it is built-in to the cmd.exe
shell.
This means that mklink
cannot be run directly from PowerShell.
C:\Users\Mike Slinn>help mklink Creates a symbolic link.
MKLINK [[/D] | [/H] | [/J]] Link Target
/D Creates a directory symbolic link. Default is a file symbolic link. /H Creates a hard link instead of a symbolic link. /J Creates a Directory Junction. Link Specifies the new symbolic link name. Target Specifies the path (relative or absolute) that the new link refers to.
Link Shell Extension
I encountered
Link Shell Extension (LSE)
while researching this article.
LSE is a free, full-featured GUI program that facilitates the creation of all types of Windows links.
It uses the Windows mklink
command, and suffers the same limitations.
Documentation is unusually extensive. Download it here. The FAQ is worth reading.
Support Matrix
This section documents the various ways that I explored for causing a file created by a native Windows application to be visible to Linux applications running in WSL.
For these tests, the Windows system drive, C:
,
was formatted with the default NTFS file system.
The WSL system drive was formatted with ext4
.
The NTFS file to be linked, C:\Users\Mike Slinn\x
, contains only one line:
This is the file called x
Drive U:
is the WSL system drive, formatted with the ext4
file system,
with UNC path
\\wsl$\Ubuntu
, and mapped as the Windows volume U:
via the
Windows File Explorer.
From Windows/NTFS
Linking an Ext4 Directory to a New NTFS Directory
It is not possible to link an existing ext4
directory on WSL Ubuntu Linux
to a new NTFS directory on Windows.
It does not matter if you specify the NTFS directory using a UNC path or as a mapped drive.
C:\Users\Mike Slinn>mkdir testDir
C:\Users\Mike Slinn>dir > testDir/blah
C:\Users\Mike Slinn>mklink /D \\wsl.localhost\Ubuntu\home\mslinn\testDir testDir The device does not support symbolic links.
C:\Users\Mike Slinn>mklink /D x:\Ubuntu\home\mslinn\testDir testDir The device does not support symbolic links.
Linking an NTFS Directory to a New Ext4 Directory
Trying the other direction
(linking an existing NTFS directory on Windows to a new ext4
directory on WSL Ubuntu Linux),
a symbolic link is created, but it is unusable.
C:\Users\Mike Slinn>mklink /D testDir x:\home\mslinn\testDir symbolic link created for testDir <<===>> x:\home\mslinn\testDir
Attempting to open the new directory from Windows File Explorer yields:
Attempting the same thing, but using a UNC path yields a similar error:
C:\Users\Mike Slinn>mklink /D testDir \\wsl.localhost\home\mslinn\testDir symbolic link created for testDir <<===>> \\wsl.localhost\home\mslinn\testDir
Linking An Ext4 File to A New NTFS File
Windows symlinks can connect Linux files to new Windows files.
C:\Users\Mike Slinn>mklink testx \\wsl.localhost\Ubuntu\home\mslinn\.profile symbolic link created for testx <<===>> \\wsl.localhost\Ubuntu\home\mslinn\.profile
Linking An NTFS File to A New Ext4 File
Windows symlinks cannot connect Windows files to new Linux files.
C:\Users\Mike Slinn>mklink \\wsl.localhost\Ubuntu\home\mslinn\moonlight.gp C:\Moonlight.gp The device does not support symbolic links
C:\Users\Mike Slinn>mklink u:\home\mslinn\moonlight.gp C:\Moonlight.gp The system cannot find the path specified.
From WSL/Ext4
Linking An NTFS File To a New Ext4 File
Linux symlinks can be created from a file in the ext4
file system
to a new file in the NTFS C:
file system by the Linux
/usr/bin/ln
program.
This example shows a Linux symlink connecting a Windows file to a new Linux file:
$ ln -s /mnt/c/Users/mslinn/x blahblahblah
$ cat blahblahblah This is the file called x
Linking An Ext4 File To A New NTFS File
Linux symlinks cannot be created to the NTFS C:
file system by the Linux
/usr/bin/ln
program.
This example shows a Linux symlink failing to connect a Windows file to a new Linux file.
The symlink is created without error, but the resulting file cannot be accessed.
$ ln -s /mnt/c/Users/Mike\ Slinn/x x
$ cat x /home/mslinn/x: No such file or directory
Linking An Ext4 Directory to A New NTFS Directory
This example shows that Linux symlink cannot connect a Linux ext4
directory to a new Windows NTFS directory:
$ ln -s \
/var/sitesUbuntu/www.mslinn.com/collections/_songs/mp3s/ \
/mnt/e/media/songs/one_year_older/outputs/mp3s/
Although the above command completes without error, the directory created in NTFS by the Linux symlink cannot be opened in Windows File Explorer.
Linking An NTFS Directory to A New Ext4 Directory
This example shows that Linux symlink cannot connect a Windows NTFS directory
to a new Linux ext4
directory:
$ ln -s /mnt/c/Users/bin/ ~/testdir
$ ls ~/testdir/ ls: cannot access '/home/mslinn/testdir/': No such file or directory
Summary
TODO: This needs further tweaking.
- Files can be symlinked across NTFS and
ext4
file systems. - Directories cannot be symlinked across NTFS and
ext4
file systems.
Cross-File System Links That Work
- Windows symlinks can connect Linux
ext4
files to new Windows NTFS files. - Linux symlinks can connect Windows NTFS files to new Linux
ext4
files.
Cross-File System Links That Do Not Work
- Windows symlinks cannot connect Windows NTFS files to new Linux
ext4
files. - Windows symlinks cannot connect Linux
ext4
directories to new Windows directories. - Windows symlinks cannot connect Windows NTFS directories to new Linux
ext4
directories. - Linux symlinks cannot connect Windows NTFS directories to new Linux
ext4
directories. - Linux symlinks cannot connect Linux
ext4
files to new Windows NTFS files. - Linux symlinks cannot connect Linux
ext4
directories to new Windows NTFS directories.