-
-
Notifications
You must be signed in to change notification settings - Fork 113
Cannot write on cache store occasionally during use. #155
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Comments
Do you have more than one account set up? I suspect this is due to concurrent access attempts. Improving this is next on the roadmap. |
I setup a single box with the proxy service and a single fetchmail process on that. Apparently no. |
Even, that was not the case when not using the cache store. |
To be clear, I mean more than one email address, not necessarily multiple processes. It could also I suppose be caused by a single address but multiple simultaneous access attempts (some clients often do this to monitor multiple folders). Regardless, I can't think of anything else that could be causing this, but will be looking at improvements to concurrent usage in the relatively near future. |
Here it is a single email addresss (on Office 365) and a single client (fetchmail) with a single process run AFAIK. |
The concurrent-config branch has a proposed solution for this issue. Could you take a look and see whether the issue still occurs? |
In the meantime a few things changed on this side, including a new Python version. Apparently the previous issue seems disappeared. Maybe something was broken in/with Python 3.9? |
Thanks for following up. I'll keep this open until that branch is ready to merge - in the meantime please do let me know if it happens again. |
I've decided to merge this branch, but please feel free to re-open the issue if it re-occurs. Thanks for the help with this. |
I'm using the IMAP proxy via fetchmail in daemon mode, with --cache-store. During the 24 hrs of use the log reports:
Error saving state to cache store file at <cache_filename> - is the file writable?
Apparently, it succeeds in connecting just one sec after. The log shows this message every 1/1.5 hour or so.
The text was updated successfully, but these errors were encountered: