Open an in-memory file with the default system application

[berzasnon]

This is the situation: I have a database wich contains medical information about the patients of a clinic. A table of the database has a BLOB field for any kind of relevant document about the patient: X-ray images, previous medical histories in (let's say) PDF format... you name it. I know that the use BLOBs to store files is controversial, but the data protection laws in my country force to do it that way, so that's not really the point this time. I'm comfortable storing files in BLOBs anyway.

The same data protection laws that force the use of BLOBs also demand to avoid as far as possible the use of temporary files. That makes sense, but also causes an issue when the time comes to view the files stored in the BLOB. I have no problem showing the files if they are images, since I can easily create an image viewer; but if the file is anything different, like a .docx file, and I don't want to create a file viewer for any known file type, the easy way is to open the file with the default system application. It's not a big deal with QDesktopServices and QUrl, but can it be done without creating a temporary file?

My first tought was that it's impossible; if the file only exists in the app memory, no other generic (not necessarily Qt) application can access that memory to open the file. Anyway I have read the documentation for QSharedMemory, QUrl, QFile, QBuffer and anything remotely related to the issue, and I keep thinking that the answer is still no, it can't be done without creating a temporary file.

So my question is simple: am I right, or have I overlooked some possible solution?

[Rhayader]

Maybe you can use a ramdrive to store the data. On linux it is easy with tmpfs.

[wysota]

My first tought was that it's impossible; if the file only exists in the app memory, no other generic (not necessarily Qt) application can access that memory to open the file. Anyway I have read the documentation for QSharedMemory, QUrl, QFile, QBuffer and anything remotely related to the issue, and I keep thinking that the answer is still no, it can't be done without creating a temporary file.

So my question is simple: am I right, or have I overlooked some possible solution?

I think it highly depends whether a particular application has an ability to read directly from a data buffer or a pipe. If yes then QDesktopServices will not help much here but you can still launch the app in question manually using means provided by the system and then feed the app with appropriate data (e.g. using ActiveX).

[berzasnon]

Maybe you can use a ramdrive to store the data. On linux it is easy with tmpfs.

Thank you for the suggestion. I also thought about that, but it would be the same as creating the temporary file in a physical drive, with the only difference that the files put in the ramdrive wouldn't survive a system reboot.


I think it highly depends whether a particular application has an ability to read directly from a data buffer or a pipe. If yes then QDesktopServices will not help much here but you can still launch the app in question manually using means provided by the system and then feed the app with appropriate data (e.g. using ActiveX).

If you can't think of a generic way to do it then nobody will ;) Thank you for your help.

Writing a specific way to open the file for every specific file type is not like writing a viewer for every file type, but sort of considering that nothing guarantees it's even possible for every software combination (PDF readers/Office or Office compatible suites and their different versions/whichever other software needed) present in the computer. Not to speak that it would be totally platform dependant.

So I guess I'm forced to use temporary files. Well, at least I'm sure I have avoided them as far as possible :)

[wysota]

Writing a specific way to open the file for every specific file type is not like writing a viewer for every file type, but sort of considering that nothing guarantees it's even possible for every software combination (PDF readers/Office or Office compatible suites and their different versions/whichever other software needed) present in the computer. Not to speak that it would be totally platform dependant.
That's not exactly what I meant. If you're on Windows, you can use WinAPI to ask for the default app registered to handle a particular file type and if it is in a list of solutions known to work, then call it.


So I guess I'm forced to use temporary files. Well, at least I'm sure I have avoided them as far as possible :)
A possible solution would be to use an encrypted ramdisk filesystem to store those temporary files.

[berzasnon]

That's not exactly what I meant. If you're on Windows, you can use WinAPI to ask for the default app registered to handle a particular file type and if it is in a list of solutions known to work, then call it.

Still would be a no generic and no guaranteed solution, because nothing assures that the default application will be able to read the data buffer. In that case would be impossible to open the file stored in the BLOB and would have to create a temporary file anyway.

The combination of trying to get the default app to open the in-memory file + creating a temporary file as a fallback method would be the safest, but honestly I can't see the difference between creating a temporary file now and then and creating it every time: creating the file only when strictly needed is safer than creating it every time, but both are unsafe anyway.


A possible solution would be to use an encrypted ramdisk filesystem to store those temporary files.

I'm confused; the default system app ought to have read access to that encrypted ramdisk filesystem, and (correct me if I'm wrong) that would only be possible if the whole system has access to such ramdisk. I mean, the app (and the OS) would see the ramdisk as any other filesystem present in the computer, encrypted or not. As I said to Rhayader, the temporary files wouldn't survive a reboot, but besides that I can't see the benefit in using a ramdisk.

Maybe I'm not getting the point. If so, please tell me.

[wysota]

Still would be a no generic and no guaranteed solution, because nothing assures that the default application will be able to read the data buffer.
Going this way, there is never a generic and guaranteed solution because there might be no default application for a particular file type installed at all and creating a temporary file wouldn't have helped either.


I'm confused; the default system app ought to have read access to that encrypted ramdisk filesystem, and (correct me if I'm wrong) that would only be possible if the whole system has access to such ramdisk.
No, not really. It should be possible to execute the program with special privileges that allow it access to a particular directory, disallowing anyone else.


besides that I can't see the benefit in using a ramdisk.
The 'ramdisk' part is not important here. The 'encrypted' is.

If you're expecting to thwack a magic wand and have a ready solution then that's probably not going to happen. I'm sure your requirement can be fulfilled but you need to get your hands dirty in the low-level system behaviour. You would be much better asking your question on some geek Windows forum than here.

[berzasnon]

No, not really. It should be possible to execute the program with special privileges that allow it access to a particular directory, disallowing anyone else.

The 'ramdisk' part is not important here. The 'encrypted' is.

If you're expecting to thwack a magic wand and have a ready solution then that's probably not going to happen. I'm sure your requirement can be fulfilled but you need to get your hands dirty in the low-level system behaviour. You would be much better asking your question on some geek Windows forum than here.

Don't get me wrong, I'm not expecting a magic wand solution, I'm just concerned about the effort/benefit ratio. I can get my hands dirty and finally have to create a temporary file anyway in some situations, so I think it's not worth the effort. Since the use of temporary files is not strictly forbidden, I think in this case is justified to use them.

Funny thing: I have been testing, and if I create a .pdf temporary file and open it with the default application (Sumatra PDF, can't tell if the result would be the same with Adobe Reader), I can delete the file inmediately after being opened (a really temporary file, a few seconds of life span) and Sumatra PDF will keep showing the file and won't complain. Obviously it doesn't lock the files it opens. That makes sense, since it opens the file for read-only access.

Maybe getting every application to open the temporary file as read-only...

[wysota]

Funny thing: I have been testing, and if I create a .pdf temporary file and open it with the default application (Sumatra PDF, can't tell if the result would be the same with Adobe Reader), I can delete the file inmediately after being opened (a really temporary file, a few seconds of life span) and Sumatra PDF will keep showing the file and won't complain. Obviously it doesn't lock the files it opens. That makes sense, since it opens the file for read-only access.

Firstly, on Windows, most apps usually open files in exclusive mode so you won't be able to delete the file. Secondly, deleting the file does not delete it from disk, it can still be accessed using freely available tools. Thirdly, even if there is no file, if an app keeps the data in memory, a clever attacker can access it directly from the process memory. If you don't have a secure application that prevents all these (and regular apps don't) your system will not be safe.