Just don't use it on Android... yet. Android I/O and filesystems are a clusterfuck: immediate reads after writes to memory mapped files are not immediately reflected. And yes, this depends on the manufacturer and how they control access to private files for each app.

Reply to this note

Please Login to reply.

Discussion

😑 of course.

Is it just an issue of that immediate read after write? e.g. subsequent reads will be fine?

Hard to say... that is the first issue that everybody sees (things disappearing) but there might be others underneath it.

No project has officially supported LMDB on Android yet. Even Mozilla tried.

I’m using it and haven’t noticed anything like that yet. I’ll do some digging to learn more.

Maybe nostr:nprofile1qqs9g69ua6m5ec6ukstnmnyewj7a4j0gjjn5hu75f7w23d64gczunmgpz4mhxue69uhhyetvv9ujumt0wd68ytnsw43qz9thwden5te0v35hgar09ec82c30wfjkcctexf34p3 can chime in on the compatibility between Android filesystems and LMDB. It would be nice to have some form of official OS-level review before using it. Especially when using encrypted storage via Dalvik -> ART apps.

Something tells me that Google has done some analysis and couldn't figure out what the impacts are.

Yeah I’m using it on graphene. I’ll definitely look into it more

Seems to be working fine on notedeck android

nostr:npub1drvpzev3syqt0kjrls50050uzf25gehpz9vgdw08hvex7e0vgfeq0eseet have you ever seen any behavior like this with LMDB? I don’t know if it would effect the rust Nostr but bindings or not.

No, but I tested it few times on Android and only on GrapheneOS