Windows: --profile-dir fails while syncing parent directory (os error 5)

[zhouzirui-2026]

Summary

On Windows, Moli v1.1.8 exits during startup whenever serve uses a fresh --profile-dir. Profile initialization writes profile.json, then fails while syncing the parent directory with Access Denied (os error 5). Starting the same binary without --profile-dir remains running.

Environment

• Moli: v1.1.8 official moli-x86_64-pc-windows-msvc.zip
• archive SHA-256 verified: 09fba722f93984ae74ce357bb31920a9ce439b7e24f15ca1a1381217d7286660
• Windows x86_64
• tested with fresh profile directories under ordinary %TEMP% and a separate scratch directory

No existing browser profile, cookies, or imported auth state are involved.

Reproduction

$root = Join-Path $env:TEMP ("moli-profile-repro-" + [guid]::NewGuid().ToString("N"))
$profile = Join-Path $root "profile"
New-Item -ItemType Directory -Force -Path $profile | Out-Null

.\moli.exe serve `
  --host 127.0.0.1 `
  --port 32174 `
  --profile-dir $profile `
  --layout `
  --log-level error

Observed stderr:

Error: failed to initialize browser profile manifest `<profile>\profile.json`: failed to sync profile manifest parent directory `<profile>`: Access is denied. (os error 5)

Control:

.\moli.exe serve --host 127.0.0.1 --port 32175 --layout --log-level error

The no-profile control remains running, so the failure is specific to persistent profile initialization.

Suspected source

In v1.1.8 (and current main), moli-browser-profile/src/atomic_write.rs calls:

fs::File::open(parent)
    .and_then(|directory| directory.sync_all())

after renaming the temporary manifest. On Windows, opening a directory through the normal File::open path appears to produce the observed Access Denied, so the directory durability step prevents profile creation even though the manifest file itself was written/replaced.

A platform-specific directory-open/sync implementation (or reviewed Windows durability equivalent) may be needed. A regression that executes write_file_atomically() with a real temporary directory on Windows would catch this.

I can retest a patch/release on Windows if useful.

[ldm0]

Thanks for reporting this, fixing now.

[zhouzirui-2026]

Additional Windows evidence from a local source build/probe:

• A direct Win32 directory-handle experiment confirms the failure mode: opening a directory with FILE_FLAG_BACKUP_SEMANTICS and access 0 or GENERIC_READ succeeds, but FlushFileBuffers fails with Win32 error 5 (ERROR_ACCESS_DENIED). The same directory opened with GENERIC_WRITE (or read+write) flushes successfully.
• A local Rust patch using std::os::windows::fs::OpenOptionsExt, access_mode(GENERIC_WRITE), and FILE_FLAG_BACKUP_SEMANTICS makes the moli-browser-profile durability path work on this host. cargo test -p moli-browser-profile --lib then passes 31/31 on Windows.
• I found two additional directory-fsync sites with the same Unix-style pattern that are likely to fail after profile creation even if only the manifest path is fixed:
  • moli-opfs/src/staging.rs::sync_directory
  • moli-storage-service/src/buckets.rs::sync_storage_bucket_cache_directory
    Applying the same Windows directory-handle helper pattern there gives 36/36 moli-opfs tests and 53/53 moli-storage-service tests on Windows.

The minimal Windows shape I validated is effectively:

use std::os::windows::fs::OpenOptionsExt;
const FILE_FLAG_BACKUP_SEMANTICS: u32 = 0x0200_0000;
const GENERIC_WRITE: u32 = 0x4000_0000;
OpenOptions::new()
    .access_mode(GENERIC_WRITE)
    .custom_flags(FILE_FLAG_BACKUP_SEMANTICS)
    .open(path)?
    .sync_all()

I have not claimed a full Windows Moli binary rebuild yet; the three affected crate test suites above are the current source-level evidence. Happy to retest the maintainer fix/release against the persistent-profile + restart fixture as soon as it lands.