I was trying to make a program for a college project, but I got stuck at this:
How will you monitor a program as to what files it writes to or reads from?
I wish to have their path names.
To make the problem more clear, here is an example:
Consider the program we wish to monitor is a.exe, and a.exe first opens a file named "a1" residing in the same folder as a.exe, and then opens another file named "a2".
The program has to give the relative or absolute path of "a1" and "a2" files, irrespective of them being opened for read/write..
How do I implement this in C++?
EDIT : Is it possible to divert the calls for a1 and a2 files to another path??
EDIT2 : ok, let me put it this way: i have moved the firefox.exe from C:\program files to D:\, now when i run firefox.exe it wont work coz it works on many files that are there in C:\program files, firefox.exe would be using relative paths for accessing the files. What i intend to do is to capture the calls for the files firefox.exe works on and then direct the call to the program files folder. Plz let me know if i have made myself clear..
On linux you can you use 'strace' wich output the different system calls performed by your application. If you need to implement a program which perfoms the same kind of output as strace, a quick implementation could consists in a simple shell program which greps the output of strace. Otherwise looking into the strace code is a good start.
On Windows 'Process monitor' from Sysinternals suite may help you out.
If you want to modify the arguments to open(2), creat(2), truncate(2), and so forth, then you could use the Linux ptrace(2) facility to intercept the systemcalls and replace the filename strings before executing the call.
ptrace(2) is dark magic, so unless it's an advanced course, it might not be what your professor intended. (If the next lecture is on writing a debugger like gdb(1), then this is exactly what your professor intended.)
Another mechanism you can use, and probably much more portably, is library or function interpositioning -- you can write little wrappers around specific functions in a library, and by loading the library with the LD_PRELOAD environment variable (see the ld.so(8) manpage for details on the environment variables that influence library loading), your functions will be called instead of the standard functions.
Library interposition is grey magic; it's better documented than ptrace(2), but still pretty easy to screw up.
Related
I need to check if a file is currently opened by another process, e.g. a text editor (but needs to apply to everything else too).
I tried using std::ofstream::is_open() etc., but this did not work. I could open the file in my text editor while my program was checking if it was open. The program saw it as a closed file and went on. Only if I opened it as another ofstream would this work.
I'm using the filesystem library to copy files and they may only be copied (and later removed) if the file is not currently written to by another process on the client server.
Really curious about this one. Been wondering this for quite some time but never found a good way for it myself.
I'm currently making a program that needs to be able to run on both linux and windows. every 5 seconds it copies all files from directory a,b,c,d to x. This can be set by the client in rules. after it copied everything. all the files may be removed. After a day (or whatever the client tells the program) all those files from x need to be zipped and archived on location y. Hence the problem, files may only be deleted (and copied) if the other programs that place all the files in directories a,b,c,d are not touching that specific file right now. Hope that makes the question clearer.
And before anybody starts. Yes I know about the data race condition. I do not care about this for now. The program does absolutely nothing with the contents of a file. And after a file is closed by the other process, it will be closed forever.
I need to check if a file is currently opened by another process
This is heavily operating system specific (and might be useless)
So read first a good textbook on operating systems.
On Linux specifically you might use inotify(7) facilities, or /proc/ pseudo-file system (see proc(5)), or perhaps lsof(8). They work only for local file systems (not remote ones, like NFS). See also Advanced Linux Programming and syscalls(2).
And you could have surprises (e.g. a process being scheduled so quickly that removes a file that you won't have time to do anything)
For Windows take more time to read its documentation.
I'm currently making a program that needs to be able to run on both linux and windows. every 5 seconds it copies all files from directory a,b,c,d to x.
You might look, at least for inspiration, inside the source code of rsync.
I don't understand what your actual problem is, but rsync might be part of the solution and is rumored to run on both Windows and Linux
I have been researching a topic unsuccessfully for a couple of days. I'm a C ++ rookie, and as a practice i decided to make a basic (very very basic) copy of a version control system.
I have separated the project into steps. The first step (splited in activities) is:
The user searches, in the windows console, for the directory where the files he wants to track are located. Let's say he reached the desired path: C:\MyProjectFolder\ProjectToTrack>
Once inside ProjectToTrack folder the user applies this command: C:\MyProjectFolder\ProjectToTrack> emi track. "emi" is the name of the .EXE that i created in C ++ and the track parameter tells to the executable to create a hidden folder inside the ProjectToTrack folder.
Note: Obviously emi.exe is not in the path C:\MyProjectFolder\ProjectToTrack, let's say that emi.exe is in C:\ProgramFiles\emi\emi.exe
That's it, once this is done I will pass the second step, but I will take care of that problem later.
For now, after practicing and reviewing documentation i have achieved:
The .exe that creates a hidden folder in the path that was sent to it as a parameter, having said that ...
I also know how to send parameters to an .exe through windows console.
But, what I still can't get is:
Calling to emi.exe (C:\ProgramFiles\emi\emi.exe) through the console from any directory (necessary to track any file in any folder).
When C:\MyProjectFolder\ProjectToTrack> emi track is applied, I know how to send the parameter track to emi.exe, however, it is evident that I must also capture the current path (path i accessed from the console), so that emi.exe knows where to create the hidden trace folder; well, i still don't figure out how to capture and send this path to the main function of the .exe.
I have not found something related to what i need, english is not my default language so maybe i'm not using the correct terms, I hope that what i have said here is understandable.
PS.1. I'm currently trying to build this project using "windows.h", i would appreciate it if your comments were related to this library. Once i have understood this, I will start practicing with portability.
PS.2. I don't want a detailed solution, I just want an opinion or recommendation and maybe some links where to find what I need, I can do the rest.
Thank you!
Calling to emi.exe (C:\ProgramFiles\emi\emi.exe) through the console from any directory (necessary to track any file in any folder).
For this you need to add the folder of your executable (i.e. C:\ProgramFiles\emi) to the system global variable called PATH (both Windows and Linux work this way, and must be MAC OS as well but I never used it).
When C:\MyProjectFolder\ProjectToTrack> emi track is applied, I know how to send the parameter track to emi.exe, however, it is evident that I must also capture the current path (path i accessed from the console), so that emi.exe knows where to create the hidden trace folder; well, i still don't figure out how to capture and send this path to the main function of the .exe.
For this take a look at this STD function here: https://en.cppreference.com/w/cpp/filesystem/current_path (personally I've never used it but must be what's you're looking for).
Good luck with your endeavor!
If the user does not pass in a target path explicitly as a parameter, the EXE can use the Win32 GetCurrentDirectory() function, or in C++17 and later the standard std::filesystem::current_path() function, to retrieve its current "working directory".
If the user navigates a console window to C:\MyProjectFolder\ProjectToTrack and then executes C:\ProgramFiles\emi\emi.exe, the current working directory will initially be C:\MyProjectFolder\ProjectToTrack.
Is it possible to modify an executable file on runtime (I'm asking about Windows XP/Vista/7/Server)? I've just evaluated SmartUtils Portable Storage application. It can create so called "managed executable storage files" that modify them-self at runtime... Such storage file is like standard self-extracting archive (the data is apended to an executable module) but the main difference it that you are able to view and modify its content without the main program. How is it possible? I need similar functionality in my project (C++): I want to be able to create executable that can modify data attached to it.
If all you're really asking is how SmartUtils Portable Storage does it's magic, then I would suggest that it is a self-executing zip archive. The EXE of the archive (just as WinZip or 7-Zip create) auto-extracts and executes your application exe from a temp folder, and gives you an API that boils down to ways to extract, manipulate, and then modify that original self-executing archive.
So Windows is never trying to modify a running .exe. Rather, your .exe (temp file extracted & run) is what is executing (and the libraries bound to it), which manipulates the source .exe (really a self-executing archive - possibly .zip).
The next time the user "runs" the modified "exe", again your .exe is extracted & run, and it can again manipulate the self-extracting .exe.
I hope that makes sense to you.
And this is just a best guess!
Yes - a common technique is to append data files at the end of an executable.
Typical scheme is to write a 0x00000000 integer to the end of the executable and then append each file followed by it's size in bytes.
Then when the executable needs to read the data it checks the last 4bytes in it's own file, uses that as the file length and copies that number of bytes form it's own file, it then checks the next 4 bytes as another length and copies that as a file , until it gets a length of 0000. If you also need to code the file names - that adds a little complexity but it's basically the same idea.
You can append a TOC pointer to an EXE (and probably a magic ID cookie) so you can verify that it is a TOC pointer, and then use that to back up to the start of each appended record.
As long as you don't mess up the file's header & main contents, it should still be loadable by the OS.
However, you sacrifice any signing your EXE had - and you probably have various permissions issues to contend with...
I have written tools for my development environment that opens a Windows EXE, extrapolates the resources in it, modifies various ones, and repackages the whole thing. We use this to mark a beta as release (so it modifies the version records).
You can do anything you want to an EXE file if you know the structure of it and rebuild it correctly.
Since this is tagged as Windows, you might also consider "Alternate Data Streams". That allows you to treat a single file almost as a directory. You can add a stream called Program.EXE:ExtraData to your program and write to that with the normal file functions.
Then again, your executable most likely will be in Program Files\, which isn't writeable for normal (non-elevated) users.
I'm trying to move (delete) a file to a Trash Can (in Linux) using C++ (also using QT4 for GUI). Unfortunately it seems to be quite difficult to do so and as far as I can tell there isn't a unified API for it.
I would like for my application to run not only on KDE but on GNOME, Xfce and other Linux desktop environments. That's why I'm searching for a more universal approach.
The best I could find so far is:
send2trash - but that's using Python/QT4 and not C++/QT4
trash-cli - this has the drawback of being a stand alone command line program and not a library
I would be happy with any approach that requires as little desktop environment specific code as possible. Or in other words that's as much independent from KDE/GNOME/Xfce components as possible.
Any help in finding a solution (if there even is one) would be greatly appreciated.
Why not find a terminal command to move the files and then call system() to run it for you inside your C++ program?
This might (I haven't tested it) be a possible one-liner in Linux to move files to the trash via the terminal. You would just pass the command as a quoted string to system() and call it in your C++ implementation.
The answer is in
http://www.freedesktop.org/wiki/Specifications/trash-spec
For every user a “home trash” directory MUST be available. Its name and location are $XDG_DATA_HOME/Trash
you only need to write C++ code move your file into such directory.
You can move files using boost file system and you can retrieve the XDG_DATA_HOME value using cstlib getenv.
As far as I know there's no standard trash can in Linux in the first place.
I know that in a DOS/Windows application, you can issue system commands from code using lines like:
system("pause");
or
system("myProgram.exe");
...from stdlib.h. Is there a similar Linux command, and if so which header file would I find it in?
Also, is this considered bad programming practice? I am considering trying to get a list of loaded kernal modules using the lsmod command. Is that a good idea or bad idea? I found some websites that seemed to view system calls (at least system("pause");) in a negative light.
system is a bad idea for several reasons:
Your program is suspended until the command finishes.
It runs the command through a shell, which means you have to worry about making sure the string you pass is safe for the shell to evaluate.
If you try to run a backgrounded command with &, it ends up being a grandchild process and gets orphaned and taken in by the init process (pid 1), and you have no way of checking its status after that.
There's no way to read the command's output back into your program.
For the first and final issues, popen is one solution, but it doesn't address the other issues. You should really use fork and exec (or posix_spawn) yourself for running any external command/program.
Not surprisingly, the command is still
system("whatever");
and the header is still stdlib.h. That header file's name means "standard library", which means it's on every standard platform that supports C.
And yes, calling system() is often a bad idea. There are usually more programmatic ways of doing things.
If you want to see how lsmod works, you can always look-up its source code and see what the major system calls are that it makes. Then use those calls yourself.
A quick Google search turns up this link, which indicates that lsmod is reading the contents of /proc/modules.
Well, lsmod does it by parsing the /proc/modules file. That would be my preferred method.
I think what you are looking for are fork and exec.