We have been running OTTO for a customer’s solution for a while and it has been working fine - up until a week ago. When trying to run a deployment of file A, B and C, the migration stops because of an issue with file Z - which isn’t part of the migration.
The error we get is:
Build server error: failed - clone failed: Menu.fmp12. Error: Error getting database info: Error: Folder not found for database: �terRapport.fmp12
The file being referred to in the error is named Återrapport.fmp12.
We have tried different many different things, all resulting in the same error:
Updated OTTOFMS
Restarted the service
Restarted the server
Closed the file Återrapport.fmp12 while running the deployment
Tried moving a completely new file using OTTODeploy
Tried OTTODeploy that was hosted on another server
Tried running the deployment from Dev to Test, and Test to Prod (making sure that it wasn’t just Dev to Test)
We also tried to run a migration of the bothersome file, but that resulted in the following error:
Build server error. http Status: 400. FMS Error 18003: The following files were not open with a NORMAL or CLOSED (for copies) status when the build was started: ÅterRapport.fmp12 NOT_FOUND
The files were very much open on both servers while doing this.
We are really running out of options on what to do, other than renaming the file and hoping that will work (though I’m getting a feeling that it won’t help either).
The last time we had a successful deployment was on the 12th of August. After that, the only thing out the ordinary is that a server maintenance was performed with Windows update.
I’ve checked the logs, comparing the succesdul deployment with the failed ones, but I can’t figure anything out with that.
Do you have any suggestions on what to do?
That’s an interesting one, we’re using the FileMaker CLI to get the file stats on the backend, which is how its looking for those files. I suspect what is happening is that that first character of the filename is being recognized properly when sent through the API but not when it is read through the CLI somehow, or at least that they are being represented as different characters in the two contexts. I can look into fixes on the OttoFMS side to get that working in the future.
If you want to get it fixed now, I would recommend removing that character from the filename somehow. I know that is not an ideal solution but it is the most likely to fix the issue in the short run.
I’ve done some testing on our side and it does look like there is an issue with the character encoding being different between the filemaker CLI and OttoFMS. I will be including a fix for this in the next version of OttoFMS. Thank you for the report!!
Thank you for the response and for including a fix in the upcoming version!
Good to know that renaming the file should work! We have already talked about replacing Å with A since it’s just more proper - and less buggy overall
Thanks for letting us know Marco! We have a fix put together for this which will be released with our next version of OttoFMS. I’ll update y’all here when that is released.
This issue is fixed in version 4.7.0! Files with special characters will now no longer break migrations of unrelated files. It is also now possible to migration files with non-Unicode characters on Linux and MacOS, although there is still an issue deploying files with non-Unicode characters on Windows. We are working on a fix for the issue on Windows which will come out in a future release.
