GNOME Bugzilla – Bug 730116
Windows: Adapt directory monitoring to the thread-safe GFileMonitorSource (and Add File Monitoring)
Last modified: 2015-03-30 06:38:11 UTC
Hi, As the default/fallback file monitor doesn't work well for Windows in GIO, it probably would be good to have one that is specifically meant for Windows (especially that there is one for directories that is largely working for Windows). As I looked into the code (and test running it with the monitor test), it does seem possible that the quite a bit of the code for Windows directory monitoring can be reused for file monitoring as well, as the Windows API ReadDirectoryChangesW() can be used for both directory/folder and file monitoring. I will try to come up with patches within the next few days (or so, time permitting) to add file monitoring support for Windows. With blessings, thank you!
Created attachment 276592 [details] [review] Add an utility source that can be shared for directory and file monitoring (for current directory/file monitoring code) Hi, On Windows, as both directory monitoring (and the upcomining file monitoring in this patch) would make use of the ReadDirectoryChangesW() API, and the process involved in directory and file monitoring largely overlap each other (where file monitoring would just take a few more steps), I think it might be good to use an utility source that can be shared for both. So, this is my patch for doing this, by copying Vlad's previous work for directory monitoring to this new utility source file, and adding the necessary steps for file monitoring that can be done when necessary.
Created attachment 276593 [details] [review] Add file monitoring for Windows (for current directory/file monitoring code) Hi, This patch adds file monitoring for Windows, as the default file monitoring mechanism provided by GIO itself does not work well there. The Windows directory monitoring code has been cleaned up a bit as well in this patch, as quite a bit of its code can be shared with file monitoring. I have tried these patches on Windows, and now the monitor test program does pass- if anyone can try these patches with MinGW based builds and let me know how these work with the MinGW builds, it would be great, as I used Visual Studio to implement and build these. With blessings, thank you!
Hi, pinging for reviews... with blessings and thank you!
Hi, I think, for tracking the work for using GFileMonitorSource in directory and file monitoring, let's use this bug to track the progress for this, as this will also cover the work that is required to make GIO on Windows support for file monitoring. With blessings, thank you!
Created attachment 294951 [details] [review] [WIP] Windows: Port to New GLocalFileMonitor API Hi, This is the probably-not-ready-for-commit diff showing the current progress of the work, which also adds file monitoring for Windows (which we didn't have). Please see the commit message for the known issues with this. With blessings, thank you!
Review of attachment 294951 [details] [review]: fyi: the changes done hint will be sent for you automatically 2 seconds after the last CHANGED event. you don't need to reimplement that logic for yourself.
Created attachment 299089 [details] [review] [WIP] Windows: Port to New GLocalFileMonitor API Hi, This shows the state of the current progress in porting the file monitoring items to the new (WIP) GIO file monitoring mechanism. Please see the diff for issues that are in this implementation. The good news is, gio.exe can monitor an individual file without crashing, and the gio/tests/monitor.c test program can run consecutively without crashing. One question: Is it correct that when we are monitoring a directory, when we change the attributes of a file in that directory, we emit a G_FILE_MONITOR_EVENT_CHANGED for the directory? With blessings, thank you!
Created attachment 299176 [details] [review] [WIP] Windows: Port to New GLocalFileMonitor API (round 3) Hi, Please see the patch comments for issues in the code, as a bit of progress is made. By the way, can I find out what the "boredom" algorithm is about? Is it about only really handling events that are marked as interesting? With blessings, thank you!
Created attachment 299194 [details] [review] po: Fix make dist (for the wip/desrt/gfilemonitor branch) Hi, Before I forget, this is the patch I had that would fix 'make dist', as we don't have gio/glocaldirectorymonitor.c anymore, and I am someone that insisted on using Visual Studio for developing Windows items :). Obviously the individiual .po files would need some purging as well, but probably leave those up to the translators. I may also need to look into the hard link stuff on Windows as well, but anyways. With blessings.
Hi Ryan, (Sorry if this is not the right place to post this) I have made some more work into the file monitoring items on Windows, which became more or less like a restructure of the code here, in your wip/desrt/gio-tool branch (commit 55847d9). Please see the commit comments for more details about what changed there. Please note, as I had a minor mess-up with the commit comments in there, the "but notifications are only sent by the system on changes when the monitored file/directory (or monitored hard link) is being changed, when the file is modified via the hard link or original file respectively in this case." should read "but notifications are only sent by the system on changes when the monitored file/directory (or monitored hard link) is being accessed, when the file (or the hard link) is being changed via the hard link or original file respectively in this case" Please also let me know: -Whether we want to monitor forced/abnormal ejects/unmounts, as ReadDirectoryChangesW() would make the system not allow the drive (USB thumbdrives, for example) with a monitored directory (and file) to be ejected normally, as the file will be in use, which IMHO is understandable. -Can I know whether we want to do the boredom/interesting algorithm that you had for the other backends? Can I know what that is about, especially if we want to do that for Windows? With blessings, thank you!