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

[Michael Albinus <michael.albinus@gmx.de>]

Eli Zaretskii <eliz@gnu.org> writes:

Hi Eli,

>> Besides this, do we want to extend file notifications to follow symlinks
>> when indicated? As said already, we could add a new symbol `follow' to
>> be used in the FLAGS argument for that function. Implementation shall be
>> simple for inotify and w32notify; for the other backends it needs to be
>> investigated.
>
> I'm not sure this is needed: clients can always resolve the symlinks
> themselves, no?

OK.

> 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.

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

Best regards, Michael.