bug#57536: 28.1; filenotify problems on macOS with symbolic links to directories

[Eli Zaretskii <eliz@gnu.org>]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: pedz@easesoftware.com,  57536@debbugs.gnu.org
> Date: Sat, 17 Sep 2022 17:15:04 +0200
> 
> > I'd start by documenting that we no longer follow symlinks when
> > watching: that's a kind-of incompatible change.  Then I'd go by
> > complaints, if any.
> 
> I've extended already the doc yesterday, see (info "(elisp) File Notifications")
> 
> --8<---------------cut here---------------start------------->8---
>      If FILE is a symlink, it doesn’t follow that link.  Just FILE
>      itself will be watched.
> --8<---------------cut here---------------end--------------->8---
> 
> And it isn't a visible incompatibility. Yes, inotify and w32notify did
> follow the link, and they have raised events for the link target. But in
> file-notify-handle-event this event must be adapted in order to keep the
> unified action names we have introduced in filenotify.el. And the event
> will be propagated only in case the full file name in that event is
> supervised via file-notify-add-watch. This didn't happen for the
> followed file names (the symlink targets), such events weren't
> propagated, and the effect for the users was the same as when inotify
> and w32notify didn't follow the link (as we have now). So I believe we
> have nothing to explain but just the clarification I have done
> yesterday.

Yes, you are right.

> >From my pov, this bug can be closed. The problem with kqueue I will work
> on once I have a new FreeBSD VM.

Fine by me, closing.

Thanks.