GNU bug report logs - #57536
28.1; filenotify problems on macOS with symbolic links to directories

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 57536 in the body.
You can then email your comments to 57536 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Perry Smith <pedz <at> easesoftware.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.1; filenotify problems on macOS with symbolic links to directories
Date: Thu, 1 Sep 2022 18:34:39 -0500

[Message part 1 (text/plain, inline)]

Referencing these commands:
; 1
(require 'filenotify)

; 2
(defun my-callback (directory)
  (message (format "called %s" directory)))

; 3
(file-notify-add-watch "/private/tmp"  '(change attribute-change) 'my-callback)

; 4
(file-notify-add-watch "/tmp"  '(change attribute-change) 'my-callback)

Starting with a fresh emacs -Q, if I execute lines 1, 2, and 3 and then
touch a file such as /tmp/OUT, I get the notification as I should.

However if I start fresh, execute lines 1, 2, and 4, and touch /tmp/OUT,
I do not get a notification.

On a Mac, /tmp is a symbolic link to private/tmp (relative path).

I first discovered this issue using Helm's find-file and I entered a
report with Helm.  The Helm developer reports that it works in his case
with Linux.

I'm using a new M1 Mac, macOS 12.5.1 and using the newish AFS.  I built
this emacs myself so it might be pilot error with my build but that
seems less likely since file notify does generally work but not when the
watched file is a symbolic link to a directory.

Also, this is not /tmp => private/tmp specific.  I can recreate the same
issue using ~/Desktop/Dog/tmp and a symbolic link ~/Desktop/tmp that has
a relative path of Dog/tmp and I get the same issue.

In GNU Emacs 28.1 (build 1, aarch64-apple-darwin21.4.0, NS appkit-2113.40 Version 12.3.1 (Build 21E258))
of 2022-04-04 built on Peace.lan
Repository revision: bffd375b378025c8f5fd947fdac8ed710cb980d7
Repository branch: master
Windowing system distributor 'Apple', version 10.3.2113
System Description:  macOS 12.5.1

Configured features:
ACL GNUTLS LCMS2 LIBXML2 MODULES NOTIFY KQUEUE NS PDUMPER PNG THREADS
TOOLKIT_SCROLL_BARS ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: ELisp/d

Minor modes in effect:
  global-git-commit-mode: t
  magit-auto-revert-mode: t
  global-rbenv-mode: t
  recentf-mode: t
  display-time-mode: t
  helm-mode: t
  helm-minibuffer-history-mode: t
  shell-dirtrack-mode: t
  helm--remap-mouse-mode: t
  async-bytecomp-package-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
/Users/pedz/.config/emacs/el-get/lua-mode/init-tryout hides /Users/pedz/.config/emacs/el-get/ample-regexps/init-tryout
/Users/pedz/.config/emacs/el-get/transient/lisp/transient hides /Applications/Emacs.app/Contents/Resources/lisp/transient

Features:
(cc-mode cc-fonts cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine
cc-vars cc-defs debug shadow sort mail-extr warnings emacsbug sendmail
cus-start cus-load sh-script executable markdown-mode color make-mode
apropos yari ebuff-menu tabify man vc-mtn vc-hg vc-bzr vc-src vc-sccs
vc-svn vc-cvs vc-rcs vc bug-reference face-remap magit-bookmark
git-rebase magit-extras magit-sparse-checkout magit-gitignore
magit-ediff ediff ediff-merg ediff-mult ediff-wind ediff-diff ediff-help
ediff-init ediff-util magit-subtree magit-patch magit-submodule
magit-obsolete magit-blame magit-stash magit-reflog magit-bisect
magit-push magit-pull magit-fetch magit-clone magit-remote magit-commit
magit-sequence magit-notes magit-worktree magit-tag magit-merge
magit-branch magit-reset magit-files magit-refs magit-status magit
magit-repos magit-apply magit-wip magit-log which-func imenu magit-diff
smerge-mode diff git-commit log-edit pcvs-util add-log magit-core
magit-autorevert autorevert magit-margin magit-transient magit-process
with-editor server magit-mode transient magit-git magit-base
magit-section crm dash rbenv ruby-mode smie rect find-dired grep compile
shortdoc misearch multi-isearch recentf tree-widget helm-x-files
helm-for-files helm-bookmark helm-adaptive org-duration org-clock
org-element avl-tree generator ol-eww eww xdg url-queue mm-url ol-rmail
ol-mhe ol-irc ol-info ol-gnus nnselect gnus-search eieio-opt speedbar
ezimage dframe gnus-art mm-uu mml2015 mm-view mml-smime smime dig
gnus-sum shr kinsoku svg dom gnus-group gnus-undo gnus-start gnus-dbus
gnus-cloud nnimap nnmail mail-source utf7 netrc nnoo gnus-spec gnus-int
gnus-range message rmc puny rfc822 mml mml-sec epa derived epg rfc6068
epg-config mm-decode mm-bodies mm-encode mailabbrev gmm-utils mailheader
gnus-win gnus nnheader gnus-util rmail rmail-loaddefs mail-utils
wid-edit ol-docview doc-view jka-compr ol-bibtex ol-bbdb ol-w3m ol-doi
org-link-doi org ob ob-tangle ob-ref ob-lob ob-table ob-exp org-macro
org-footnote org-src ob-comint org-pcomplete org-list org-faces
org-entities noutline outline org-version ob-emacs-lisp ob-core ob-eval
org-table oc-basic bibtex ol rx org-keys oc org-compat advice org-macs
org-loaddefs cal-menu calendar cal-loaddefs cl-print help-fns dired-aux
image-file image-converter helm-external helm-net ffap vc-git diff-mode
vc-dispatcher flyspell ispell bookmark text-property-search winner
thingatpt tramp-archive tramp-gvfs dbus xml helm-command helm-elisp
helm-eval edebug backtrace find-func helm-info info helm-setup pedz
resize ruby-setup time el-get-setup helm-mode helm-misc helm-files
image-dired image-mode exif filenotify tramp tramp-loaddefs trampver
tramp-integration files-x tramp-compat shell pcomplete comint ring
parse-time iso8601 time-date ls-lisp helm-buffers helm-occur helm-tags
helm-locate helm-grep helm-regexp format-spec ansi-color helm-utils
helm-help helm-types helm helm-global-bindings helm-easymenu helm-core
easy-mmode edmacro kmacro async-bytecomp helm-source helm-multi-match
helm-lib async helm-config helm-autoloads el-get el-get-autoloading
el-get-list-packages el-get-dependencies el-get-build el-get-status pp
el-get-methods el-get-fossil el-get-svn el-get-pacman el-get-github-zip
el-get-github-tar el-get-http-zip el-get-http-tar el-get-hg el-get-go
el-get-git-svn el-get-fink el-get-emacswiki el-get-http el-get-notify
el-get-emacsmirror el-get-github el-get-git el-get-elpa package
browse-url url url-proxy url-privacy url-expand url-methods url-history
url-cookie url-domsuf url-util mailcap url-handlers url-parse
auth-source eieio eieio-core cl-macs eieio-loaddefs password-cache json
map url-vars el-get-darcs el-get-cvs el-get-bzr el-get-brew
el-get-builtin el-get-apt-get el-get-recipes el-get-byte-compile subr-x
el-get-custom cl-extra help-mode seq byte-opt gv cl-seq el-get-core
autoload radix-tree lisp-mnt mail-parse rfc2231 rfc2047 rfc2045 mm-util
ietf-drums mail-prsvr bytecomp byte-compile cconv dired dired-loaddefs
cl-loaddefs cl-lib iso-transl tooltip eldoc paren electric uniquify
ediff-hook vc-hooks lisp-float-type elisp-mode mwheel term/ns-win ns-win
ucs-normalize mule-util term/common-win tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu
timer select scroll-bar mouse jit-lock font-lock syntax font-core
term/tty-colors frame minibuffer cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite emoji-zwj charscript charprop case-table
epa-hook jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice
button loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote threads kqueue cocoa ns lcms2
multi-tty make-network-process emacs)

Memory information:
((conses 16 792904 71749)
(symbols 48 42889 12)
(strings 32 204756 30906)
(string-bytes 1 7937607)
(vectors 16 88687)
(vector-slots 8 1724598 211160)
(floats 8 529 451)
(intervals 56 79268 873)
(buffers 992 91))

[signature.asc (application/pgp-signature, attachment)]

Message #8 received at 57536 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Perry Smith <pedz <at> easesoftware.com>,
 Michael Albinus <michael.albinus <at> gmx.de>
Cc: 57536 <at> debbugs.gnu.org
Subject: Re: bug#57536: 28.1;
 filenotify problems on macOS with symbolic links to directories
Date: Fri, 02 Sep 2022 09:25:29 +0300

> From: Perry Smith <pedz <at> easesoftware.com>
> Date: Thu, 1 Sep 2022 18:34:39 -0500
> 
> Referencing these commands:
> ; 1
> (require 'filenotify)
> 
> ; 2
> (defun my-callback (directory)
>   (message (format "called %s" directory)))
> 
> ; 3
> (file-notify-add-watch "/private/tmp"  '(change attribute-change) 'my-callback)
> 
> ; 4
> (file-notify-add-watch "/tmp"  '(change attribute-change) 'my-callback)
> 
> Starting with a fresh emacs -Q, if I execute lines 1, 2, and 3 and then
> touch a file such as /tmp/OUT, I get the notification as I should.
> 
> However if I start fresh, execute lines 1, 2, and 4, and touch /tmp/OUT,
> I do not get a notification.
> 
> On a Mac, /tmp is a symbolic link to private/tmp (relative path).

I don't see any bug here.  If file-notify-add-watch would resolve
symlinks of its argument, we would be unable to watch changes to the
symlink file itself.

So if you want to watch changes for the target of a symlink, your Lisp
program needs to resolve symlinks, e.g. by calling file-truename or
something similar.

> I first discovered this issue using Helm's find-file and I entered a
> report with Helm.  The Helm developer reports that it works in his case
> with Linux.

That could be a (mis)feature of our use of inotify, which is used on
GNU/Linux for implementing file notifications.  AFAIU, inotify allows
control on whether to follow symlinks when setting a watch, and its
default is to follow symlinks.  I think we should call inotify so as
not to follow symlinks.

Michael, WDYT?

Message #13 received at 57536 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Perry Smith <pedz <at> easesoftware.com>, 57536 <at> debbugs.gnu.org
Subject: Re: bug#57536: 28.1; filenotify problems on macOS with symbolic
 links to directories
Date: Sun, 04 Sep 2022 13:42:16 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

Hi,

>> Referencing these commands:
>> ; 1
>> (require 'filenotify)
>>
>> ; 2
>> (defun my-callback (directory)
>>   (message (format "called %s" directory)))
>>
>> ; 3
>> (file-notify-add-watch "/private/tmp"  '(change attribute-change) 'my-callback)
>>
>> ; 4
>> (file-notify-add-watch "/tmp"  '(change attribute-change) 'my-callback)
>>
>> Starting with a fresh emacs -Q, if I execute lines 1, 2, and 3 and then
>> touch a file such as /tmp/OUT, I get the notification as I should.
>>
>> However if I start fresh, execute lines 1, 2, and 4, and touch /tmp/OUT,
>> I do not get a notification.
>>
>> On a Mac, /tmp is a symbolic link to private/tmp (relative path).
>
> I don't see any bug here.  If file-notify-add-watch would resolve
> symlinks of its argument, we would be unable to watch changes to the
> symlink file itself.

I agree. Emacs' file notifications are not designed to follow
symlinks. The manual in (info "(elisp) File Notifications") is silent
about, perhaps we shall clarify.

> So if you want to watch changes for the target of a symlink, your Lisp
> program needs to resolve symlinks, e.g. by calling file-truename or
> something similar.

Yep.

>> I first discovered this issue using Helm's find-file and I entered a
>> report with Helm.  The Helm developer reports that it works in his case
>> with Linux.
>
> That could be a (mis)feature of our use of inotify, which is used on
> GNU/Linux for implementing file notifications.  AFAIU, inotify allows
> control on whether to follow symlinks when setting a watch, and its
> default is to follow symlinks.  I think we should call inotify so as
> not to follow symlinks.

Yep. We shall go through our f-n libraries and check the current
behavior, preferred by a new test case. And we shall adjust the
libraries to behave similar.

Will do next days.

Btw, there are bug#16113 and bug#18883, which report a similar problem
in auto-reverting. A possible solution could be to extend the FLAGS arg
of file-notify-add-watch by a condition 'follow', which means to
supervise the expanded symlink instead of the link file itself.

inotify knows the mask bit IN_DONT_FOLLOW (which we haven't set yet),
see inotify(7). Other libraries might offer similar possibilities, which
I haven't checked yet.

Best regards, Michael.

Message #16 received at 57536 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: pedz <at> easesoftware.com, 57536 <at> debbugs.gnu.org
Subject: Re: bug#57536: 28.1; filenotify problems on macOS with symbolic
 links to directories
Date: Sun, 04 Sep 2022 16:10:22 +0300

> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: Perry Smith <pedz <at> easesoftware.com>,  57536 <at> debbugs.gnu.org
> Date: Sun, 04 Sep 2022 13:42:16 +0200
> 
> > I don't see any bug here.  If file-notify-add-watch would resolve
> > symlinks of its argument, we would be unable to watch changes to the
> > symlink file itself.
> 
> I agree. Emacs' file notifications are not designed to follow
> symlinks. The manual in (info "(elisp) File Notifications") is silent
> about, perhaps we shall clarify.

Yes, we should clarify that, both in the manual and in the doc
strings, I think.

> Btw, there are bug#16113 and bug#18883, which report a similar problem
> in auto-reverting. A possible solution could be to extend the FLAGS arg
> of file-notify-add-watch by a condition 'follow', which means to
> supervise the expanded symlink instead of the link file itself.

I think it would be better to handle that option in Lisp, before we
call the OS-specific notification library.  That way, we can control
better what exactly "follow symlinks" means.

> inotify knows the mask bit IN_DONT_FOLLOW (which we haven't set yet),
> see inotify(7). Other libraries might offer similar possibilities, which
> I haven't checked yet.

I see that w32notify.c currently follows symlinks; that will need to
be fixed.

Message #19 received at 57536 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: pedz <at> easesoftware.com, 57536 <at> debbugs.gnu.org
Subject: Re: bug#57536: 28.1; filenotify problems on macOS with symbolic
 links to directories
Date: Sun, 04 Sep 2022 16:26:54 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

Hi Eli,

>> Btw, there are bug#16113 and bug#18883, which report a similar problem
>> in auto-reverting. A possible solution could be to extend the FLAGS arg
>> of file-notify-add-watch by a condition 'follow', which means to
>> supervise the expanded symlink instead of the link file itself.
>
> I think it would be better to handle that option in Lisp, before we
> call the OS-specific notification library.  That way, we can control
> better what exactly "follow symlinks" means.

Of course, that's why I've mentioned file-notify-add-watch.

>> inotify knows the mask bit IN_DONT_FOLLOW (which we haven't set yet),
>> see inotify(7). Other libraries might offer similar possibilities, which
>> I haven't checked yet.
>
> I see that w32notify.c currently follows symlinks; that will need to
> be fixed.

Yep. I guess you'll care about w32notify.c. and I'll check inotify.c,
kqueue.c and gfilenotify.c?

Best regards, Michael.

Message #22 received at 57536 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: pedz <at> easesoftware.com, 57536 <at> debbugs.gnu.org
Subject: Re: bug#57536: 28.1; filenotify problems on macOS with symbolic
 links to directories
Date: Sun, 04 Sep 2022 17:49:45 +0300

> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: pedz <at> easesoftware.com,  57536 <at> debbugs.gnu.org
> Date: Sun, 04 Sep 2022 16:26:54 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> inotify knows the mask bit IN_DONT_FOLLOW (which we haven't set yet),
> >> see inotify(7). Other libraries might offer similar possibilities, which
> >> I haven't checked yet.
> >
> > I see that w32notify.c currently follows symlinks; that will need to
> > be fixed.
> 
> Yep. I guess you'll care about w32notify.c. and I'll check inotify.c,
> kqueue.c and gfilenotify.c?

Yes.

Message #25 received at 57536 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: michael.albinus <at> gmx.de
Cc: pedz <at> easesoftware.com, 57536 <at> debbugs.gnu.org
Subject: Re: bug#57536: 28.1;
 filenotify problems on macOS with symbolic links to directories
Date: Wed, 07 Sep 2022 15:20:55 +0300

> Cc: pedz <at> easesoftware.com, 57536 <at> debbugs.gnu.org
> Date: Sun, 04 Sep 2022 17:49:45 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> 
> > From: Michael Albinus <michael.albinus <at> gmx.de>
> > Cc: pedz <at> easesoftware.com,  57536 <at> debbugs.gnu.org
> > Date: Sun, 04 Sep 2022 16:26:54 +0200
> > 
> > Eli Zaretskii <eliz <at> gnu.org> writes:
> > 
> > >> inotify knows the mask bit IN_DONT_FOLLOW (which we haven't set yet),
> > >> see inotify(7). Other libraries might offer similar possibilities, which
> > >> I haven't checked yet.
> > >
> > > I see that w32notify.c currently follows symlinks; that will need to
> > > be fixed.
> > 
> > Yep. I guess you'll care about w32notify.c. and I'll check inotify.c,
> > kqueue.c and gfilenotify.c?
> 
> Yes.

Now done on the master branch.

Message #28 received at 57536 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: pedz <at> easesoftware.com, 57536 <at> debbugs.gnu.org
Subject: Re: bug#57536: 28.1; filenotify problems on macOS with symbolic
 links to directories
Date: Wed, 07 Sep 2022 17:57:08 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> > Yep. I guess you'll care about w32notify.c. and I'll check inotify.c,
>> > kqueue.c and gfilenotify.c?
>
> Now done on the master branch.

Thanks! I hope to get done my parts next days ...

Best regrds, Michael.

Message #31 received at 57536 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: pedz <at> easesoftware.com, 57536 <at> debbugs.gnu.org
Subject: Re: bug#57536: 28.1; filenotify problems on macOS with symbolic
 links to directories
Date: Fri, 16 Sep 2022 17:27:34 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

Hi Eli,

>> Yep. I guess you'll care about w32notify.c. and I'll check inotify.c,
>> kqueue.c and gfilenotify.c?
>
> Yes.

I've pushed the changes for inotify and the remote inotifywait. There's
also a new testcase file-notify-test11-symlinks. Do you mind to check it
on w32?

The other cases will follow.

Best regards, Michael.

Message #34 received at 57536 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: pedz <at> easesoftware.com, 57536 <at> debbugs.gnu.org
Subject: Re: bug#57536: 28.1; filenotify problems on macOS with symbolic
 links to directories
Date: Fri, 16 Sep 2022 18:56:33 +0300

> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: pedz <at> easesoftware.com,  57536 <at> debbugs.gnu.org
> Date: Fri, 16 Sep 2022 17:27:34 +0200
> 
> I've pushed the changes for inotify and the remote inotifywait. There's
> also a new testcase file-notify-test11-symlinks. Do you mind to check it
> on w32?

I don't think I can: I have XP here, where symlinks aren't supported.

Would someone else please see if the new test works on MS-Windows?

Message #37 received at 57536 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: pedz <at> easesoftware.com, 57536 <at> debbugs.gnu.org
Subject: Re: bug#57536: 28.1; filenotify problems on macOS with symbolic
 links to directories
Date: Fri, 16 Sep 2022 18:39:10 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

Hi Eli,

>> I've pushed the changes for inotify and the remote inotifywait. There's
>> also a new testcase file-notify-test11-symlinks. Do you mind to check it
>> on w32?
>
> I don't think I can: I have XP here, where symlinks aren't supported.
>
> Would someone else please see if the new test works on MS-Windows?

Hmm. Somewhere, I have a Windows 10 VM lying around. Perhaps I can
convince it to support symlinks in Emacs, and test then.

Disclaimer: I don't know what I'm doing.

Best regards, Michael.

Message #40 received at 57536 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: pedz <at> easesoftware.com, 57536 <at> debbugs.gnu.org
Subject: Re: bug#57536: 28.1; filenotify problems on macOS with symbolic
 links to directories
Date: Sat, 17 Sep 2022 11:02:49 +0200

Michael Albinus <michael.albinus <at> gmx.de> writes:

Hi Eli,

>>> I've pushed the changes for inotify and the remote inotifywait. There's
>>> also a new testcase file-notify-test11-symlinks. Do you mind to check it
>>> on w32?
>>
>> I don't think I can: I have XP here, where symlinks aren't supported.
>>
>> Would someone else please see if the new test works on MS-Windows?
>
> Hmm. Somewhere, I have a Windows 10 VM lying around. Perhaps I can
> convince it to support symlinks in Emacs, and test then.

Well, the test fails with

--8<---------------cut here---------------start------------->8---
Test file-notify-test11-symlinks condition:
    (file-error "Making symbolic link" "Operation not permitted" "c:/Users/albinus/AppData/Local/Temp/file-notify-testQ4fWLh/file-notify-testoFYuvn" "c:/Users/albinus/AppData/Local/Temp/file-notify-testQ4fWLh/file-notify-testLaRL78")
--8<---------------cut here---------------end--------------->8---

So a simple `make-symbolic-link' doesn't seem to work on MS
Windows. What shall I do instead?

Best regards, Michael.

Message #43 received at 57536 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: pedz <at> easesoftware.com, 57536 <at> debbugs.gnu.org
Subject: Re: bug#57536: 28.1; filenotify problems on macOS with symbolic
 links to directories
Date: Sat, 17 Sep 2022 12:43:01 +0300

> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: pedz <at> easesoftware.com,  57536 <at> debbugs.gnu.org
> Date: Sat, 17 Sep 2022 11:02:49 +0200
> 
> >> Would someone else please see if the new test works on MS-Windows?
> >
> > Hmm. Somewhere, I have a Windows 10 VM lying around. Perhaps I can
> > convince it to support symlinks in Emacs, and test then.
> 
> Well, the test fails with
> 
> --8<---------------cut here---------------start------------->8---
> Test file-notify-test11-symlinks condition:
>     (file-error "Making symbolic link" "Operation not permitted" "c:/Users/albinus/AppData/Local/Temp/file-notify-testQ4fWLh/file-notify-testoFYuvn" "c:/Users/albinus/AppData/Local/Temp/file-notify-testQ4fWLh/file-notify-testLaRL78")
> --8<---------------cut here---------------end--------------->8---
> 
> So a simple `make-symbolic-link' doesn't seem to work on MS
> Windows.

It should work if you give your user the privilege of creating
symlinks.

Alternatively, try running Emacs from a cmd.exe window that is "Run as
Administrator".

Creating symlinks is a privileged operation on MS-Windows (at least
before Windows 11, where I hear that restriction was lifted?)

Message #46 received at 57536 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: pedz <at> easesoftware.com, 57536 <at> debbugs.gnu.org
Subject: Re: bug#57536: 28.1; filenotify problems on macOS with symbolic
 links to directories
Date: Sat, 17 Sep 2022 15:16:37 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

Hi Eli,

>> So a simple `make-symbolic-link' doesn't seem to work on MS
>> Windows.
>
> It should work if you give your user the privilege of creating
> symlinks.

But the damn User Account Settings don't give me this possibility :-(

> Alternatively, try running Emacs from a cmd.exe window that is "Run as
> Administrator".

That worked, thanks.

Your changes in w32notify.c work as expected, I simply needed to adapt
the test case a little bit. I've added also to skip this test, when
make-symbolic-link doesn't work.

Pushed to master.

Best regards, Michael.

Message #49 received at 57536 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: pedz <at> easesoftware.com, 57536 <at> debbugs.gnu.org
Subject: Re: bug#57536: 28.1; filenotify problems on macOS with symbolic
 links to directories
Date: Sat, 17 Sep 2022 15:27:45 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

Hi Eli,

>> Yep. I guess you'll care about w32notify.c. and I'll check inotify.c,
>> kqueue.c and gfilenotify.c?
>
> Yes.

So everything is tested, the cases mentioned above as well as the remote
inotifywait and gio variants. Everything works as expected except
kqueue, where I get an EMLINK error when running file-notify-add-watch
on a symlink file. Needs further investigation, but unfortunately, while
testing, my FreeBSD 12 VM has crashed with an unrecoverable error. So I
need to install a new VM first.

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.

WDYT?

Best regards, Michael.

Message #52 received at 57536 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: pedz <at> easesoftware.com, 57536 <at> debbugs.gnu.org
Subject: Re: bug#57536: 28.1; filenotify problems on macOS with symbolic
 links to directories
Date: Sat, 17 Sep 2022 16:53:23 +0300

> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: pedz <at> easesoftware.com,  57536 <at> debbugs.gnu.org
> Date: Sat, 17 Sep 2022 15:27:45 +0200
> 
> 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?

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.

Message #55 received at 57536 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: pedz <at> easesoftware.com, 57536 <at> debbugs.gnu.org
Subject: Re: bug#57536: 28.1; filenotify problems on macOS with symbolic
 links to directories
Date: Sat, 17 Sep 2022 17:07:50 +0300

> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: pedz <at> easesoftware.com,  57536 <at> debbugs.gnu.org
> Date: Sat, 17 Sep 2022 15:16:37 +0200
> 
> > It should work if you give your user the privilege of creating
> > symlinks.
> 
> But the damn User Account Settings don't give me this possibility :-(

AFAIK, it is not under User Account Settings.  It is under

  Control Panel->Administrative Tools->Local Security Policy->Local Policies->User Rights Assignment

Look for "Create symbolic links" policy.

The above will have no effect if your user is in the Administrators
group: those must use the "Run as Administrator" method.

> > Alternatively, try running Emacs from a cmd.exe window that is "Run as
> > Administrator".
> 
> That worked, thanks.
> 
> Your changes in w32notify.c work as expected, I simply needed to adapt
> the test case a little bit. I've added also to skip this test, when
> make-symbolic-link doesn't work.

Thanks.

Message #58 received at 57536 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: pedz <at> easesoftware.com, 57536 <at> debbugs.gnu.org
Subject: Re: bug#57536: 28.1; filenotify problems on macOS with symbolic
 links to directories
Date: Sat, 17 Sep 2022 17:03:33 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

Hi Eli,

>> But the damn User Account Settings don't give me this possibility :-(
>
> AFAIK, it is not under User Account Settings.  It is under
>
>   Control Panel->Administrative Tools->Local Security Policy->Local Policies->User Rights Assignment
>
> Look for "Create symbolic links" policy.

Indeed. Thanks.

Best regards, Michael.

Message #61 received at 57536 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: pedz <at> easesoftware.com, 57536 <at> debbugs.gnu.org
Subject: Re: bug#57536: 28.1; filenotify problems on macOS with symbolic
 links to directories
Date: Sat, 17 Sep 2022 17:15:04 +0200

Eli Zaretskii <eliz <at> 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.

Message #66 received at 57536-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: pedz <at> easesoftware.com, 57536-done <at> debbugs.gnu.org
Subject: Re: bug#57536: 28.1; filenotify problems on macOS with symbolic
 links to directories
Date: Sat, 17 Sep 2022 18:37:29 +0300

> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: pedz <at> easesoftware.com,  57536 <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.