Invalid characters can be created in file names on Android
Please agree to the following
- [X] I have searched existing issues for duplicates
- [X] I agree to follow this project's Code of Conduct
Summary
Android client allows accidentally creating filenames with characters, that break directory access on Windows
System Setup
- Android:
- Android 14
- Samsung Galaxy A52s
- Google Play system update "November 1 2023".
- Cryptomator: 1.10.2
- PC:
- Windows 11, 23H2.
- Cryptomator 1.13.0
- WinFSP installed
- Setting "Default Volume Type": "Automatic"
Cloud Type
Dropbox
Steps to Reproduce
- On Android, select some text containing newlines but no other characters potentially problematic as file name.
- "Copy" the text
- Use "Share > Cryptomator" on some image on a webpage.
- Paste the text into the file name field when uploading to a cryptomator vault.
Expected Behavior
Not completely clear:
- Either Cryptomator on Android should reject the newline, or
- Cryptomator on Windows should allow the newline or, if the issue is with the Windows APIs instead,
- Translate it on Windows to something, the system can work with, or
- Show a more informative error message, maybe a "rename file now" option.
Actual Behavior
When viewing the vault on PC,
- The root directory is listed as usual.
- Trying to copy the file (Ctrl+C, Ctrl+V or drag-and-drop with Ctrl held down) leads to an error
Error 0x80070057: The parameter is incorrect. - Trying to copy the file to a subdirectory will create the same error message, but on Android, the copied file is still visible.
- Subsequently, the sub directory is shown as empty in Explorer, while the root directory remains viewable.
- This pattern repeats with other software, e.g. in
cmd, thedircommand can list the root directory, including the newline character, but fails for the subdirectory with an error "File not found". - Similarly, using
os.listdiron Android yields the list of files (including newline characters) in the root directory, but fails with an exceptionFileNotFoundError: [WinError 206] The filename or extension is too long: 'foo'for the subdirectory.
Reproducibility
Always
Relevant Log Output
Nothing relevant to report for the log files. The last entry prior to reproducing the failing behavior is just "10:36:37.078 [JavaFX Application Thread] INFO o.c.ui.unlock.UnlockWorkflow - Unlock of 'test bug' succeeded.", and nothing after that. Errors show up in Python, CMD "dir" and the directory is listed as empty, but nothing shows up in the log.
Anything else?
The issue is not reproducible by creating a file with newline characters directly on Windows, e.g. using Python, i.e. for the behavior to break, for some reason the file must originally have been created on Android, even though they should have the exactly same name, see screenshot below:
After manually changing the mount type of the vault, it looks like the issue occurs only when mounting with WebDAV. However, originally the mount type was set to "automatic" in the Cryptomator settings, and "Default (WinFsp)" in the vault settings. After testing the different mount types and setting it back to "Default (WinFsp)", the issue is now gone unless I explicitly set the vault to "WebDAV", indicating that Cryptomator may have previously used WebDAV as the default after all.
An example broken vault is attached with password helloworld:
example_broken_vault.zip
The subdirectory subdirectory_populated_by_dragndrop shows the described breakage under webdav access.
Additional faulty behavior: When trying to rename an affected file on Windows in Explorer, I get the error message A filename can't contain any of the following characters: \/ : * ? " < > |
Note that the file name, when doing Ctrl+Shift+C in Windows explorer is
"Z:\radiation
A newly-discovered technique17225849807494802770755157842211.jpg"
(note the newline), so that might be Explorer being more restrictive than the file system and simply not stating, that newline is a forbidden character.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.