DrvFs Metadata and Case Sensitivity: When Windows Files Behave Like Linux Files

DrvFs, the driver that projects Windows drives into a WSL distribution’s filesystem under /mnt/c and similar paths, has to bridge two filesystems with genuinely different assumptions about ownership, permissions, and case sensitivity. Understanding what DrvFs actually does at that bridge — rather than assuming Windows files simply “become” Linux files transparently — explains a category of confusing behavior around permissions and duplicate-looking filenames.

Without metadata: synthesized, not real, Linux permissions

By default, DrvFs does not store genuine Linux-style ownership and permission bits for files on a Windows volume, because NTFS’s own permission model (Windows ACLs) doesn’t map one-to-one onto Unix owner/group/mode bits. Without metadata support enabled, the Linux-side permission and ownership values you see on a file under /mnt/c are synthesized from mount options — a fixed, mount-wide interpretation — rather than reflecting anything actually stored per-file. Running chmod on such a file may appear to succeed but doesn’t necessarily persist a genuinely per-file Linux permission the way it would on a native ext4 filesystem.

With metadata enabled: real per-file Linux permission data, stored in NTFS extended attributes

DrvFs supports an explicit metadata mode where Linux-style permission and ownership information is actually stored, per file, using NTFS’s extended attribute mechanism — a genuine, persistent record distinct from the synthesized mount-wide defaults. Enabling this (via mount options, typically configured through /etc/wsl.conf’s automount settings) makes chmod and chown on files under /mnt/c behave much more like they would on a native Linux filesystem, since there’s now an actual per-file record being modified rather than a fixed default being reported regardless of what you set.

Why Windows ACLs still ultimately govern access

Enabling metadata mode changes what Linux reports and modifies about a file’s permissions — it does not remove or override the underlying Windows security model. The Windows identity WSL is running under (and its NTFS ACL permissions on that specific file or folder) still ultimately determines what’s actually readable or writable, regardless of what a Linux ls -l now reports thanks to metadata mode. A Linux permission bit that looks permissive doesn’t grant access if the underlying Windows ACL for the account WSL is running as doesn’t already permit it — metadata mode adds a more accurate Linux-side view and manipulation of permissions, it doesn’t grant Linux tooling authority Windows itself hasn’t already granted to the same identity.

Case sensitivity: a per-directory setting, not global

NTFS is case-insensitive by default (File.txt and file.txt are the same file), while Linux filesystems are case-sensitive by convention. Windows has supported per-directory case sensitivity for some time, and WSL/DrvFs can take advantage of this — a specific directory can be marked case-sensitive, after which creating both File.txt and file.txt inside it succeeds as two genuinely distinct files, exactly as a native Linux directory would behave.

The real risk of enabling case sensitivity broadly

Enabling case sensitivity on a directory that Windows applications also access is where this gets genuinely risky rather than merely inconvenient — many Windows applications, including some backup tools, synchronization utilities, and even parts of Windows Explorer’s own handling, assume case-insensitive behavior and can become confused, duplicate files unexpectedly, or fail outright when two files differing only by case coexist in a directory they’re operating on. This is why the practical guidance is scoping case sensitivity to a dedicated development directory that Windows-native tools don’t also need to operate on directly, rather than enabling it broadly across an entire user profile or shared directory tree.

Testing before trusting, especially with backup and antivirus tools

Before relying on a case-sensitive directory for real work, specifically test whatever backup and antivirus tooling your organization requires against it — these categories of software are exactly the kind most likely to have been built assuming case-insensitive Windows filesystem semantics, and confirming they handle a case-sensitive directory correctly (rather than silently skipping, duplicating, or mishandling files) avoids discovering a gap during an actual restore attempt rather than during a deliberate, low-stakes test.

Checking current settings before changing anything

Before enabling metadata or case sensitivity on a directory, confirm the current state rather than assuming a default:

fsutil.exe file queryCaseSensitiveInfo C:\path\to\directory

run from a Windows command prompt, reports whether a specific directory is currently case-sensitive. Combined with reviewing the relevant /etc/wsl.conf automount options for metadata mode, this gives a clear before/after picture — useful both for confirming a change actually took effect and for documenting the current configuration before troubleshooting a permission or duplicate-file report from a teammate working in the same shared directory.

Choosing where source code should actually live given all of this

For Linux-heavy development work, keeping source code inside the distribution’s own native ext4 filesystem and accessing it from Windows tools through \\wsl.localhost sidesteps both the metadata-translation question and the case-sensitivity risk entirely, since the filesystem in question is genuinely Linux-native rather than a Windows volume being made to behave like one. Reserve /mnt/c access for cases where Windows-native interoperability — a Windows-only build tool, direct Explorer access — is the actual primary requirement, and treat DrvFs’s metadata and case-sensitivity features as compatibility bridges for that specific need, not a general-purpose substitute for a real Linux filesystem.

What this means for cross-tool collaboration on a shared machine

On a machine where multiple tools or multiple people touch the same Windows-side directory — a shared build agent, a workstation used for both Linux development and Windows-native tasks — undocumented metadata or case-sensitivity changes are a recurring source of “it works for me” reports that are genuinely hard to diagnose remotely, since the symptom (a permission that looks wrong, a file that appears duplicated) doesn’t obviously point back to a mount option someone changed weeks earlier. Recording any non-default DrvFs setting in the same place you’d document other environment-specific configuration avoids that class of bug entirely. Related: How to Access Files Between Windows and WSL Correctly · How to Run Linux GUI Applications on Windows with WSLg

Sources: