Run a .exe file when a file is opened in a folder - c

I am mounting a folder as a virtual drive and i want to run a .exe file everytime user opens any file present in that folder. To be precise the folder would contain dummy files present on some other machine. By dummy files i mean the file would be listed but it would be a empty file. Whenever user opens a file i want the .exe program to download that file from another machine and display it to user.

That functionality (remote access on demand) can be implemented using reparse points and file system filters.

You could
use hooks to rewrite the jump address of OpenFile and in the
detour function check for the handle type, retrieve it's info by
using GetFileInformationByHandleEx, parse the data, download
what you need, open the downloaded file and then return
STATUS_SUCCESS or any appropriate error status in case one occurs.
Note
this is a bit more complicated as you also need a auto-inject
mechanism to inject function/library into each process according to
it's architecture.
this is not a safe procedure as most AV's will most likely consider your code malware.

Related

Moving file to another directory in ABAP

I have got a service running in a specific directory in 5-second-intervals which is picking up an XML file created in that directory sending it for some necessary authorization checks to another client and then requesting a response file.
My issue is that my Z_PROGRAM creating the XML file might take longer than 5 seconds as a result of the file's size. Therefore creating the file in that specific directory is not preferable. I thought about creating a new folder in that directory called "temporary" and creating the file inside that folder, then once I'm done with it, moving it back outside for the service to pick it up.
Is there any way to move files from one directory to another via ABAP code only?
Copying the file manually is not an option since the problem that I have during file creation still persists. I need 2 alternatives, one used for local directories and one for application server directories. Any ideas?
Generally, we create another empty file for completed files after the file creation process ends. Third parties must be firstly checked empty file is there. Example:
data file.csv
data file.ok
If you already completed your integration and it is not easy to make any change with third parties, I prefer using OS level file moving commands. Sample document here. You can use mv for Linux server and move for Windows. If your file is big, you will get same problem with OPEN DATASET concept. We have ARCHIVFILE_SERVER_TO_SERVER FM for moving files but it is also using OPEN DATASET.
there is no explicit move command in ABAP code that move or copy files between directories in application server.
there is two tips can be helpfull in your case. if you are writing big file you may seperate the logic behind collecting data and writing file. I would say don't execute transfer data inside your loop. instead collect you data into an internal table once you're done, loop over this internal table and write direclty strings without any delay you should be able to write a big files upp to several hundred of MB under 1 sec.
next tips is to not modify your program, or if you are using function modules to construct xml is, write to a temp directory after finishing, then have another program open you file on source directory by read dataset and directly write data to the new directory again just strings without interruptions.
you should be ok if you just write strings.
You can simply use System Call Commands to perform actions in Application Directory.
CALL 'SYSTEM'
ID 'COMMAND'
FIELD 'mv /usr/sap/temporary/File.xml
/usr/sap/final/file.xml'

How to find out if a pdf file is "blocked" by a pdf-reader

In our application you can import - for instance - a pdf file into the application area. In the popup window where you define the path of the pdf file, you can specify if the original file should be deleted after a successful import or not.
Sometimes a user imports a pdf file, which he has also "open" in an pdf reader (in our case pdf xchange viewer and foxit reader). In this case our application cannot delete the pdf file because it is somehow blocked.
How can I find out - for instance a winapi call? (without trying to delete it or rename it) that the pdf is blocked by a pdf reader?
Thanks alot in advance
Though it is not good to interfere with other programs (just tell your user the file is being used), releasing file locks are a bit difficult.
First, you need to use ZwQuerySystemInformation to obtain a system-wide file handle table (and your program needs SeDebug privilege) and find the file being used.
Use DUPLICATE_CLOSE_SOURCE flag for DuplicateHandle to duplicate and close the file handle.
Or, go into the kernel and use ZwClose or ObDereference functions to close a file.
Still, closing a file outside may crash remote programs and it is against Windows' design principles.

How to open multiple files in explorer at the same time?

It is a little tricky to describe my question, but I'll try my best.
First, I am developing a Multi-Document-Interface app using C and WinAPI. My program is able to parse command line arguments to open multiple files. I put this string:
"X:\MyAppName.exe" "%1"
under the open with command list of the txt files so that now I can right click any .txt files in Windows Explorer and open it with my app. However, when I select multiple files, the explorer runs command "X:\MyAppName.exe" "%1" multiple times so that multiple instances of my app are started.
But wait! That's not the most tricky part. Instead, it is that my app treats opening a single file and opening multiple files at a time as two different things with seperate visual styles. I know the idea of keeping one instance running at a time (though I don't know the C code to implement it). But I don't know how to tell the difference between open several files one by one and opening multiple files at the same time.
I hope I make it clear.
Using the Registry like you currently are, you will not be able to directly differentiate between multiple files from single files. Each requested file will start a new copy of your app, as you have already noticed. If you implement single-instancing (which is not that hard to do), what you could do is detect when the first file is requested and start a short timer, then have each subsequent file reset that timer. When it finally elapses, check how many files you collected and act on them as needed.
A better, and preferred, solution is to instead create an out-of-process COM object in your app that implements the IDropTarget interface. Windows will then be able to funnel file information through a single entry point into your app. Your app will not have to care where the information is coming from. You will be able to support not only multiple files at a time, but even different formats of file information (Windows could pass you just the file names, or it could pass you the actual file data itself).
Windows will construct a single IDataObject object to hold whatever file information is needed, and will then pass it to your IDropTarget object. If your app is already running, COM will be able to access your existing IDropTarget object. If your app is not already running, COM will automatically start your app before then accessing its IDropTarget object. Either way, once it is running, your IDropTarget can look at whatever data is passed to it and decide whether to accept it or reject it.
If you register your COM object's CLSID as a DropTarget for the desired file extensions, users will be able to double-click on such files, or select such files and press Enter, and they will be passed to your IDropTarget object.
If you register an AppPath for your app and then register the CLSID as a DropTarget for it, users will be able to drag files, regardless of extension, onto your app's exe file itself, and they will be passed to your IDropTarget object.
If you use the same COM object with the RegisterDragDrop() function, users will be able to drag files, regardless of extension, onto your app's UI directly, and they will be passed to your IDropTarget object.

read from a file while installation in nsis but do no copy it on the destination pc

I want to display the version on the installation dialog pages of nsis, by reading the version from a text file, but i have to copy this on the destination pc where the executable is run, but i want that the text file is not copied on the user's pc but is only read from,
that is,
i want to include this file into the exe, and read text from it to display on the nsis dialog pages, but not copy it anywhere on the pc wherever the exe is run?
is this possible? or is there any other way of doing this?
In general, you can use $PLUGINSDIR constant. It is de-facto temporary directory on target system and you can put there something and use. Following code will copy the file into the temporary directory on the target machine, but whole directory will be deleted after the installation completion. (InitPluginsDir is needed somewhere before)
InitPluginsDir
File /oname=$PLUGINSDIR\blah.txt "..\myfile.txt"
But in your case, it could be better to solve it in some other way. You can define some constant containing version number and use it in the code, can't you? The !define command could be in generated file so you can automate it...

How to implement a file type based filesystem?

I want to essentially make it so that you never need to unzip/unrar any files. Currently, I have a Dokan filesystem which can do it given a specific zip file but I wanted to know how I can make it apply to all files. Meaning, I want to be able to compile a program that has "fopen("test.zip/1.jpg", "rb");". I think that a Shell Extension would work for dynamically loading the file into the filesystem IF I were browsing in the shell explorer but that doesnt help me with the fopen example. Any ideas?
What you want to do can be used with help of file system filter driver, which would track directory enumeration requests and report directories in place of ZIP files. Then this driver would create virtual files and take the data from ZIP archives. Quite a lot of kernel-mode work, I should say. And file system filter driver is not a file system driver, so dokan won't help you at all.

Resources