Can't change vault "Unlock Duration" while unlocked

[sindastra]

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

Can't change vault "Unlock Duration" while unlocked

System Setup

• iOS: 15.3.1
• Cryptomator: 2.1.2 (838)

Cloud Type

No response

Steps to Reproduce

1. Tap on unlocked vault
2. Tap on Unlock Duration
3. Tap on "Indefinite"
4. Tap on "Confirm & Lock Now"

Expected Behavior

It should lock the vault, and change the unlock duration.

Actual Behavior

It gives me an error message (see screenshot below). Note that this has worked in the past, but now it doesn't, and it repeatedly doesn't. Manually locking and changing the duration works, though.

Reproducibility

Intermittent

Relevant Log Output

No response

Anything else?

[tobihagemann]

The error message could indeed be better. But it means that there are running/pending operations (like uploads) and can't be locked yet. Is it maybe related to #173 because the vault is "stuck"?

[sindastra]

Well, I do have a "stuck" vault, as described in the issue you mention. Manually locking works without issues, though.

[phil1995]

The manual lock works because it is a forced lock. But I agree that we should definitely make the error message user friendly and prevent the vault from getting stuck.

[sindastra]

@phil1995 Thank you for clarifying. But shouldn't a manual lock ask for confirmation before doing a forced lock? It sounds "dangerous" to have it force by default without confirmation. I wasn't aware it's a forced lock.

[phil1995]

It is not as dangerous as it sounds, because we "register" (save) all actions (uploads, etc.) as tasks in the database and thus we can theoretically recover them. In addition, if there are file changes, they are first made locally and are therefore also not lost. The problem that other applications have opened the file while the vault is getting locked, we can't take into account anyway, because we lack information about this (due to a bug in the FileProviderExtension API, we are only notified about the start of an access but not about the end). Nevertheless, the changes will still be applied locally to the file and just not uploaded immediately.

But you are of course right that a user should be explicitly asked again before a forced lock. In fact, we already have this feature planned, that every time a graceful lock is performed and if this fails, the user is notified about it via an alert and has the option to force lock the vault.

[github-actions[bot]]

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.

[sindastra]

This comment is activity that occurred.

[github-actions[bot]]

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.

[sindastra]

This comment is activity that occurred.