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

Consider moving state to $XDG_STATE_HOME as opposed to $XDG_CACHE_HOME #5

Open
shymega opened this issue Sep 11, 2024 · 8 comments
Open
Labels
invalid This doesn't seem right

Comments

@shymega
Copy link

shymega commented Sep 11, 2024

To follow-up from our Matrix chat:

Currently, neverest stores state/locks in two places:
$XDG_CACHE_HOME/pimalaya and $XDG_RUNTIME_DIR/pimalaya.

The former is the one I'd like to see changed to $XDG_STATE_HOME/pimalaya, as
storing in $XDG_CACHE_HOME/pimalaya runs the risk of accidental deletion of
the state files.

The latter isn't as much of an issue.

We could, maybe in the future, store state in the IMAP/Maildir backends as well.

@codethief
Copy link

In how far is it safe vs. not safe to delete $XDG_CACHE_HOME/pimalaya? Could anything go wrong next time I run neverest synchronize? If yes, that folder should definitely be considered state.

@soywod
Copy link
Member

soywod commented Sep 20, 2024

In how far is it safe vs. not safe to delete $XDG_CACHE_HOME/pimalaya? Could anything go wrong next time I run neverest synchronize? If yes, that folder should definitely be considered state.

The scariest scenario is when you delete your data, the root-dir, without deleting the cache. It may consider that all emails were removed and needs to be removed remotely.

If you delete the cache, Neverest will not be able to know if sth has been deleted right side or added left side. For now it comes with safe defaults: it will always take the path that does not delete data. Worst case you just get back emails you previously deleted, or get duplicates (same email in trash and inbox).

I believe cache is not crucial. It just helps the sync to take the right decision. Hence my initial choice behind the cache directory. That said, the state directory also makes sense, and may be a safer default. So let's do it!

@soywod soywod added this to Pimalaya Sep 20, 2024
@soywod soywod moved this to Todo in Pimalaya Sep 20, 2024
@codethief
Copy link

codethief commented Sep 20, 2024

@soywod Thanks for elaborating! That is quite scary indeed.

Would it make sense to add a "readonly" flag to protect either left or right side from accidental changes or a flag to indicate the "direction" of the sync? In my case I'm only ever interested in syncing from left to right. (Except for the hopefully unlikely case when I need to restore left from my backup on the right.)

@soywod
Copy link
Member

soywod commented Sep 20, 2024

Would it make sense to add a "readonly" flag to protect either left or right side from accidental changes or a flag to indicate the "direction" of the sync?

You have permissions for that purpose:

# Left backend permissions
#
# In this example, we set up a full permissive backend (default
# behaviour):
#
left.folder.permissions.create = true
left.folder.permissions.delete = true
left.flag.permissions.update = true
left.message.permissions.create = true
left.message.permissions.delete = true

@shymega
Copy link
Author

shymega commented Dec 24, 2024

In how far is it safe vs. not safe to delete $XDG_CACHE_HOME/pimalaya? Could anything go wrong next time I run neverest synchronize? If yes, that folder should definitely be considered state.

It's not safe to delete it IMO, given it stores state. It should be in the XDG state directory - cache is for temporary files, and admittedly - sometimes state - but for this use-case of neverest, this should not be considered safe.

@soywod
Copy link
Member

soywod commented Dec 25, 2024

Then I will fix it for the next release. Thank you for your feedback!

@soywod soywod moved this to Todo in Pimalaya Dec 25, 2024
@soywod soywod added the invalid This doesn't seem right label Dec 25, 2024
@shymega
Copy link
Author

shymega commented Dec 25, 2024

Did you mean to add the Invalid label? 🤔

@soywod
Copy link
Member

soywod commented Dec 25, 2024

Yes, in a way that "this implementation does not seem right". But not sure if it's a common practice, I can just remove it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
invalid This doesn't seem right
Projects
Status: Todo
Development

No branches or pull requests

3 participants