Fix a bug when syncing international characters in files#5218
Fix a bug when syncing international characters in files#5218robinsowell wants to merge 1 commit into
Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 152d0de6eb
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
There was a problem hiding this comment.
flattenDirectoryMap() now only inserts a directory key when $val !== [], so an empty folder ([]) is dropped entirely. Because getAllFileNames() depends on this flattened list, empty folders are never passed to syncFiles(), which means no Directory model is created for them during sync. This is a behavior regression from the previous implementation and causes folder-only structures to disappear after synchronization.
Useful? React with 👍 / 👎.
2 participants
Had an issue syncing with a file with ö in the name. Sync would appear to never finish, though the file did end up in the upload directory. Same file could be uploaded fine.
Looks like there are a few differences in unicode character handling- namely getDirectoryMap() → Flysystem Local adapter + getWithMetadata() + basename() on macOS (darwin) can return decomposed Unicode (NFD) while PHP/DB/Flysystem normalization elsewhere uses composed (NFC). Comparisons like $fileInfo['path'] != $clean_filename or getFileByPath() DB lookups can behave unexpectedly.
This fix does a few things: