I can't comment on the details just yet, I need to get reacquainted with the
code. In general the problem is that as far inotify is concerned symlinks don't
exist. When you ask inotify to watch a symlink it watches the inode that the
symlink points to. The current code tried to match FAM's handling of a symlink,
which was to watch the link and not what was pointed to by it.

We should decide on a symlink policy for gnome-vfs. Do we want to be able to
watch the symbolic link or do we want to watch whatever is pointed to by the
symbolic link?

Consider 'Watch /tmp/foo which is a symlink to /tmp/bar'

-We want to know when /tmp/foo is deleted.
	We can do this by watching /tmp.
-We want to know when /tmp/foo is written to.
	We have to watch whatever /tmp/foo is pointing to.
	**If /tmp/foo was a regular file, we could accomplish this by watching /tmp.

It gets worse if an application also watches /tmp/bar because inotify treats
them as if they were the same thing.

The fix for this bug is to just ignore the fact that we are watching a symlink.
So, just watch it with inotify like it is anything else. You will get
notification when files are changed in the directory.

I think some scenarios need to be constructed that show the behaviour we want to
have when symlinks are involved.

Lets start with a user interface perspective here. There are two
common uses of file monitoring in Nautilus, one is the "display a
directory and keep it up to date" and one is a "display the properties
window for a file and keep it up to date.

For the directory case we're interested in renames/moves/deletes of
the directory inode (in the case of rename we update things, in the
case of delete we close the window), changes of directory contents
(file add/remove/move) and changes to the metadata/contents of files
in the directory (to update file type, file size display, etc).

For the properties case we're interested in the file getting
removed/renamed (meaning we close/retitle the window) and changes of
metadata/contents of the file (to update properties/type in the
dialog). For properties of directories we currently display the
recursive count+size but don't monitor it, which i think is sane.

Now, in the case where the item in these cases is a symlink to an
existing file we want the same behaviour. The question is, at what
level do we implement this similarity.

Currently, the way we monitor the folder case is that we have a single
monitor on the folder. This breaks in the case the folder is a
symlink, and i guess it also fails to update if a file in the
directory is a symlink to a file that changes.

The way we monitor for the properties dialog is different though. We
monitor both the target and the source of the file, so things work
even when the file is a symlink (or a desktop file shortcut).

So, do we make the monitoring framework handle the directory case, or
do we handle it in the app. I think a middle road might be useful
here. We pass a FOLLOW_SYMLINK_FLAG flag (addition to GnomeVFSMonitorType,
say "1<<31") to the add_monitor call. This then decides whether to
monitor the source or the target. For nautilus watching a folder we
then start both monitors, but for the very common case of file is not
a symlink we make sure in gnome-vfs to only actually have one inotify
monitor that is shared by these two monitors.

What do you think of this? The only problem it has is the symlink destination of
file in monitored folder is missed. But, even that could be fixed, as nautilus
does have some code to track symlinks (I think).

At the same time we can add a SEND_MOVE_EVENTS_FLAG flag so that we
can add move events to the inotify backend. (Other backends continue
to send remove+add events even if the flag is passed, its a
best-effort thing.)

*** Bug 318999 has been marked as a duplicate of this bug. ***

Your suggestion of a flag sounds good. I am working on implementing this now.
Could you add those flags to GnomeVFS ?

With my latest commit, sym link directories should work like a real directory.

I looked at the flags idea. Its a bit hard, since the notification callback only
has one uri argument. You'd have to use a different type of callback if you
specify that you want move events, which is a bit nasty...

Yep. Sending move events is going to require a new callback function type. The
symbolic link flag is still doable. I think the default behaviour should be to
follow a symlink. So the flag should be DONT_FOLLOW_SYMLINK_FLAG. This will keep
gnome-vfs-monitor backwards compatible. 

Changing component to the brand new Monitoring (inotify).

This has been fixed for a while. I will open bugs for the other issues discussed here.

I am using Gnome 2.12.2 and this problem still exists.

When I view a symlinked directory, it never gets updated.  I have to manually update it.

This bug does not affect gnome 2.12