{"version":"2.1.233","anchor":"windows-device-namespace-paths-are-treated-as-network-paths","canonical_anchor":"windows-device-namespace-paths-are-treated-as-network-paths","heading":"Windows device-namespace paths are treated as network paths","tier":"notice","area":"Windows","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.233\/e\/windows-device-namespace-paths-are-treated-as-network-paths","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.233","markdown":"### Windows device-namespace paths are treated as network paths\n\nOn Windows, odd device-style paths are now blocked from attachments, uploads and deep-link directories.\n\n**What**\n\nPaths 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.\n\n**Details**\n\n- One shared predicate now covers both `\\\\` UNC paths and `\\??\\` device-namespace paths; `\/net\/<host>` automounts are recognized by a separate predicate.\n- 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.\n- The executable-path check uses the combined predicate.\n\n**Evidence**\n\n`Invalid cwd in deep link: UNC \/ network paths are not supported, got`, `network path not allowed: `\n\n- Area: Windows\n- Tier: You'll notice\n- Useful: 3\/5\n- Signal: 2\/5"}