Multibyte (Japanese) characters in filenames cause deployment, rename, and copy failures

OttoFMS
1

OttoFMS Version: 4.16.0 FileMaker Server Version: 21.1.1.40 OS: macOS Ventura

Summary

OttoFMS fails to handle database filenames containing multibyte characters (e.g., Japanese). Rename, Copy, and Deploy operations all fail when the filename includes non-ASCII characters such as サンプル.fmp12.

Steps to Reproduce

  1. Host a FileMaker database with a Japanese filename (e.g., サンプル.fmp12) on FileMaker Server.
  2. Try any of the following operations via OttoFMS:

Case 1: Rename

Rename サンプル.fmp12 → sample.fmp12 via OttoFMS console or API.

Result:

OttoFMS API Error: File .fmp12 not found. HTTP Status Code: 500.

Note: The Japanese portion of the filename is completely dropped, leaving only .fmp12.

Case 2: Deploy (JIT Build)

Deploy サンプル.fmp12 from source server to destination server using OttoDeploy.

Result:

Build server error: The following files were not open with a NORMAL or CLOSED 
status when the build was started: サンプル.fmp12 NOT_FOUND

Followed by:

File サンプル.fmp12 not found while opening files
Deployment process failed. Original files are unmodified.

Expected Behavior

OttoFMS should correctly handle filenames containing multibyte characters (Japanese, Chinese, Korean, etc.) for all operations including rename, copy, and deploy.

Additional Notes

  • The file is hosted normally on FileMaker Server and accessible via FileMaker clients without any issues.
  • The same operations succeed when using ASCII-only filenames.
  • This appears to be an encoding issue in how OttoFMS passes filenames internally or to the FMS Admin API.
2

Hey @yama ,

Thanks for the report. We’re using the fmsadmin CLI to do a lot of the file management on the server and it doesn’t work well with multibyte characters. I’ll do some testing on our side as I thought most of the issues were on the windows side and not mac. I’ll keep you updated.

-Kyle