Re: [Tracker] REVIEW: 'follow-symlinks' branch

[Aleksander Morgado <aleksander aleksander es>]

On Mon, Mar 17, 2014 at 10:40 AM, Martyn Russell <martyn lanedo com> wrote:
> There was recent interest in following symlinks within Tracker:
>
>   https://bugzilla.gnome.org/show_bug.cgi?id=726264
>
> For those that don't know, Tracker uses GIO and in nearly every case the
> G_FILE_QUERY_INFO_NOFOLLOW_SYMLINKS flag, documented here:
>
>   https://developer.gnome.org/gio/stable/GFile.html#GFileQueryInfoFlags
>
> The bug above talks about how disruptive this is for git-annex which almost
> entirely uses symlinks to git objects/resources in .git/. We've had this
> policy/code in Tracker for a LOOONG time, I think, to avoid following files
> onto remote file systems or into public (e.g. /usr/share) areas.
>
> I knocked up a preliminary branch here:
>
>   https://git.gnome.org/browse/tracker/log/?h=follow-symlinks
>
> Which removes these flags for testing, but I wanted to gauge usefulness
> before taking this any further.
>
> So:
>
> 1. Would a patch/branch like this be useful to anyone?
>
> 2. Would it make sense to make this a configuration option in the miner-fs
> (defaulting to the current practise), that way, avoiding any unexpected
> behaviour from what we have now?
>
> Thoughts?


The key point here is to decide when to follow the symlink, because by
default we shouldn't be following all.

What if there is a symlink to a file which is configured not to be
indexed at all? The git-annex setup case would be this case actually,
as the symlink points to a path within the .git directory (hidden, not
indexed by default).

What if the symlink points to a directory which is already in the list
of paths to index? Wouldn't that re-index all the files within that
path with another path based on the symlink? In a worst case, what if
the symlink points to the root path? Or what if you end up getting a
closed loop in the symlinks?

A maybe not very bad default could be to only follow symlinks if the
target is a file (i.e. skip symlinks to directories). That would
handle the git-annex case at least...  I believe your patch does also
follow symlinks to directories, doesn't it?

-- 
Aleksander
https://aleksander.es