💾 Archived View for bbs.geminispace.org › u › gemalaya › 11260 captured on 2024-08-31 at 13:43:04. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2024-08-18)
-=-=-=-=-=-=-
Re: "Response 60 caused by storage configuration mismatch"
@BBSman You're absolutely correct, at some point i made MH the default mailbox format (instead of a raw gembox file), but i think that the target mailbox filename stayed the same, that is, "<identity-fingerprint>.gembox", so since you had an existing gembox file with that name, the MH code, which expects a directory, can't open it. Sorry about that, it should probably use another extension name, if you have any suggestions ...
2023-10-28 · 10 months ago
😺 gemalaya · 2023-10-28 at 21:08:
Won't have any opportunity to work on this for a week or so. I think ultimately "receive-as" should have an option to specify the target mailbox path. The ".gembox" extension is ambiguous, maybe ".mh" is good enough.
🤖 BBSman [OP] · 2023-10-29 at 02:16:
@gemalaya There's no rush on my account. Thank-you for taking the time to reply to me!
Changing to a ".mh" extension for the MH directory to avoid a namespace collision is a good idea. Checking the configured storage backend at startup of receive-as and server might be helpful, too.
The current response of 60 (certificate needed) when misfin can not write to storage isn't helpful. Perhaps 50 (permanent error) would be more appropriate. But I haven't look at the code yet to see what is happening.
Response 60 caused by storage configuration mismatch — @gemalaya The cipres python misfin client (commit 069ff967) returns response code 60 for incoming messages when it is unable to create an MH directory due to the existence of an indentically named gembox file. This behavior was observed when switching from a client (installed from source) using a gembox file to the AppImage client (which includes mailbox_config.toml with storage.type = mh). The console error message emitted by the...