Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can't change vault "Unlock Duration" while unlocked #180

Open
2 tasks done
sindastra opened this issue Feb 23, 2022 · 9 comments
Open
2 tasks done

Can't change vault "Unlock Duration" while unlocked #180

sindastra opened this issue Feb 23, 2022 · 9 comments
Labels
state:confirmed We are able to reproduce the reported behavior type:bug Something isn't working

Comments

@sindastra
Copy link

Please agree to the following

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?

image

@sindastra sindastra added the type:bug Something isn't working label Feb 23, 2022
@tobihagemann
Copy link
Member

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
Copy link
Author

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

@phil1995
Copy link
Collaborator

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
Copy link
Author

@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
Copy link
Collaborator

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
Copy link

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.

@github-actions github-actions bot added the state:stale Issues without any activity that will be closed automatically label Apr 21, 2023
@sindastra
Copy link
Author

This comment is activity that occurred.

@github-actions github-actions bot removed the state:stale Issues without any activity that will be closed automatically label Apr 22, 2023
Copy link

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.

@github-actions github-actions bot added the state:stale Issues without any activity that will be closed automatically label Apr 22, 2024
@sindastra
Copy link
Author

This comment is activity that occurred.

@github-actions github-actions bot removed the state:stale Issues without any activity that will be closed automatically label Apr 23, 2024
@iammajid iammajid added state:confirmed We are able to reproduce the reported behavior and removed state:confirmed We are able to reproduce the reported behavior labels Oct 31, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
state:confirmed We are able to reproduce the reported behavior type:bug Something isn't working
Projects
None yet
Development

No branches or pull requests

4 participants