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.
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 am developed a program in dev c++ compiler name of file is CorrectPrgm.cpp and want to run CorrectPrgm.exe created by CorrectPrgm.cpp file. from Le.cpp which was developed in turbo c++ 3.0 compiler and my need is at the time of running Le.cpp i want to invoke/run CorrectPrgm.exe. The CorrectPrgm file accepts file name from user and produces output as list of tokens.
i have tried like this:
system("C:\\CorrectPrgm.EXE");
not working..
any other way to call...
Any help would be appreciated..
If you are on Windows Vista and above, probably you can't run it, as I believe this would be a 16-bit DOS applications. If it's 32-bit DOS app (proteced mode through DPMI, but unlikely) then it might run too, but that was too long ago to remmember how.
On Windows 7, you can install Windows XP mode (actually Virtual PC builtin kind of), and run it from there. XP still supports 16-bit apps.
I believe you can use one of the exec or spawn functions.
you can create a separate process for the program you want to invoke. But you will face a lot of problems. Firstly. correctPrgm.exe and le.exe will execute in two separate process. So you have to consider interprocess communication.
The best thing I'd suggest is break the CorrectPrgm.exe source file in functions and call the functions you need. Even you can use library and header file(s) to get the functionality of those functions.
You can also create threads. But then you have to design the threads (in one thread the CorrectPrgm will run) very carefully.
What I'm trying to do is to sign my compiled executable's first 32 bytes with a version signature, say "1.2.0" and I need to modify this signature in runtime, keeping in mind that:
this will be done by the executable itself
the executable resides on the client side, meaning no recompilation is possible
using an external file to track the version instead of encoding it in the binary itself is also not an option
the solution has to be platform-independent; I'm aware that Windows/VC allows you to version an executable using a .rc resource, but I'm unaware of an equivalent for Mac (maybe Info.plist?) and Linux
The solution in my head was to write the version signature in the first or last 32 bytes of the binary (which I didn't figure out how to do yet) and then I'll modify those bytes when I need to. Sadly it's not that simple as I'm trying to modify the same binary that I'm executing.
If you know of how I can do this, or of a cleaner/mainstream solution for this problem, I'd be very grateful. FWIW, the application is a patcher/launcher for a game; I chose to encode the version in the patcher itself instead of the game executable as I'd like it to be self-contained and target-independent.
Update: from your helpful answers and comments, I see that messing with the header/footer of the binary is not the way to go. But regarding the write permission for the running users, the game has to be patched one way or another and the game files need to be modified, there's no way to circumvent that: to update the game, you'll need admin privileges.
I would opt for using an external file to hold the signature, and modify that with every update, but I can't see how I can guard against the user spoofing with that file: if they mess up the version numbers, how can I detect which version I'm running?
Update2: Thanks for all your answers and comments, in truth there are 2 ways to do this: either use an external resource to track the version or embed it in the main application's binary itself. I could choose only 1 answer on SO so I did the one I'm going with, although it's not the only one. :-)
Modern Windows versions will not allow you to update an installed program file unless you're running with administrator privileges. I believe all versions of Windows block modifications to a running file altogether; this is why you're forced to reboot after an update. I think you're asking for the impossible.
This is going to be a bit of a challenge, for a number of reasons. First, writing to the first N bytes of the binary is likely to step on the binary file's header information, which is used by the program loader to determine where the code & data segments, etc. are located within the file. This will be different on different platforms (see the ELF format and executable format comparison)--there are a lot of different binary format standards.
Assuming you can overcome that one, you're likely to run afoul of security/antivirus systems if you start modifying a program's code at runtime. I don't believe most current operating systems will allow you to overwrite a currently-running executable. At the very least, they might allow you to do so with elevated permissions--not likely to be present while gaming.
If your application is meant to patch a game, why not embed the version in there while you're at it? You can use a string like #Juliano shows and modify that from the patcher while the game is not running - which should be the case if you're currently patching anyways. :P
Edit: If you're working with Visual Studio, it's really easy to embed such a string in the executable with a #pragma comment, according to this MSDN page:
#pragma comment(user, "Version: 1.4.1")
Since the second argument is a simple string literal, it can be concatenated, and I'd have the version in a simple #define:
// somehwere
#define MY_EXE_VERSION "1.4.1"
// somewhere else
#pragma comment(user, "Version: " MY_EXE_VERSION)
I'll give just some ideas on how to do this.
I think it's not possible to change some arbitrary bytes in the executable without side effects. To overcome this, I would create some string in your source code, like:
char *Version = "Version: AA.BB.CC";
I don't know if this is a rule, but you can look for this string in your binary code (open it in a text editor and you will see). So, you search and change this bytes for your version number in the binary file. Probably, their position will vary each time you compile the application, so this it is possible only if that location is not a problem for you.
Because the file is being used (it's running), you have to launch an external program that would do this. After modifying the file, this external program could relaunch the original application.
The version will be stored in your binary code in some part. Is that useful? How will you retrieve the version number?
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.
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.