evalFile fails with Volumes path prefix when network drives are mounted on macOS

[BlondeLegion]

Summary

The "evalFile" function fails to load ExtendScript files when network drives (particularly Windows shares) are mounted on macOS. ExtendScript resolves local paths with a Volumes prefix in this scenario, causing file loading to fail even though the files exist and are accessible to Node.js/CEP.

This first manifested as an issue when I would load my CEP extension (using "yarn dev"), and After Effects would immediately produce the Extendscript error modal:

"IOError: File or folder does not exist"

Various I/O related functions in my extension would fail. I was stumped for some time before I eventually tracked this down with logging to the initBolt function, and then eventually to evalFile.

Environment

• OS: macOS (I have yet to test the reverse scenario)
• After Effects Version: 24.6.6 (likely affects other versions)
• Bolt CEP Version: 1.2.6
• Network Configuration: Windows machine connected via SMB/network sharing (i.e, Finder > Network > [Windows Machine] > "Connect as")

Steps to Reproduce

1. Connect a Windows machine to Mac via network sharing
2. Mount the Windows machine as a network drive (appears in Volumes)
3. Launch After Effects with a CEP extension using Bolt
4. Observe evalFile failing to load ExtendScript files

Expected Behaviour

evalFile should successfully load ExtendScript files regardless of network drive mounting status.

Actual Behaviour

evalFile fails with a forced modal "IOError: File or folder does not exist" error when triggered with a network drive mounted, even though:

• Node.js fs.existsSync() reports the file exists
• The file path is correct: /Users/username/Library/Application Support/Adobe/CEP/extensions/[Extension Name]/jsx/index.js

Analysis

Root Cause

When network drives are mounted on macOS, Adobe's ExtendScript engine resolves local file paths differently than Node.js. Specifically:

• Node.js/CEP context: /Users/[Username here]/path/to/file.js
• ExtendScript context: /Volumes/Users/[Username here]/path/to/file.js

This path resolution discrepancy seemingly occurs because ExtendScript appears to use the network file system context when network drives are present, causing it to prepend Volumes to local paths.

Current Implementation Problem

The current evalFile implementation in Bolt:

/**
 * @function evalFile
 * Evaluates a file in ExtendScript
 * @param file The file to be evaluated
 * @return String Result.
 */
export const evalFile = (file: string) => {
  return evalES(
    "typeof $ !== 'undefined' ? $.evalFile(\"" +
      file +
      '") : fl.runScript(FLfile.platformPathToURI("' +
      file +
      '"));',
    true
  );
};

Directly passes the Node.js-resolved path to ExtendScript without accounting for this path resolution difference.

Error Log Example

An example of one of my logs reporting the issue:

[evalFile] ExtendScript result: Error: File does not exist at: /Volumes/Users/[Username here]/Library/Application Support/Adobe/CEP/extensions/com.extension.cep/jsx/index.js | File path attempted: /Users/[Username here]/Library/Application Support/Adobe/CEP/extensions/com.extension.cep/jsx/index.js

Impact

• Severity: High - Blocks ExtendScript functionality entirely in affected environments
• Scope: macOS users with network drives mounted (common in studio environments)
• Workaround: Manually disconnect network drives before using CEP extensions (not entirely practical for some users)

Notes

• This issue is specific to the interaction between Adobe's ExtendScript engine and macOS network drive mounting
• The issue does not occur when network drives are unmounted; the issue is straightforward to reproduce
• Node.js file system operations work correctly in both scenarios (but I am undecided on whether to transition to this for every I/O operation)
• This appears to be an undocumented behaviour of ExtendScript's file system resolution on macOS

System Configuration Details

• File Path Format: POSIX-style paths (/Users/...)
• Network Protocol: SMB/CIFS (Windows file sharing)
• Mount Point: /Volumes/[Computer Name] (standard macOS network drive mounting)
• ExtendScript Version: Latest (bundled with After Effects 24.6.6)

[justintaylor-dev]

In what scenario are you executing storing / evaluating your ExtendScript file on a network drive? Adobe apps don't look for extensions on network drives, only the local drive.

[BlondeLegion]

In what scenario are you executing storing / evaluating your ExtendScript file on a network drive? Adobe apps don't look for extensions on network drives, only the local drive.

Hi Justin,

The issue was that I wasn't attempting to evaluate something on a network drive. The problem is that evalFile behaves differently when evaluating files locally, depending on whether a networked drive is attached, as documented above, because Extendscript automatically prepends 'Volumes' to the file path merely due to the existence of a networked drive.

For example:

• While on Computer A, using evalFile for a file on Computer A was working as expected, so long as Computer B isn't networked
• While on Computer A, using evalFile for a file on Computer A doesn't work as expected if Computer B is networked.

I wasn't intentionally trying to involve Computer B for my Extension at all.

My extension was unexpectedly breaking in strange ways until I caked the entire extension in logs to eventually find the culprit was evalFile due to me connecting my Windows machine to my Mac.

[justintaylor-dev]

Thanks for clarifying. I've tested and it looks like it's only an issue if there is a clash in the mounted drive name and the root folder of where your extension is.

If you have your extension within your User folder for dev purposes and you mount another volume named Users, causing there to be 2 different /Users, requiring the specification of which volume. This is pretty uncommon and why I'd imagine no one else has reported this yet.

For reference:

Works without a mounted drive called Users

f = new File("/Users/justin/path/to/test.js");
$.evalFile(f)

Required when there is a mounted drive called Users

f = new File("/Volumes/Macintosh HD/Users/justin/path/to/test.js");
$.evalFile(f)

I'm not seeing a clear way in Node.js to get the OS volume and pass that to evalFile() since it's not always going to be the first drive and not always going to be called Macintosh HD. If you find one, please open a PR with the correction.

Very strange that ExtendScript won't default to the OS drive but instead suddenly requires this if there's a clash.

This won't be an issue for installed panels unless you have a mounted drive called Library

Interestingly, even using ExtendScript to get the myDocuments folder will end up giving you the wrong documents folder if a /User volume is mounted:

docPath = Folder.myDocuments.fsName;
ff = new Folder(docPath);
ff.fsName; // /Users/justin/Documents

I'd recommend just renaming your mounted folder

[justintaylor-dev]

And FYI, Adobe doesn't fix core ExtendScript bugs anymore, only bugs in individual app APIs.