11:35:28 <m-relay> <m​rdeveloperdude:matrix.org> I am currently implementing monero wallet functionalty into my C++ Qt6 app and I was wondering if monero api supports alternative storage api to "put files directly on local storage". My app maintains all data in a secure virtual filesystem and for this to work I somehow need to make monero use filesystem function hooks or provide an alternative way to handle storage
11:40:45 <sech1> If your virtual filesystem has a path (i.e. mounted to a folder), regular file functions will work with it
18:40:52 <m-relay> <m​rdeveloperdude:matrix.org> Of course. In taht case I would not ask this question. My virtual filesystem lives in a sparse file and since I am using Qt I can use all the file code as if it was a normal filesystem. This is accomplished by a custom file-system handler that works with that file instead of the actual OS filesystem.
18:41:53 <m-relay> <m​rdeveloperdude:matrix.org> But since wallet api is not implemented on top of Qt I need to find a way to somehow port file access commands to work with my system
19:01:25 <m-relay> <r​brunner7:monero.social> That "custom file-system handler", is that based on a Qt capability? And only works if you restrict your file accesses to Qt functions only?
19:04:26 <m-relay> <r​brunner7:monero.social> Guessing that the answer is "yes", I go on and suspect that what you want is either not possible, or would at least mean that you maintain a fork of Monero wallet code indefinitely, i.e. at least as long as your app lives.
19:05:50 <m-relay> <r​brunner7:monero.social> That fork would contain new methods and/or mechanisms to implement what you need. And I think that would be so special that you could not upstream and make it part of Monero's standard code, hence you maintaining a fork.
19:07:42 <sech1> This is why virtual filesystems are usually implemented as an OS driver, so you can just mount them to a folder
19:10:11 <m-relay> <r​brunner7:monero.social> I once solved a problem with the Monero wallet on Windows by making the wallet directly call Win32 API functions to read and write wallet files. So yes, intercepting anything there, without any code changes, would be a Windows file system driver.
19:11:59 <m-relay> <m​rdeveloperdude:matrix.org> I think the use case is valid, I want to create an app that does not leave stuff up to the OS especially relating to security of data. I know on linux there is FUSE and LD_PRELOAD and I can probably hack around to have all file acecss wrapped but all those are pretty ugly for various reasons. If monero had a switchable "backend" I could simply tie iinto that. But I guess that is n<clipped message>
19:12:01 <m-relay> <m​rdeveloperdude:matrix.org> ot a common usecase and not a feature that monero has at this time
19:13:18 <m-relay> <m​rdeveloperdude:matrix.org> The idea is to make an app that uses a "encrypted by default" virtual filesystem living in a sparse file in the OS filesystem. So far a lot of features are already there, but now is the challenge of including stuff that is not made on top of Qt
19:14:03 <sech1> Monero wallet files are encrypted by default
19:14:05 <m-relay> <r​brunner7:monero.social> Oh yes, I think the idea is sound, and would have merit. It just meets an utterly unprepared Monero codebase :)
19:15:32 <sech1> you could try to play with linker flags and link your code to your own fopen/fread/fwrite version or whatever Monero code uses
19:16:11 <sech1> maybe it's possible to force linker ignore duplicate symbols and make it use the first symbol it encounters (your interceptor)
19:17:10 <m-relay> <r​brunner7:monero.social> Hmm, I think you would also have to intercept a lot of OS methods that deals with filenames and directory queries. Some of them in Monero code, some maybe in Boost.
19:18:26 <m-relay> <r​brunner7:monero.social> That all would be so brittle, and so hacky ...
19:19:05 <m-relay> <m​rdeveloperdude:matrix.org> If my research is correct, there is just one file per wallet and then there is the blockchain which uses some kind of memory mapped database engine called LMDB
19:19:31 <m-relay> <r​brunner7:monero.social> Two files per wallet.
19:19:33 <m-relay> <m​rdeveloperdude:matrix.org> It would indeed be brittle and hacky.
19:19:44 <m-relay> <r​brunner7:monero.social> At least.
19:20:11 <m-relay> <r​brunner7:monero.social> Well, sometimes there are 3.
19:21:22 <m-relay> <m​rdeveloperdude:matrix.org> So is it completely far fetched to suggest this as a feature? I mean it would if nothing else provide an oportunity to "tidy" the codebase relating to file access and tie it up in a nice testable bundle
19:22:00 <m-relay> <m​rdeveloperdude:matrix.org> I can just leave monero outside for now and when my app becomes "the future of the internet" then I can come and ask politely 😄
19:22:48 <m-relay> <m​rdeveloperdude:matrix.org> OK, I'll do that. Thanks for rubber-ducking with me!
20:05:32 <moneromooo> I'm reasonably sure wallet2 uses epee functions to read/write as a block, save_string_to_file or simiarly named.
20:05:45 <moneromooo> So replace these two and you *should* be good, or almost.
20:06:15 <moneromooo> There's also advistory lock functions, which can be taken out.
20:06:58 <moneromooo> There are no piecemeal fwrite/fread and the like to the wallet keys or cache..
20:42:35 <m-relay> <m​rdeveloperdude:matrix.org> What is epee? I tried googling it without much luck
20:43:21 <UkoeHB> mrdeveloperdude: utils library inside monero core
20:49:36 <m-relay> <m​rdeveloperdude:matrix.org> Ah ok cool so it is already in one place
20:50:12 <m-relay> <m​rdeveloperdude:matrix.org> I think this is going to be more work than it is worth right now. I will just maintain monero wallet separately. Since the files are encrypted it will be fine