Skip to content

fix: list recipes when the collection is on a Windows network drive - #787

Merged
LeMyst merged 2 commits into
cooklang:mainfrom
LeMyst:fix/783-windows-share-listing
Oct 28, 2026
Merged

LeMyst merged 2 commits into
cooklang:mainfrom
LeMyst:fix/783-windows-share-listing

Conversation

@LeMyst

@LeMyst LeMyst commented Oct 27, 2026 •

Copy link
Copy Markdown
Collaborator

Fixes #783.

Cause

resolve_to_absolute_path (used by the server and the CLI) runs the base path through std::fs::canonicalize, added in 85b91b0 ("fix: issue with . base path in server"). On Windows that returns a verbatim path. For a local disk it is \\?\C:\…, which glob walks fine. A mapped network drive or share comes back as \\?\UNC\server\share\…, and some virtual drives as \\?\Volume{…}\…; for those, glob deliberately returns no matches (check_windows_verbatim). Every cooklang-find walk (build_tree, search) globs from the base path.

So the home page, folders, search and cook search find nothing, while /recipe/French/crepes.cook still opens: that is a plain join and read, no walk. That matches the report, and it explains why older releases behave the same.

Fix

resolve_to_absolute_path now spells the canonical path without \\?\ where Windows allows it (dunce::simplified, already in the tree through other crates):

  • \\?\C:\x becomes C:\x
  • \\?\UNC\nas\share\x becomes \\nas\share\x

Where it can't be spelled that way (\\?\Volume{…}), it keeps the absolute path as given. The containment checks (inside_collection, rename, new file, users file, shopping list output) canonicalize both sides themselves, so they still agree. private_paths already hides both spellings.

Tests

Two Windows-only tests in src/util/mod.rs. The second reaches a temp folder through the \\localhost\C$ admin share, which canonicalizes like a mapped drive. The first commit carries only these tests, and its Windows run shows the bug without the fix:

nothing listed under \\?\UNC\localhost\C$\Users\runneradmin\AppData\Local\Temp\.tmpN4gm3e

Confirmed by the reporter

The reporter confirmed that their recipe folder is on a mapped network drive (N: mapped to \\SERVER\data\), and cook server -v logs the base path as \\?\UNC\SERVER\data\Cooking Stuff\CookCLI: the case the share test reproduces.

🤖 Generated with Claude Code

LeMyst and others added 2 commits October 27, 2026 19:52
On Windows a mapped network drive or share canonicalizes to a
`\\?\UNC\…` path, and glob, which every cooklang-find walk uses, finds
nothing under it (cooklang#783). Windows-only, through the admin share.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The base path goes through `std::fs::canonicalize`, which on Windows
returns a `\\?\` path. `glob`, which every cooklang-find walk uses,
returns nothing under one other than `\\?\C:\…`, so a collection on a
mapped network drive or share (`\\?\UNC\…`) showed an empty home page,
and search, in the server and `cook search`, found nothing, while a
recipe's URL still opened it.

`resolve_to_absolute_path` now drops the prefix with `dunce` where
Windows allows it, and keeps the absolute path as given where the
canonical one cannot be spelled without it (`\\?\Volume{…}`). Every
containment check canonicalizes both sides itself, so they still agree.

Fixes cooklang#783

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@LeMyst
LeMyst force-pushed the fix/783-windows-share-listing branch from 884d7e8 to aea1e68 Compare October 27, 2026 18:53
@LeMyst
LeMyst marked this pull request as ready for review October 27, 2026 19:02
@LeMyst
LeMyst merged commit f0b7c94 into cooklang:main Oct 28, 2026
7 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Recipes Page Not Finding/Displaying List of Recipes

1 participant