When trying to access a drive called \\OO-AA1 (zo not the usual Z:/ or something alike)
We get an error, file not found, and if you look at the error it doesn’t show the drive in the path.
\\OO-AA1\Profiles$\t\ would turn into file:///Profiles$/t/
The path is accessible from Explorer and such, although it’s not visible from “Your pc” like the Z drive is.
Just to rule out more obvious access issues, are you able to access random files on your local drive? And just to confirm you have all the right settings in your manifest, etc. like it has been mentioned over and over in various threads in the forum (e.g. this one or this)?
Regarding your first question, I can open random files, or the files specified in my script yeah? Or am I misunderstanding you.
Regarding the manifest, don’t have one, it’s a script and not a plugin.
The root cause feels to me like is a Photoshop bug, based on how it removes the drive, in this case network drive from the path.
I’ll try to rewrite it using Node FS, maybe that works?
My question was, if you were able to invoke localFileSystem.getEntryWithUrl successfully in any other case. To be honest, I’m not entirely sure that UXP allows random file access in scripts (vs. plugins, that can request that permission via manifest). Similarly I don’t think Node FS is available in UXP, only UXP’s own fs module, but again not sure if that is available in a script (vs. plugin). Maybe someone from Adobe can confirm that.
Yes you can open any file with local filesystem.getEntryWithUrl, scripts have access to all files unlike plugins.
The issue most likely is permission related
Within Java and normal NodeJS FS I can read the file without problems.
Just not possible when in a script. I can try to convert it into a plugin, but honestly no clue how much time that takes.
Or alternatively, it can still be a bug in the UXP API.
See:
We get an error, file not found, and if you look at the error it doesn’t show the drive in the path.
\\OO-AA1\Profiles$\t\would turn intofile:///Profiles$/t/
the OO-AA1 is the drive path, so yea that’s absolutely required.
When using a manifest, i get the same error, notice how the drive again got removed…
In terms of converting to a plugin - if all you want is a button to trigger a script it would be super easy to adapt the vanilla starter.
I’d want it to trigger by CMD, but that’s another issue.
If I can’t open those kind of network drives the script isn’t possible to work without a restructure of our organisations infrastructure.
And after trying, with using a manifest with fullAccess to the localFileSystem, it still doesn’t work so it’s not very helpfu.
I was also under the impression that this was either a bug or not supported. Formats like \\Volume seem to be erased and unavailable.
@Tais993 Permissions for scripts are a little limiting https://developer.adobe.com/photoshop/uxp/2022/scripting/how-it-works/#permitted-uxp-modules However, it should have worked within a plugin. Can you share the manifest.json and code snippet?
When using localFileSystem.getFileForOpening it works fine, or is that bypassed as it’s user-selection?
I added this to my manifest:
"requiredPermissions": {
"localFileSystem": "fullAccess",
"network": {
"domains": [
"10.0.4.34",
"OO-PWK-FL01",
"OO-PWK-FL01\\Profiles$"
]
}
},
The error was still:
With the code:
const data = fs.readFileSync("\\\\OO-PWK-FL01\\Profiles$\\t.beek\\Documents\\Voorbeeld fotos\\test\\Auto Edits\\PSS-config.json", "test");
Forgot to mention, so just to make sure: @pkrishna
@Tais993 Thanks for sharing the details.
Would like to point out that the ‘network’ permission does not influence the file system access. So you can remove OO-PWK-FL01 from network → domains.
To what @dotproduct recommended, can you try accessing any other location, such as a desktop folder, with your plugin to test that it works under normal circumstances?
Ideally, "localFileSystem": "fullAccess" should do the job but I have heard an issue with unusual drives sometimes. As an interim, my recommendation would be to move your files to a more accessible location while we look into this.
To what @dotproduct recommended, can you try accessing any other location, such as a desktop folder, with your plugin to test that it works under normal circumstances?
Yes, no issues when loading files on a mounted drive in my plugin.
As an interim, my recommendation would be to move your files to a more accessible location while we look into this.
I have written a script which moves all files to the C drive temp folder, works for now.
Is there any way to follow bug progress? If no, that’s fine!