One of the QIODevice reimplemented open() methods in QFile has a QFileDevice::FileHandleFlag argument. Taking a look at the documentation for it there are two options with contradicting descriptions.
From the QFileDevice documentation:
QFileDevice::AutoCloseHandle – The file handle passed into open() should be closed by close(), the default behavior is that close just flushes the file and the application is responsible for closing the file handle. When opening a file by name, this flag is ignored as Qt always owns the file handle and must close it.
QFileDevice::DontCloseHandle – If not explicitly closed, the underlying file handle is left open when the QFile object is destroyed.
So does Qt auto close files or not and does setting this option actually change anything?
After looking up the Qt source I found the line in QFSFileEngine.cpp:378* that ultimately uses the flag.
QFile::open() can be passed an existing (stdio.h) FILE handler which was not created by Qt and shouldn't be automatically closed by Qt. In contrast files opened by Qt are automatically closed by Qt.
The QFileDevice::FileHandleFlag flag is for the former case and allows the programmer to specify if QFile should auto-close a file ignoring the fact that it was not opened by Qt.
* Search for closeFileHandle if the line number doesn't match.
Related
I had sort of an odd idea and was wondering whether it would be possible. Here's a rough outline of my plan.
Scenario: An application loads and interprets values from a config file at startup. I want to fuzz the application via the config file, without rewriting the config file.
Note: The config file is closed later on in the program, and the function that opens the config file is used to open various other files, so I do not want to hook this function. While SetKMode() and SetProcPermissions() are used here, answers that apply to Windows in general are just as helpful as Windows CE answers.
Plan:
Attain debug privileges over this process via SetKMode() and SetProcPermissions and attach a debugger via DebugActiveProcess()
Break after the function that loads the file returns
Create a temporary modified version of the file and open it in the parent process
Use VirtualAlloc() to allocate space for the FILE structure in the debugee
Transfer the entire FILE structure for the temporary file to the debugee using WriteProcessMemory()
Swap the pointer for the config file loaded by the debuggee to the pointer for the temporary file
Allow the debugee to run the file
Before the debugee closes the file, copy the old pointer for the original config file back to the new pointer so that it closes the correct file
Would the debugger be able to read the file? Would the parent be able to close the file after it's finished?
Edit:
Transferring the old pointer back to the debugee every time it tries to close the file no longer seems like a good solution after some RE, so on top of my current question I have an additional question: Would the debugee be able to close the file the debugger opened? Would that be a problem? And would the fact that the original file isn't closed properly be a problem?
Edit:
Sorry I'm a dummy who forgot that if I'm going through the trouble of injecting all this I can just inject a new filename and swap the pointer long before the call to fopen.
Assuming the entire file is loaded into memory and then parsed, I would hook whatever function loads the file data into memory, use a conditional to check the filename so you're only executing your code after the correct file is loaded into memory by checking the filename. Then I would perform my fuzzing by modifying the file data in memory and then return execution to the target process before the file dats is then parsed. In this manner you aren't touching any file permissions, only memory.
To automate it create a "loader' which executes the target process, injects, executes your hook and then checks for crash or other unwanted behavior.
If I call fileRead with a path argument (rather than with a file object I explicitly opened with fileOpen), does ColdFusion close the file it opens? Is this documented anywhere? I don't see anything about this type of behavioral guarantee on either Adobe's or CFDocs' pages.
Yes, the file commands are self contained procedures that open, act on a file and then close. This is the standard expectation for any standalone command.
I've some code to monitor a folder containing .xml files.
I used a QFileSystemWatcher and connected the signal directoryChanged(const QString &path) to a slot where I implemented a small routine.
When I delete a file which is located in this monitored folder, the signal is emitted twice, and I cannot figure out why.
I've read other posts on stackoverflow, but all those I found mentioned the same issue when editing a file and not deleting it. Since I'm deleting files and not editing them, the file is not first removed and then written again by the editor.
Anyone knows why this happens and how to fix it ? I can add some code if needed.
Thanks !
EDIT : After reading this question, I added Qt::UniqueConnection to my connect to make sure it was only done once (even though I'm sure the connection is made only once with an auto connection since it's called in the constructor of the mainwindow), but the result is the same.
I'm writing a program which operates on a file (only reads the file), while another program is writing that file (I've no control over it to use events and I don't know the content of the file). I want a way to know when that program finished writing, to stop my program operating on the file. I used these two method but I don't know which one is reliable and more performance:
1- renaming file to another name, if success, rename it to original name.
2-flush file , if file size has not been changed for a while (e.g 5 sec) then stop operation.
which one is better? is there any better way (more reliable and more performance)?
I'm using windows 7 and qt5.2(or visual studio) for c++.
Qt provides a class called QFileSystemWatcher which allows you to monitor files and directories.
I have data in memory that represents an image. I want to open the image in the default program to open images. Therefore, I create a temporary file, write the data to it, and then open the file with the default application. Currently, I am using Qt to do the last step via QDesktopServices::openUrl ( const QUrl & url ). The problem is that I now have this random file lying around on disk. Is there a way that I can queue a delete on the file so that after the app closes it gets deleted?
As far as OS is concerned, I'd prefer a os independent solution, but I am guessing that none probably exists. Therefore, if you could link to/post how to do it in linux/osx/windows, that would be really helpful.
On a POSIX system (any Unix or Linux machine), there's a nice trick you can take advantage of: you can remove the directory entry for the file with unlink after opening the file. As long as you keep an open filehandle on the file, it will not be removed, but once you've closed it, the filesystem will automatically reclaim the storage.