Indeed that looping behaviour is not bound to occur only on remote file systems, but it is caused by the current version of the database file (like "home") not referring to the redo log (like "home-01234567.log") that is currently opened by the gvfsd (because it was referred to by the database at the time gvfsd opened the database).
The usual reason for this mismatch is that the database has been replaced by a different version referring a different redo log file, but it could be due to data corruption, too. As long as the data base (and the redo log) is only used on a single system, the kernel (mostly?) ensures that once a redo log has been rotated into the data base, the "this redo log is rotated"-Bit is also seen by all other processes using the same redo log. This is why the bug usually does not appear in the single-system setup. There at least two different possible scenarios, how the mismatch could arise on a local file system, too: a) The local file system is exported, and the log has been rotated by a remote machine. b) The gvfs-metadata database directory has been restored from a backup while gvfsd-metadata was running. The temporary fix of disabling the metadata recording on remote file systems would help in scenario a, but not in scenario b. Regards, Michael Karcher -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org