GNOME Bugzilla – Bug 172750
gnome-vfs appears to corrupt it's own FAM state
Last modified: 2005-06-24 18:45:45 UTC
While attempting to discover why my Desktop is no longer updating in response file changes, I discovered the following oddity. I'm messing with gnome-vfs-2.8.2 (as shipped in FC3), but I think this still applies to HEAD, because (afaict) none of the changes to file-method.c are relevant. Anyway, the scenario so far is this: I'm using $HOME as my Desktop, and I'd been creating/deleting/renaming files at the shell prompt, waiting for something to go wrong. When I renamed a file called TODO.txt to ToDo.txt, it vanished from the desktop and failed to reappear. Renaming it back failed to make it reappear, and other filesystem changes are also failing to do anything. Looking at nautilus in the debugger, I see that gamin is delivering events, but GnomeVFS is attributing them to the wrong directory. i.e. mv ToDo.txt TODO.txt in /home/nicholas results in 1) a FAMChanged event for /home/nicholas 2) a FAMDeleted event for ToDo.txt, except that the full path for ToDo.txt is computed to be /home/nicholas/.gnome/mime-info/ToDo.txt (based on the contents of the ev.userdata pointer) 3) a FAMCreated event for TODO.txt, except that the full path for TODO.txt is computed to be /home/nicholas/.gnome/mime-info/TODO.txt (again based on the contents of the ev.userdata pointer) So, it looks like gnome-vfs attached the wrong userdata and is breaking accordingly. (Or else gamin is returning the wrong userdata value, which seems less likely to me -- cc'ing Daniel Veillard just in case).
I added a new program to the gnome-vfs programs called gnomevfs-monitor so we can better track down that issue. And there indeed seems to be something fishy going on. Although I am not sure sure it's gnome-vfs' fault. I sometimes see the changes in gnomevfs-monitor but it doesn't get updated on the Desktop (nautilus error?) On the other hand some of the changes seem to be totally missed, although I think that might as well be a gamin problem. I would love if someone would play around with it a bit and see what's going on ...
Ok .. this seems to be a dup of bug #172365 and also seems in fact to be a problem of gamin. *** This bug has been marked as a duplicate of 172365 ***
I think marking this a dup of 172365 is premature. gamin never stops reporting events (and the events are correct from gamin's POV, afaict); however those events are being misunderstood by either gnome-vfs or possibly nautilus.
Ohh are you sure about that? How did you verify this? I looked at the fam code in the file method and there isnt any obvious error there (execpt one leak reportet by Vicent). Also the fam code of gnome-vfs is pretty "old" and there since a long time so I am still convinced that this is a dup. If you think otherwise please tell me why do you think so? How exaclty did you verify that gamin is working correctly and didn't stop sending events (although this seem to be a known problem). I leave this bug open for now but as I am pretty sure this isnt gnome-vfs I will not look into this anymore, but you are more then welcome to prove me wrong and point me to the error or even better send a patch :) Btw I also missed some events with the command line program I have checked into gnome-vfs cvs .. so I don't think nautilus is the one to blame here. If at all it is the fam code in file-method.c
Like I said in the original report, gamin reports the FAMChanged (dir /home/nicholas), FAMDeleted (file ToDo.txt), and FAMCreated (file TODO.txt) like normal, however when gnome-vfs converts the relative paths to absolute paths, it does it wrong. The userdata pointer in the event struct returned by FAMNextEvent points to the wrong data, so instead of computing absolute paths of /home/nicholas/ToDo.txt and /home/nicholas/TODO.txt, it computes /home/nicholas/.gnome/mime-info/ToDo.txt and home/nicholas/.gnome/mime-info/TODO.txt. Thus, views of /home/nicholas (my Desktop) are never updated because gnome-vfs isn't reporting /home/nicholas to be changed. So, either gnome-vfs is corrupting it's own userdata, or gamin is returning the wrong userdata. Does gnome-vfs assume that libfam is thread safe? My quick inspection suggests that it isn't, although I'm not sure that's an issue in this case.
Is that 100% reproduceable? I just tried fiddling with a TODO.txt/ToDO.txt file on my desktop, and things worked properly (though I restarted nautilkus first since when I created TODO.txt it refused to appear on my desktop). I'd tend to consider it's a gamin bug unless bug #172365 is fixed and this bug still happens ;)
Oh, another question that I forgot: you aren't using inotify, are you?
It isn't 100% reproducible, but once it starts, it doesn't stop until you restart nautilus. inotify hasn't been merged into the kernel yet, so, no, I'm not using it. That shouldn't make a difference, though gamin is delivering the events without problem.
Created attachment 45164 [details] GDB log of nautilus Note that all events occur as the result of changes to objects in /home/nicholas and that /usr/local/share/applications/mimeinfo.cache is a file, and thus couldn't possibly contain any of the objects that gnome-vfs thinks are changing.
Ok! I am still not convinced at all and the gdb log isnt that helpfull neither. I sometimes see nautilus not updating files but only if FAMCreate events are missed out. So I still think this is a gamin bug (and although I have the already patched ubuntu version). Please apply this patch: http://www.gnome.org/~gicmo/patches/fam-debug.patch Install the new file method and attach the debug output to this patch. If you need more details on how to generate/recored the debug output just let me know. Thanks Christian
Just btw .. nautilus places a monitor on /usr/local/share/applications/mimeinfo.cache on purpose (even though the file might not be there) .. not sure why you should get events for that though. We need more info for that. Also a killall -SIGUSR2 gam_server and a tail -f gamin_debug_XXXXXX might be useful to see what's going on.
I'm not getting events from /usr/local/share/applications/mimeinfo.cache. That would be impossible, /usr/local/share/applications/mimeinfo.cache is a file and couldn't possibly contain other files or directories to report events on. I'm getting events from /home/nicholas. gnome-vfs is wrongly attributing them to /usr/local/share/applications/mimeinfo.cache because FAMEvent::userdata points to the wrong FileMonitorHandle, either because gnome-vfs corrupted it's internal state, or gamin returned the wrong value. Christian: your patch wouldn't be helpful, I already know what is happening: The only problem is that FAMEvent::userdata as returned by FAMNextEvent isn't the correct value, and I have no idea why. gnome-vfs proceeds to use the wrong path to convert the relative path returned by FAMNextEvent to an absolute path, and then reports the wrong event. This is the third time I've restated the problem. I hope you understand it this time.
Thanks for the work on this bug. I think than your explantion of your understanding of the bugs is clear, but could you patch gnomevfs with http://www.gnome.org/~gicmo/patches/fam-debug.patch and attach that to the bug ? That would be useful to know if that behaviour is the same for the different people looking on this bug.
Are you still having issues?
Yes, but now that gamin is making an attempt at being thread safe, I think they're the usual mysterious gamin problems that everybody has.