QFileSystemWatcher locks directory on Windows 7
I am watching a directory recursively using QFileSystemWatcher. And I am not able to rename/delete the parent directory either programmatically or manually if its sub directories are being watched.
When trying to rename manually through system i get a message box saying "The action cannot be completed because the folder/ file in it is opened in another program" and on renaming programmatically it fails.
I got these similar bugs, but no resolution:
I am not watching . and .. as said in the above link, but still the directory is locked.
In case of programmatically renaming.. I tried a workaround:
- Remove all the subdirectory paths from watcher before renaming the parent.
- Rename parent.
- Add subdirectory paths again.
But here too my program fails on first step. QFileSystemWatcher::removePath() returns false when trying to remove the subdirectory paths, and QFileSystemWatcher::directories() show that directory in the paths being watched. Same as posted here https://bugreports.qt-project.org/browse/QTBUG-10846
Since step 1 fails here, step 2 also fails and i cannot rename the parent dir.
I am using Qt5.2.1 and Windows 7.
Kindly help me with a resolution.
I tried a small piece of code in Qt 5.3.1, the issue persists.
You might want to fill in a bug report and hope they'll come back to you soon (hopefully, with good news).
Hi @T3STY. Thanks for the reply and update that the new version of Qt have this bug too.
However can you tell me why my workaround is not working. Why I am not able to remove paths from QFileSystemWatcher? Is this too a bug in Qt?
As you can see from the documentation, the QFileSystemWatcher class is pretty restricted to itself when it comes to usage, it only requires few data types when using it. All this is to say that there is little you can do externally to handle the QFSW class internals, even less if using just the methods it provides. The behavior of the bug is definitely something that locks the class internals.
I can't really tell what's wrong there, they're using a tricky lock-unlock mechanism together with threads to manage all the watching process (I have had a look at Qt's sources), so the culprit could be anything from a thread getting stuck (so, not allowing you to actually remove a file from the watching list) to invalid file handles, to threads terminating before a file/path is actually removed.
You might want to play with the watcher by using lists of paths instead of calling multple times the addPath method (for a single path) - or viceversa; the same for removing them. Also, between an add and a remove try to get the list of paths and files from the watcher and see what it reports; for example, if it says that a path/file has been removed (it does not exist in the list) yet you can't make file/folder changes in that path from the system (which means the watcher is still watching and locking them) then the developers might have a clue on where to start looking for the issue.
I'm sorry for not being helpful here...
You could also try something else. There is an application called Unlocker which can unlock files or folders from whichever application is locking them, so that they can be moved/deleted. Try to use Unlocker on a locked directory, and see the what the watcher reaction is. As from the the docs, when a path/file is deleted, the watcher stops watching that path/file; If you force remove something externally with Unlocked you should still be able to trigger the remove mechanism of the watcher. Again, this is not going to help you but might help the developers understand where the problem is.
After days of trying, I am finally able to find the solution of my problem by using Win32 API for watching directories on Windows platform. I wrote a blog post on How to use Win32 Api to monitor directory changes. I would like to share the link so it may help others who land up here to find the solution of the same problem.
"Win32 API to monitor Directory Changes":http://developersarea.wordpress.com/2014/09/26/win32-file-watcher-api-to-monitor-directory-changes/
if your problem solved please tagged this thread as SOLVED :) tnx;