Please agree to the following
Summary
Opening a large (~15 MB) .txt file in the built-in text editor kills the app process. All vaults are locked afterwards and the password has to be entered again.
System Setup
- Android: not specified by the reporter
- Cryptomator: 2.0.0
Steps to Reproduce
- Unlock a vault
- Open a
.txt file of roughly 15 MB stored in it
- Tapping the file routes it to the built-in text editor
Expected Behavior
The file opens, or the app reports that it is too large for the built-in editor and offers to open it with another app.
Actual Behavior
The app terminates and restarts. Because the process dies, all vaults are locked and the password must be entered again. No error message is shown.
Reproducibility
Always
Relevant Log Output
(no debug log supplied yet)
Anything else?
Files ending in .txt, .md and .todo are always routed to the built-in editor in BrowseFilesPresenter.viewFile(), with no size check and no way to opt out. TextEditorPresenter.loadFileContent() reads the whole file into a single String via FileCacheUtils.read() and hands it to the EditText, so memory use scales with file size — and again on save via binding.textEditor.text.toString(). This is consistent with an OutOfMemoryError on a file of this size.
Possibly related: #588 (text editor performance on large files).
Additional Context
Reported via support ticket. Awaiting developer confirmation.
Please agree to the following
Summary
Opening a large (~15 MB)
.txtfile in the built-in text editor kills the app process. All vaults are locked afterwards and the password has to be entered again.System Setup
Steps to Reproduce
.txtfile of roughly 15 MB stored in itExpected Behavior
The file opens, or the app reports that it is too large for the built-in editor and offers to open it with another app.
Actual Behavior
The app terminates and restarts. Because the process dies, all vaults are locked and the password must be entered again. No error message is shown.
Reproducibility
Always
Relevant Log Output
Anything else?
Files ending in
.txt,.mdand.todoare always routed to the built-in editor inBrowseFilesPresenter.viewFile(), with no size check and no way to opt out.TextEditorPresenter.loadFileContent()reads the whole file into a singleStringviaFileCacheUtils.read()and hands it to theEditText, so memory use scales with file size — and again on save viabinding.textEditor.text.toString(). This is consistent with anOutOfMemoryErroron a file of this size.Possibly related: #588 (text editor performance on large files).
Additional Context
Reported via support ticket. Awaiting developer confirmation.