2

I have a library that has a file based interface (it only accept file names/paths). Since the operations are time critical i would like to load the file to memory.

Is there a way to create create in-memory files that have a file path that is resolvable with the normal file access routines?

For example many programs still work if they get some win32 device path or an UNC path instead of a 'classic' windows path. or maybe if that is not the case maybe a softlink can be used to map it into 'normal' filesystem.

One obvious way would be to use some ramdisk software but this would require further manual steps and also requires to tell the program the ramdisks letter.

vlad_tepesch
  • 6,681
  • 1
  • 38
  • 80
  • no way. CreateFile function can not open/create section in memory. because this is *different* objects types - *file* and *section* – RbMm Feb 20 '17 at 10:13
  • *"library that has a file based interface"* - That one needs clarification. Does it take file descriptors? Path names? File handles? C++ streams? Windows `IStream` interfaces? – IInspectable Feb 20 '17 at 10:24
  • You could use a pipe maybe. – Jonathan Potter Feb 20 '17 at 10:51
  • @RbMm please give some reference for your claims. For example is it possible with `CreateFile` to open devices and hard drives/volumes. since often the runtimes file routines are directly mapped to the winapi functions some programms also can work with this. One example may be alternative data streams. Ithink many programmer are not aware of them, but since the above mentioned mapping the most programm still can open them like any other normal file. Or UNC paths that refer files on network shares or even URIs. Maybe there is a way to create a Memory object that is accessible via a device path. – vlad_tepesch Feb 20 '17 at 11:03
  • @IInspectable i added a clarification on that - thank you for pointing at this – vlad_tepesch Feb 20 '17 at 11:05
  • 1
    @vlad_tepesch - also assume you have some handle and call say `ReadFile` or `WriteFile` with it. first what make kernel - convert your handle to `FILE_OBJECT` and convert fail is handle point not to `FILE_OBJECT` (with code `STATUS_OBJECT_TYPE_MISMATCH`) - so you can work only with file objects. local or remote FS, or FS on Virtual Disk, or write own driver, which implement virtual FS. or named pipes but it very restricted in file interface – RbMm Feb 20 '17 at 11:27
  • @RbMm `CreateFileMapping` is more or less the opposite thing of that i want to do. it maps a file to memory so that you can work with it like with a normal memory buffer. I want to allocate some Memory and 'mount' it into the file system as if it is a file, so that other parts/libs/programs can open it like any file. – vlad_tepesch Feb 20 '17 at 11:31
  • @vlad_tepesch - only one way do this - have driver which implement in-memory virtual file system. or driver which implement virtual in-memory only disk, which will be mounted by usual file system. `allocate some Memory and 'mount' it into the file system as if it is a file` - this is absolute impossible – RbMm Feb 20 '17 at 11:36
  • 1
    In principle you can use a RAM disk driver to create disk volumes in memory. In practice you're probably wasting everybody's time - yours and ours. If you don't like the ramdisk approach because you have to install the ramdisk and pass the program the file path (WTF? And you didn't give it a path until today?) you can inject a DLL into the target program, hook the file access functions, read the entire file into memory and lock it in physics memory. Sure, that's not a waste of time at all. – conio Feb 20 '17 at 13:24
  • 1
    @vlad_tepesch - don't try to guess where your bottlenecks are - instead you should measure it. Windows' file caching is quite good - chances are your file will stay in memory once it's read without you doing anything special. – 500 - Internal Server Error Feb 21 '17 at 13:27
  • JFYI: EldoS has a range of products, some of which can be useful. Any of Callback* products would work for your needs. – Eugene Mayevski 'Callback Mar 05 '17 at 16:11

0 Answers0