Do not show files that are not reachable

I certainly agree that we shouldn't display deleted items, but stat()ing each file in the result set is a bit scary to me. It is however, by far, the easiest solution right now.

The Real Fix (TM) is to fix bug #489194 and make Zeitgeist respect the StorageState parameter in the query.

Before I merge something like Seif's branch I'd like to consider if we can lighted the IO load a bit somehow... Any ideas? Perhaps some clever caching + monitoring parent dirs of result uris...

I had a look at some GIO stuff...
I dont know how much it depends on inotify, but i found a monitor_directory
method that could monitor the home directory recursively.
If it is elegant enough I could write an extension that monitors the home
directory for move event and update the uris in the DB as well as push in a
"MOVE" event.
We should also see how tracker does it to keep track of their uuids.

On Mon, Jun 28, 2010 at 8:07 PM, Mikkel Kamstrup Erlandsen <
<email address hidden>> wrote:

> I certainly agree that we shouldn't display deleted items, but stat()ing
> each file in the result set is a bit scary to me. It is however, by far,
> the easiest solution right now.
>
> The Real Fix (TM) is to fix bug #489194 and make Zeitgeist respect the
> StorageState parameter in the query.
>
> Before I merge something like Seif's branch I'd like to consider if we
> can lighted the IO load a bit somehow... Any ideas? Perhaps some clever
> caching + monitoring parent dirs of result uris...
>
> ** Branch linked: lp:~seif/unity-place-files/check-for-path
>
> --
> Do not show files that are not reachable
> https://bugs.launchpad.net/bugs/599271
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in Unity Files Place: New
>
> Bug description:
> Files that are not reachable because they have been moved or deleted should
> not appear in the documents view.
> However if nautilus is patched to tell us that something was copied or
> moved we could still display it by showing the right path.
> However deleted items should not be there at all...
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/unity-place-files/+bug/599271/+subscribe
>

--
This is me doing some advertisement for my blog http://seilo.geekyogre.com

Both Tracker and the GFileMonitor (obtainable fx. vi g_file_monitor()) use inotify. And I am quite sure that GIOs monitoring doesn't provide recursive watching.

Last time I check Tracker simply crawled you FS on each startup installing monitors on all directories in the indexed paths.

When FSNotify is universally available in kernels and there pops up a GIO backend for GFileMonitor that uses fsnotify we may have a chance of doing relatively cheap recursive watching. Otherwise btrfs will also be of help when it goes mainstream. But until then I'd strongly advice against large scale file monitoring (unless one has significant manpower resources to throw at it).

Just to clarify: s/fsnotify/fanotify/ in my last comment

hey guys i added a branch for this issue
lp:~seif/unity-place-files/check-path

Branch merged. Thanks Seif.

I filed a new bug about coming up with a smarter (more IO-friendly) way to accomplish this. See bug #607206