The Zoo desktop app regularly stops being able to write its own KCL files to the local drive project folder Zoo itself created when the project was initially started. Zoo was able to write several KCL files but now fails. The Zoo dialog will even indicate that the files are available, when questioned that they are not in the folder or Zoo Explorer, Zoo will either attempt to re-draft the file or more often confirm that the non-existent file(s) are present when in fact they are not. This can go several rounds of back and forth.
Needless to say this is a massive issue, with a great deal of time lost. Worse is that this seems to be triggered when an existing part needs to be updated, resulting an either a useless part altogether or an endless loop of Zoo thinking it is providing the corrected part when in fact Zoo is just presenting the original, unmodified part.
This is a known issue we’re actively working to fix. In some cases, Zookeeper can report that a file was successfully created or updated even though that change didn’t make it to the local project folder.
We understand how disruptive this is, especially when it results in lost work. If there’s work you’d like us to try to recover, please let us know by requesting technical support and we’ll take a look.
Thank you for the update. Zoo is great if and when it works but between this issue and the non-stop hangs, dropped connections, the impact on productivity is massive. This is whether I’m using the desktop app or the web-based tool. It appears that there are some serious issues on the backend in supporting longer sessions and larger projects, file counts, edits etc.
So I had an issue where it would hang and they found an issue that should be corrected with an update in the next day or so. Fingers crossed it solves some issues.
