Turbopack Error: "Failed to sync database directory after updating CURRENT" on WSL2 when the directory is on a mounted Windows drive

[wazuka-rail]

Next.js version: 16.3.2
Error message:

[Error: Failed to open database

Caused by:
    0: Creating and initializing persistence directory failed
    1: Failed to sync database directory after updating CURRENT
    2: failed to sync file `/mnt/c/Users/...SNIP.../v16.3.2-d0ac8828`: Invalid argument (os error 22)] {
  code: 'GenericFailure'
}

$ mount -l | grep /mnt/c
32d51e83-5ed8-4380-9f17-d2c11a6ef750 on /mnt/c type virtiofs (rw,noatime)

When running next dev (or next build) with Turbopack's persistent FileSystem Cache enabled from inside WSL2, and the project directory lives on a mounted Windows drive (e.g. /mnt/c/Users/..., backed by drvfs/9p or virtiofs), the cache commit fails with the error above.

This is the same class of failure that Turbopack already special-cases for native Windows

next.js/turbopack/crates/turbo-persistence/src/db.rs

Lines 244 to 251 in c0dfeff

	// Skipped on Windows: `sync_data` on a directory handle fails with ERROR_ACCESS_DENIED (the
	// handle `File::open` returns for a directory has no write access).Apparently metadata changes
	// are always atomic on windows so this is simply unneeded.
	#[cfg(not(windows))]
	File::open(path)
	.and_then(|dir| dir.sync_data())
	.context("Failed to sync database directory after updating CURRENT")?;
	Ok(())

because opening a directory handle and calling sync_data() on it is not meaningful/supported on Windows filesystem semantics. WSL2's drvfs mount for Windows drives inherits the same limitation (unlike native ext4 inside the WSL2 VM), so the existing cfg(not(windows)) guard does not cover this case even though the underlying cause is identical.

Suggested Fix

Detect at runtime whether directory fsync is supported (e.g., attempt it once, and if it fails with EINVAL/EACCES/ENOTSUP, treat the filesystem as not supporting it and suppress the error message as non-fatal failure).