Mike Slinn

NTFS/ext4 Compatible Aliases

Published 2024-11-21. Last modified 2024-11-28.
Time to read: 6 minutes.

This page is part of the 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

  1. Two environment variables are defined in my bash shell's initialiation:
    • media=/mnt/e/media
    • songs=$media/songs
    WSL automagically maps the above paths to:
    • E:\media
    • E:\media\songs
    This allows us to specify directory paths in Linux format or in Windows/DOS format.
  2. The media for a music video project that I am working on resides in $songs/one_year_older/. 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.
  3. 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.
  4. The directories containing additional media created by Pro Tools are (see the diagram at the top of Production Infrastructure Overview):
    1. E:\media\songs\one_year_older\outputs\mp3s\
    2. E:\media\songs\one_year_older\outputs\stems\
    These directories need to be linked such that they are visible from Windows as:
    1. U:\var\sitesUbuntu\www.mslinn.com\site\songs\mp3s\
    2. U:\var\sitesUbuntu\www.mslinn.com\site\songs\stems\
    The UNC paths used by Windows for these directories are:
    1. \\wsl$\Ubuntu\var\sitesUbuntu\www.mslinn.com\site\songs\mp3s\
    2. \\wsl$\Ubuntu\var\sitesUbuntu\www.mslinn.com\site\songs\stems\
  5. 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.
  6. 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:

  1. Hard links: aliases files; only works within a single volume.
  2. Junctions: aliases directories; can work across volumes.
  3. Volume mountpoints – points to the root directory of another volume.
  4. 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.

Administrator CMD.EXE
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:

CMD.EXE
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.

Administrator CMD.EXE
c:\Users\Mike Slinn>dir u:
The system cannot find the drive specified. 
Administrator Windows PowerShell
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.

Administrator CMD.EXE
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.

Administrator CMD.EXE
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:

C:\Users\Mike Slinn\x
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.

Administrator CMD.EXE
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.

Administrator CMD.EXE
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:

Administrator CMD.EXE
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.

Administrator CMD.EXE
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.

Administrator CMD.EXE
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:

Shell
$ 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.

Shell
$ 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:

Shell
$ 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:

Shell
$ 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.

  1. Files can be symlinked across NTFS and ext4 file systems.
  2. Directories cannot be symlinked across NTFS and ext4 file systems.

Cross-File System Links That Work

  1. Windows symlinks can connect Linux ext4 files to new Windows NTFS files.
  2. Linux symlinks can connect Windows NTFS files to new Linux ext4 files.

Cross-File System Links That Do Not Work

  1. Windows symlinks cannot connect Windows NTFS files to new Linux ext4 files.
  2. Windows symlinks cannot connect Linux ext4 directories to new Windows directories.
  3. Windows symlinks cannot connect Windows NTFS directories to new Linux ext4 directories.
  4. Linux symlinks cannot connect Windows NTFS directories to new Linux ext4 directories.
  5. Linux symlinks cannot connect Linux ext4 files to new Windows NTFS files.
  6. Linux symlinks cannot connect Linux ext4 directories to new Windows NTFS directories.
* indicates a required field.

Please select the following to receive Mike Slinn’s newsletter:

You can unsubscribe at any time by clicking the link in the footer of emails.

Mike Slinn uses Mailchimp as his marketing platform. By clicking below to subscribe, you acknowledge that your information will be transferred to Mailchimp for processing. Learn more about Mailchimp’s privacy practices.