Hi,
I’m having an issue updating the PATH of a Published File via the API.
I’m building a custom publisher and it creates a Published File for frames from inside Nuke.
The frames are at that point still in a work directory.
A farm job get’s sent to render versions and copy the files to a publish directory.
The Published File Path then needs to be updated to the Published File Path.
I’m getting this error:
API update() CRUD ERROR #6: Create failed for [Attachment]: Path G:/Projects/SHOWNAME/shots/pipeline/TST/color_pipeline/compositing/publish/output/color_pipeline_comp_v001/frames/3200x1800/exr/color_pipeline_comp_v001.%04d.exr doesn’t match any defined Local Storage.
The command that is run is:
data = {‘path’: {‘local_path’: published_frames, ‘name’: ‘Published Frames’} }
result = sg.update(‘PublishedFile’, sg_publish.get(“id”), data)
What is the API telling me here? Because this definately matches the local storage as far as g:/projects/SHOWNAME is concerned.
It looks like there might be a discrepancy between your path and your storage root: G:/Projects/SHOWNAME/shots/pipeline/TST/color_pipeline/compositing/publish/output/color_pipeline_comp_v001/frames/3200x1800/exr/color_pipeline_comp_v001.%04d.exr has an uppercase G as the drive letter, while g:/projects/SHOWNAME has a lowercase g.
These need to be in step. Try fixing that and let us know if it fixes the problem.
it seemed like that wasn’t the issue… I did a path.replace("/", “\”) before and it fixed it.
So Apparently the api doesn’t take a windows path with forward slashes as valid.
Maybe that could be looked into and if it doesnt cause problems it could be made flexible on the slahes?
I’be fixed it by a replace but it doesnt make sense that it would fail just because the slahes are one way and not the other?
Hi Ricardo – I took a look at your site, and as you say, your File Storage path does indeed have an uppercase G. I do know that Toolkit automatically uses the correct platform-specific separator when forming paths from templates, but it looks like the Python API needs an exact match—including forward slash vs. back slash—with the storage root for attachment fields. I was able to repro exactly what you’re seeing. I’ll run this by the ecosystem team (ecosystem includes APIs) and see if we can handle it better.
Cheers!
Maybe just giving a hint in the CRUD error that path slashes are the most likely culprit?
It’s such an easy fix on my end, I just didnt think that would cause an issue