(Windows) Unable to Access Files on Network Drive

UXP Developer Tool
, ,
1

I’m developing a UXP InDesign plug-in that accesses InDesign packages on a shared network drive. The last time I tested my plugin in January 2024, I was able to access these files with no issues. Today, I’m unable to resolve the network path correctly on a Windows machine.

UXP Developer Tool Version: 2.0.1.10
InDesign Version: 19.0.1 and 18.5.2 (both show the same behavior)
OS: Windows Server 2022

Assume that I have an InDesign file on a network drive named mydrive.

I was previously accessing the file with:

const fs = require('fs');
const DRIVE_PATH = require('os').platform() == "darwin" 
    ? "/Volumes" 
     : "\\\\mydrive";

fs.lstatSync(path.join(DRIVE_PATH, "path", "to", "file.indd"));

This still works fine on macOS, but not on Windows.

While attempting to debug the issue, I’ve tried the following, but all of them fail with error code 4058:

fs.lstatSync("\\\\mydrive\\path\\to\\file.indd");
fs.lstatSync("\\\\mydrive\path\to\file.indd");
fs.lstatSync("\\mydrive\path\to\file.indd");
fs.lstatSync("//mydrive/path/to/file.indd");
fs.lstatSync("\/\/mydrive\/path\/to\/file.indd");
fs.readdirSync("\\\\mydrive");
fs.readdirSync("\\mydrive");
fs.readdirSync("//mydrive");

If I open the file in InDesign directly, and try to fetch the file name from the UXP Developer Tool console, I get an error:

> let filePath = await app.activeDocument.fullName
< Uncaught Error: Could not find an entry of 'file:///path/to/file.indd'
    at Object._getEntryImpl (uxp://uxp-internal/webfs_scripts.js:2)
    at async Object.getEntryWithUrl (uxp://uxp-internal/webfs_scripts.js:2)
    at async <anonymous>:1:16

If I open the file in InDesign, and run this ExtendScript, I get the correct path as I would expect, e.g. //mydrive/path/to/file.indd

alert(app.activeDocument.fullName);

Local files on a mapped drive are not affected, only files on named network drives accessed via UNC paths. Again, I don’t have this issue on macOS, and it used to work correctly a couple months ago.

Given all of this information, I believe that UXP’s implementation of fs might be prepending file: to the beginning of UNC paths, or otherwise incorrectly handling the drive name, which is causing the path to fail to resolve.