I'd like to simulate a file without writing it on disk. I have a file at the end of my executable and I would like to give its path to a dll. Of course since it doesn't have a real path, I have to fake it.
I first tried using named pipes under Windows to do it. That would allow for a path like \\.\pipe\mymemoryfile but I can't make it works, and I'm not sure the dll would support a path like this.
Second, I found CreateFileMapping and GetMappedFileName. Can they be used to simulate a file in a fragment of another ? I'm not sure this is what this API does.
What I'm trying to do seems similar to boxedapp. Any ideas about how they do it ? I suppose it's something like API interception (Like Detour ), but that would be a lot of work. Is there another way to do it ?
Why ? I'm interested in this specific solution because I'd like to hide the data and for the benefit of distributing only one file but also for geeky reasons of making it works that way ;)
I agree that copying data to a temporary file would work and be a much easier solution.
Use BoxedApp and do not worry.
You can store the data in an NTFS stream. That way you can get a real path pointing to your data that you can give to your dll in the form of
x:\myfile.exe:mystreamname
This works precisely like a normal file, however it only works if the file system used is NTFS. This is standard under Windows nowadays, but is of course not an option if you want to support older systems or would like to be able to run this from a usb-stick or similar. Note that any streams present in a file will be lost if the file is sent as an attachment in mail or simply copied from a NTFS partition to a FAT32 partition.
I'd say that the most compatible way would be to write your data to an actual file, but you can of course do it one way on NTFS systems and another on FAT systems. I do recommend against it because of the added complexity. The appropriate way would be to distribute your files separately of course, but since you've indicated that you don't want this, you should in that case write it to a temporary file and give the dll the path to that file. Make sure you write the temporary file to the users' temp directory (you can find the path using GetTempPath in C/C++).
Your other option would be to write a filesystem filter driver, but that is a road that I strongly advise against. That sort of defeats the purpose of using a single file as well...
Also, in case you want only a single file for distribution, how about using a zip file or an installer?
Pipes are for communication between processes running concurrently. They don't store data for later access, and they don't have the same semantics as files (you can't seek or rewind a pipe, for instance).
If you're after file-like behaviour, your best bet will always be to use a file. Under Windows, you can pass FILE_ATTRIBUTE_TEMPORARY to CreateFile as a hint to the system to avoid flushing data to disk if there's sufficient memory.
If you're worried about the performance hit of writing to disk, the above should be sufficient to avoid the performance impact in most cases. (If the system is low enough on memory to force the file data out to disk, it's probably also swapping heavily anyway -- you've already got a performance problem.)
If you're trying to avoid writing to disk for some other reason, can you explain why? In general, it's quite hard to stop data from ever hitting the disk -- the user can always hibernate the machine, for instance.
Since you don't have control over the DLL you have to assume that the DLL expects an actual file. It probably at some point makes that assumption which is why named pipes are failing on you.
The simplest solution is to create a temporary file in the temp directory, write the data from your EXE to the temp file and then delete the temporary file.
Is there a reason you are embedding this "pseudo-file" at the end of your EXE instead of just distributing it with our application? You are obviously already distributing this third party DLL with your application so one more file doesn't seem like it is going to hurt you?
Another question, will this data be changing? That is are you expecting to write back data this "pseudo-file" in your EXE? I don't think that will work well. Standard users may not have write access to the EXE and that would probably drive anti-virus nuts.
And no CreateFileMapping and GetMappedFileName definitely won't work since they don't give you a file name that can be passed to CreateFile. If you could somehow get this DLL to accept a HANDLE then that would work.
And I wouldn't even bother with API interception. Just hand the DLL a path to an acutal file.
Reading your question made me think: if you can pretend an area of memory is a file and have kind of "virtual path" to it, then this would allow loading a DLL directly from memory which is what LoadLibrary forbids by design by asking for a path name. And this is why people write their own PE loader when they want to achieve that.
I would say you can't achieve what you want with file mapping: the purpose of file mapping is to treat a portion of a file as if it was physical memory, and you're wanting the reciprocal.
Using Detours implies that you would have to replicate everything the intercepted DLL function does except from obtaining data from a real file; hence it's not generic. Or, even more intricate, let's pretend the DLL uses fopen; then you provide your own fopen that detects a special pattern in the path and you mimmic the C runtime internals... Hmm is it really worth all the pain? :D
Please explain why you can't extract the data from your EXE and write it to a temporary file. Many applications do this -- it's the classic solution to this problem.
If you really must provide a "virtual file", the cleanest solution is probably a filesystem filter driver. "clean" doesn't mean "good" -- a filter is a fully documented and supported solution, so it's cleaner than API hooking, injection, etc. However, filesystem filters are not easy.
OSR Online is the best place to find Windows filesystem information. The NTFSD mailing list is where filesystem developers hang out.
How about using a some sort of RamDisk and writing the file to this disk? I have tried some ramdisks myself, though never found a good one, tell me if you are successful.
Well, if you need to have the virtual file allocated in your exe, you will need to create a vector, stream or char array big enough to hold all of the virtual data you want to write.
that is the only solution I can think of without doing any I/O to disk (even if you don't write to file).
If you need to keep a file like path syntax, just write a class that mimics that behaviour and instead of writing to a file write to your memory buffer. It's as simple as it gets. Remember KISS.
Cheers
Open the file called "NUL:" for writing. It's writable, but the data are silently discarded. Kinda like /dev/null of *nix fame.
You cannot memory-map it though. Memory-mapping implies read/write access, and NUL is write-only.
I'm guessing that this dll cant take a stream? Its almost to simple to ask BUT if it can you could just use that.
Have you tried using the \?\ prefix when using named pipes? Many APIs support using \?\ to pass the remainder of the path directly through without any parsing/modification.
http://msdn.microsoft.com/en-us/library/aa365247(VS.85,lightweight).aspx
Why not just add it as a resource - http://msdn.microsoft.com/en-us/library/7k989cfy(VS.80).aspx - the same way you would add an icon.
Related
I have some files (.xml extensions) that my app requires them to be present as long as my application is open.
So, is there a cross-platform solution to mark these files as "File in use" so that the user cannot delete or modify them?
Since you specify you need it to work cross-platform, you might want to use Qt with QFile::setPermissions and set it to QFileDevice::ReadOwner. Do note the platform-specifc notes the documentation makes. There is nothing similar in the C++ Standard Library as far as I am aware.
Edit: turns out I was wrong! Since C++17 can use std::filesystem::permissions and set the permissions to read-only.
These steps could work for you:
read and store the file(s) to memory (or perhaps a temporary storage if memory is a problem)
implement a file-change watcher (concrete solutions here How do I make my program watch for file modification in C++? )
if a change occurs, you could:
overwrite the changed file (from data you have in memory or in temporary storage); or create the file anew if it was deleted
notify the user that the files have been changed and the program might not work correctly
Not sure about this one, never tried it, but could theoretically block access:
Open the file(stream) for reading and writing but don't close it (until program finishes)
try to even read or write from/to file
File management is always tricky because it is operating system dependant, although most OS behave similarly. Here you have some ideas that could work:
If the .xml files are never modified: make them read-only. The C++17 standard introduced a method to configure file permissions (https://en.cppreference.com/w/cpp/filesystem/permissions), so you can always ensure that they are read-only from your application. However, this will not prevent some user deleting them, but for example in linux you will see a warning when trying to remove the files with "rm".
If the files are not that big, I would just parse the XML files at the beginning of the program and keep the data structures in RAM, so then you can just forget about the actual files in disk.
An alternative would be to just copy the .xml files to a temporary location, rarely someone will be deleting temporary files. The "tmp" directories are platform dependant, but the lib has a method to create temporary files, so you could create one for each xml and copy their contents: http://www.cplusplus.com/reference/cstdio/tmpfile/
Since it is platform-dependent and you want a cross-platform solution, you'll have to make it by preprocessor flags. So you have to consider all the platforms that your application will have support for and write special code for each of them. As far as I know with Windows and Linux you can use std::filesystem::permissions. Just set read-only and OS will automatically warn the user once he wants to remove any of marked files. Also, tmpfile is mentioned in the answers could be a good fit if you don't say I exactly need to set file permissions.
I have a legacy C library which accepts a file, works on the file payload and writes the processed payload to an output file. The functions in the library are tightly coupled with FILE i.e. it passes around FILE handle to the functions and functions do file IO to retrieve the necessary data.
I want to modify this library such that it works with in memory data(No file IO). i.e pass a binary array and get back binary array.
I have 2 solution in mind
Implement a InMemory File module (which implants all operations as C FILE) and override the default file operations with new implementation using typedef or #define
Pass around binary array to all the functions of the library and retrieve the necessary data from the same.
Which one of this is better or any other better way to solve the problem
I would suggest not to change legacy code if any other code depends on it.
If you are building for a somewhat POSIX compliant platform, you can use fmemopen http://pubs.opengroup.org/onlinepubs/9699919799/functions/fmemopen.html
For Windows maybe this might help
C - create file in memory
I don't know what is the exact purpose of changing legacy code.The issue which is I understand is the overhead caused by reading and writing. But there are many methods are available to resolve overhead issues as:
As already told you can use fmemopen
You may also use mmap for plain read/write should make little difference; either way, everything happens through the filesystem cache/buffers.
You can also use tmpfs to leverage memory as (temporary) files also known as RAMDisk as storage. As the files are washed out easily as files are temporary already in nature
Another solution - you can use inmemory database (TimesTen for sample)
I am working on a game, and one of the requirements per the licence agreement of the sound assets I am using is that they be distributed in a way that makes them inaccessible to the end user. So, I am thinking about aggregating them into a flat file, encrypting them, or some such. The problem is that the sound library I am using (Hekkus Sound System) only accepts a 'char*' file path and handles file reading internally. So, if I am to continue to use it, I will have to override the c stdio file functions to handle encryption or whatever I decide to do. This seems doable, but it worries me. Looking on the web I am seeing people running into strange frustrating problems doing this on platforms I am concerned with(Win32, Android and iOS).
Does there happen to be a cross-platform library out there that takes care of this? Is there a better approach entirely you would recommend?
Do you have the option of using a named pipe instead of an ordinary file? If so, you can present the pipe to the sound library as the file to read from, and you can decrypt your data and write it to the pipe, no problem. (See Beej's Guide for an explanation of named pipes.)
Override stdio in a way that a lib you not knowing how it works exactly works in a way the developer hasn't in mind do not look like the right approach for me, as it isn't really easy. Implement a ramdrive needs so much effort that I recommend to search for another audio lib.
The Hekkus Sound System I found was build by a single person and last updated 2012. I wouldn't rely on a lib with only one person working on it without sharing the sources.
My advice, invest your time in searching for a proper sound lib instead of searching for a fishy work around for this one.
One possibility is to use a encrypted loopback filesystem (google for additional resources).
The way this works is that you put your assets on a encrypted filesystem, which actually lives in a simple file. This filesystem gets mounted someplace as a loopback device. Password needs to be supplied at attach / mount time. Once mounted, all files are available as regular files to your software. But otherwise, the files are encrypted and inaccessible.
It's compiler-dependent and not a guaranteed feature, but many allow you to embed files/resources directly into the exe and read them in your code as if from disk. You could embed your sound files that way. It will significantly increase the size of your exe however.
Another UNIX-based approach:
The environment variable LD_PRELOAD can be used to override any shared library an executable has been linked against. All symbols exported by a library mentioned in LD_PRELOAD are resolved to that library, including calls to libc functions like open, read, and close. Using the libdl, it is also possible for the wrapping library to call through to the original implementation.
So, all you need to do is to start the process which uses the Hekkus Sound System in an environment that has LD_PRELOAD set appropriately, and you can do anything you like to the file that it reads.
Note, however, that there is absolutely no way that you can keep the data inaccessible from the user: the very fact that he has to be able to hear it means he has to have access. Even if all software in the chain would use encryption, and your user is not willing to hack hardware, it would not be exactly difficult to connect the audio output jack with an audio input jack, would it? And you can't forbid you user to use earphones, can you? And, of course, the kernel can see all audio output unencrypted and can send a copy somewhere else...
The solution to your problem would be a ramdisk.
http://en.wikipedia.org/wiki/RAM_drive
Using a piece of memory in ram as if it was a disk.
There is software available for this too. Caching databases in ram is becoming popular.
And it keeps the file from being on the disk that would make it easy accessible to the user.
For my purpose I was looking to optimize ways of recursively enumerating subfolders from a given folder on the NTFS file system on Windows, and I came across this little "gem" from the Microsoft's page for the FindFirstFile API:
Note In rare cases or on a heavily loaded system, file attribute
information on NTFS file systems may not be current at the time this
function is called. To be assured of getting the current NTFS file
system file attributes, call the GetFileInformationByHandle function.
So, let me try to understand it.
I do rely on the dwFileAttributes parameter returned in the WIN32_FIND_DATA struct to tell a file from a folder. So what this note suggests is that in some cases I might get some bogus result, right? If so, why not fix it in one of their updates instead of posting it here?
And also their suggested workaround of using GetFileInformationByHandle API. How exactly am I supposed to call it? It takes a file handle. So do they really want us to open each file that the FindNextFile returns and call GetFileInformationByHandle on it? Can you imagine "how far" my optimization would go with such approach?
Anyway, it'd be nice if someone could shed some light on this...
Distinguishing a file from a folder will be OK, because that information is likely to be constant. Files aren't being turned into folders or folders into files.
The documentation says "may not be current" because other processes may be changing attributes, and without a locking mechanism to synchronize the attributes are being written lazily. If your application requires absolutely current info, you retrieve it ...ByHandle which insures that the information is current.
This is the way every status-reporting function works. At best, it reports the status at some undefined point in-between when you called the function and when the function returned. But it doesn't "freeze the world" to ensure that the data is still valid later.
Rather than noting this on every single function, documentation typically only notes it on functions that tend to lead to severe problems, particularly security problems, when this is not taken into account.
If you open a file and get a handle to it, you are assured that all your operations using that handle will be to the same underlying file. But when you perform operations by name, there is no such assurance. Files can be created, deleted, and renamed. So the same name may not later refer to the same file.
dwFileAttributes is not something that is going to be unreliable when it comes to telling the difference between files and folders. I think that note is referring to information that might be cached for update by the file system (modified/accessed timestamps, etc) but whether an item is a file or a folder is not something that is going to change.
I want to create a file that only resides in memory... In looking through some documentation I saw a recommendation to use a shell extension as a virtual file. Im not sure that is a workable solution but I would like to know
Is it a good approach (or should I be using a ramdisk instead)
Where is a good place to start to read up on it
Note: This is on the Windows platform
As I understand, you want your program to create a "file", which resides only in memory and that you can pass on to another external program (say, Microsoft Word).
AFAIK this is not possible, short of a ramdrive. I'd suggest using a temporary folder. You will however have to come up with a strategy for deleting the file when it's not needed anymore.
Added: On second though, you might want to check out Reparse points. I'm not familiar with them myself, and they will only work for NTFS formatted disks, but perhaps they can provide you with what you want. It will be a lot of coding though.
You don't say on which plateform you are but I'm guessing Windows. Is mmap() available? If not, I think BerkeleyDB has been ported to Windows so you should be able to use that. Win32 API may have something akin to mmap() but I don't know it.
If you want a file that resides only in memory, use a named pipe or something, though I question your scenario - can you go up a level and describe what you want to do?