| 1 |
Apparently, though unproven, at 20:13 on Friday 19 November 2010, BRM did |
| 2 |
opine thusly: |
| 3 |
|
| 4 |
> > My guess is that it scans every time you restart to be sure nothing |
| 5 |
> > changed while it was shutdown. It doesn't know if you've dual-booted, |
| 6 |
> > logged into xfce, mounted the disk in another machine, had fsck remove |
| 7 |
> > files, etc. |
| 8 |
> > |
| 9 |
> > |
| 10 |
> > |
| 11 |
> > I think Tracker behaves the same way in gnome-land. |
| 12 |
> |
| 13 |
> To add to it - Nepomuk has two parts (according to |
| 14 |
> http://nepomuk.kde.org/node/2) that seem to be active in here: |
| 15 |
> 1. Strigi - |
| 16 |
> http://techbase.kde.org/Development/Tutorials/Metadata/Nepomuk/StrigiServic |
| 17 |
> e 2. FileWatchService - |
| 18 |
> http://techbase.kde.org/Development/Tutorials/Metadata/Nepomuk/FileWatchSer |
| 19 |
> vice |
| 20 |
> |
| 21 |
> From the FileWatchService info: |
| 22 |
> |
| 23 |
> "However: due to the restrictions of all file watching systems available |
| 24 |
> (systems such as inotify are restricted to 8000 something watches, fam |
| 25 |
> does not support file moving monitoring, etc.) the service mostly relies |
| 26 |
> on KDirNotify. Thus, all operations performed by KDE applications through |
| 27 |
> KIO are monitored while all other operations (such as console commands) |
| 28 |
> are missed." |
| 29 |
> |
| 30 |
> So it really does need to check up on things during restart to get back in |
| 31 |
> sync, but also to find what it didn't know about from info not going |
| 32 |
> through an interface it is aware of. |
| 33 |
|
| 34 |
Well at least that explains the reason for the current state of affairs. |
| 35 |
Thanks for the find. |
| 36 |
|
| 37 |
|
| 38 |
-- |
| 39 |
alan dot mckinnon at gmail dot com |
Archives