GNOME Bugzilla – Bug 169061
FileSystemWatcher backend is broken
Last modified: 2006-01-23 21:07:00 UTC
Distribution/Version: SuSE9.3 1. I have a test file named "beagle-test" with contents as "testing beagle". 2. Run best and give the search string as "testing". In the results we get the test file "beagle-test". 3. Now move the file to some other name say "newtest". 4. After sometime (when the file gets indexed by beagled) the file "newtest" appears in the best search results window in addition to the file "beagle-test" (which was the earlier search result and doesn't exist any more). So the total number of search results are 2 instead of the actual 1. 5. Also The search result doesn't go from the best window if the file is deleted. 6. The search results are refreshed only when you click on Find again in the best window. 7. The problem here seems to be in best as beagled is correctly deleting the indexes of the renamed/moved/deleted files (as is visible from the correct results being displayed after Find is clicked again) Additional Information: I am running beagle without the inotify kernel on SuSE9.3. The beagle version running is 0.0.6. The mono version is 1.1.4
We can't immediately update without inotify, at least not in general. On 9.3, we will only get notification of file system events in ~, ~/Desktop and ~/Documents. The deleted file disappears when you do the second search because beagle filters out files that do not exist at query-time. But without inotify, there is no way for us to know
Jon: But even ~Desktop/ and ~Documents/ directories are not being refreshed if the contents of the files contained in these directories is changed. I have the following scenario: I have a file in ~Desktop/ directory named "testone", and it contains a string "connoi". When I search for the string "connoi" in best it shows the files "testtwo" in the search results. Now I modify the file "testtwo" and delete the string "connoi" from it. Best should automatically refresh and remove the file "testtwo" from the search results because now the string "connoi" is not present in the file, but this doesn't happen until I again click on Find in the best window.
OK, I'll take a look at it. Thanks.
So I just tried this, and the FileSystemWatcherBackend doesn't seem to work at all anymore. ;) Events appear and are printed out, but nothing is done with them. In OnCreatedEvent, for example, which is called any time a file or directory is created, the code only checks whether it's a directory, so new files are indexed at all.
Created attachment 54339 [details] [review] reimplement FileSystemWatcher event handlers More to the point, OnCreatedEvent doesn't even check if it is a directory since the code is "#if false" ! You may remember a short IRC conversation we had about this. I tried to reimplement the FSW stuff but it doesn't work at all on my setup - setting an extended attribute causes a FSW event - presumably this is because FSW uses fam, but I have gamin installed using inotify so it is more intelligent than your standard file-polling fam. THis means that we index a file, update the xattr, recieve a changed event, reindex file, update the xattr, ..... Either way here's how far I got.
Should we just going to drop any semblance of support for this?
I think it would make sense to drop it --- mono's FSW doesn't work very well, and the semantics are different enough from inotify to make supporting it a pain.
I just removed the FSW backend. Closing this WONTFIX.