Hi everyone, wanted to post a question about an irksome behavior in Maya that some of our artists have been encountering lately. We have the following scenario:
An artist has two maya scenes open, each for a different task. In scene 1, they have an animation instance containing ASSET_X, which has already been published multiple times. In scene 2, the hero product ASSET_X_animation_hero.abc is loaded as reference.
If both of these scenes are open simultaneously, whether by the same user or different ones, it’s not possible to publish scene 1 due to an error on the plugin Integrate Hero Version. Basically, it seems like the hero version cannot be overwritten while it is open in another scene. From running some generic tests with maya and manually editing files on disk, we noticed that, while you cannot delete or rename an alembic that is currently open in a scene, you should be able to overwrite it in place.
What’s really odd is that we’ve found some ways to work around this error, but they don’t reliably produce the same results. For example, we tried disabling speedcopy (AYON_COPY_FILE_DISABLE_SPEEDCOPY = 1), and this appeared to avoid the error, but then after exiting and relaunching ayon the issue came back, which seems to suggest some kind of caching problem.
Anyway, we would be curious to know if anyone else has encountered this problem or has thoughts! Thanks in advance
Our logic does not write in-place, but moves the existing files out of the way, copies the new one and only then deletes the original on success of the copy. It’s the best way we can mitigate loss of data.
The fact that a system may put a file lock on these files and how these then behave, is very much dependent on the OS, storage format and perhaps network share being accessed. Admittedly, I’ve heard of very little issues with these in practice even though I expected personally that this would be a very common issue in production - yet I’ve heard little of it.
In short, I’ve seen little reports of this myself even though I expected it to be more common.
Thanks for the reply, Roy. I wonder if there’s a middle ground here where instead of moving/renaming the existing files to backup, we could instead make a copy of them in backup and then overwrite the original. And the behavior of the backup folder would remain the same as it is now, either used to restore or deleted at the end.
I suppose it’s less memory efficient for large files, but I’ll try tinkering with this on my end to see if that gives us the desired results.
I tested out a small modification to the integrate_hero_version plugin to make a copy of the current hero version to backup (instead of renaming it) before copying the new hero version to its destination. This ensures that there is never a moment when the hero version doesn’t exist, and for us fixed the issue.
I’m not sure if this would be of interest to others if there haven’t been any other reports of this problem, but posting for info!