On Windows, odd device-style paths are now blocked from attachments, uploads and deep-link directories.
What's wrong with this entry?
Paths of the form \??\..., including ones that only take that shape after Windows normalization, now count as network paths everywhere the check is made. They are blocked for @-mention attachments and Chrome file uploads regardless of which network directories the session trusts, and deep-link working directories using them are rejected.
- One shared predicate now covers both
\\UNC paths and\??\device-namespace paths;/net/<host>automounts are recognized by a separate predicate. - A per-module copy of the old check, which required a non-slash character after the two leading slashes and did no normalization, was deleted and its caller moved to the shared helper.
- The executable-path check uses the combined predicate.
Invalid cwd in deep link: UNC / network paths are not supported, got, network path not allowed:
Strings lifted out of the shipped bundle, so the claim above can be checked against them.
Related
Other releases about the same thing. Found by shared names or similar wording; neither means one caused the other.
-
v2.1.234
Windows policy helpers can be PowerShell scripts
Both mention window
-
v2.1.234
Windows sandbox refusals now say why an exclusion did not apply
Both mention window
-
v2.1.234
Terminal is restored on Ctrl+Break on Windows
Both mention window