* bug#21432: 25.0.50; file-notify-rm-watch (inotify) errors if watched dir is deleted
@ 2015-09-08 6:36 Tassilo Horn
2015-09-08 7:47 ` Michael Albinus
` (2 more replies)
0 siblings, 3 replies; 36+ messages in thread
From: Tassilo Horn @ 2015-09-08 6:36 UTC (permalink / raw)
To: 21432
Right now, (at least) the inotify version of `file-notify-rm-watch'
signals an error in case the given descriptor denotes a directory which
has been deleted in the meantime. If it denotes a file which has been
deleted, no error is signaled.
Here's a receipe:
(require 'filenotify)
(let* ((flags '(change))
(handler (lambda () nil))
(file (make-temp-file "foo"))
(file-watch (file-notify-add-watch file flags handler))
(dir (make-temp-file "bar" t))
(dir-watch (file-notify-add-watch dir flags handler)))
(delete-file file)
(delete-directory dir)
(file-notify-rm-watch file-watch) ;; works
(message "Removed file watch")
(file-notify-rm-watch dir-watch) ;; signals an error
(message "Removed directory watch"))
The documentation does not define any specific behavior for these
situation, so this is currently a gray area which makes it hard for
package developers to develop something which will work right accross
the different notification backends.
I don't have a strong opinion about what the right behavior would be but
at least it seems inconsistent that you get the error only with deleted
directories. I guess the best solution was if `file-notify-rm-watch'
never signaled an error (then the docs can stay as they are), and there
would be some `file-notify-valid-p' predicate which would test if a
given descriptor still denotes a valid file or directory. I guess the
latter has probably some function equivalent in the respective backend
APIs, and even if not, it can be implemented by inspecting
`file-notify-descriptors'.
In GNU Emacs 25.0.50.10 (x86_64-unknown-linux-gnu, GTK+ Version 3.16.6)
of 2015-09-08
Repository revision: 6cd64aaf1317bdd96f29fa2a7c3d49172e79bc37
Windowing system distributor 'The X.Org Foundation', version 11.0.11702000
System Description: Arch Linux
Configured using:
'configure 'CFLAGS=-g -ggdb3 -O1''
Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GCONF GSETTINGS
NOTIFY ACL GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11
Important settings:
value of $LC_MONETARY: de_DE.utf8
value of $LC_NUMERIC: de_DE.utf8
value of $LC_TIME: de_DE.utf8
value of $LANG: en_US.utf8
locale-coding-system: utf-8-unix
Major mode: Group
Minor modes in effect:
hl-line-mode: t
gnus-topic-mode: t
global-company-mode: t
shell-dirtrack-mode: t
global-aggressive-indent-mode: t
gnus-undo-mode: t
pdf-occur-global-minor-mode: t
recentf-mode: t
global-subword-mode: t
subword-mode: t
save-place-mode: t
savehist-mode: t
show-paren-mode: t
ivy-mode: t
minibuffer-depth-indicate-mode: t
electric-pair-mode: t
tooltip-mode: t
global-eldoc-mode: t
electric-indent-mode: t
mouse-wheel-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
buffer-read-only: t
column-number-mode: t
line-number-mode: t
transient-mark-mode: t
Recent messages:
20150908T081715.611> Reading active file via nndraft...
20150908T081715.611> Reading active file via nndraft...done
20150908T081715.612> Reading active file from archive+nnml+archive:sent-postings via nnml...
20150908T081715.612> Opening nnml server on archive+nnml+archive:sent-postings...
20150908T081715.613> Opening nnml server on archive+nnml+archive:sent-postings...done
20150908T081715.615> nnml: Reading incoming mail (no new mail)...done
20150908T081715.615> Reading active file from archive+nnml+archive:sent-postings via nnml...
20150908T081715.616> Reading active file from archive+nnml+archive:sent-postings via nnml...done
20150908T081715.616> Checking new news...done
Contacting host: debbugs.gnu.org:80
Load-path shadows:
~/Repos/el/auctex/lpath hides ~/Repos/el/gnus/lisp/lpath
~/Repos/el/highlight-symbol.el/highlight-symbol hides /home/horn/.emacs.d/elpa/highlight-symbol-20150816.628/highlight-symbol
~/Repos/el/gnus/lisp/md4 hides /home/horn/Repos/el/emacs/lisp/md4
~/Repos/el/gnus/lisp/color hides /home/horn/Repos/el/emacs/lisp/color
~/Repos/el/gnus/lisp/format-spec hides /home/horn/Repos/el/emacs/lisp/format-spec
~/Repos/el/gnus/lisp/password-cache hides /home/horn/Repos/el/emacs/lisp/password-cache
~/Repos/el/gnus/lisp/hex-util hides /home/horn/Repos/el/emacs/lisp/hex-util
~/Repos/el/gnus/lisp/dns-mode hides /home/horn/Repos/el/emacs/lisp/textmodes/dns-mode
~/Repos/el/gnus/lisp/dig hides /home/horn/Repos/el/emacs/lisp/net/dig
~/Repos/el/gnus/lisp/hmac-md5 hides /home/horn/Repos/el/emacs/lisp/net/hmac-md5
~/Repos/el/gnus/lisp/ntlm hides /home/horn/Repos/el/emacs/lisp/net/ntlm
~/Repos/el/gnus/lisp/hmac-def hides /home/horn/Repos/el/emacs/lisp/net/hmac-def
~/Repos/el/gnus/lisp/rfc2104 hides /home/horn/Repos/el/emacs/lisp/net/rfc2104
~/Repos/el/gnus/lisp/sasl-ntlm hides /home/horn/Repos/el/emacs/lisp/net/sasl-ntlm
~/Repos/el/gnus/lisp/sasl-cram hides /home/horn/Repos/el/emacs/lisp/net/sasl-cram
~/Repos/el/gnus/lisp/dns hides /home/horn/Repos/el/emacs/lisp/net/dns
~/Repos/el/gnus/lisp/sasl hides /home/horn/Repos/el/emacs/lisp/net/sasl
~/Repos/el/gnus/lisp/tls hides /home/horn/Repos/el/emacs/lisp/net/tls
~/Repos/el/gnus/lisp/sasl-scram-rfc hides /home/horn/Repos/el/emacs/lisp/net/sasl-scram-rfc
~/Repos/el/gnus/lisp/netrc hides /home/horn/Repos/el/emacs/lisp/net/netrc
~/Repos/el/gnus/lisp/sasl-digest hides /home/horn/Repos/el/emacs/lisp/net/sasl-digest
~/Repos/el/gnus/lisp/uudecode hides /home/horn/Repos/el/emacs/lisp/mail/uudecode
~/Repos/el/gnus/lisp/binhex hides /home/horn/Repos/el/emacs/lisp/mail/binhex
~/Repos/el/gnus/lisp/hashcash hides /home/horn/Repos/el/emacs/lisp/mail/hashcash
~/Repos/el/gnus/lisp/canlock hides /home/horn/Repos/el/emacs/lisp/gnus/canlock
~/Repos/el/gnus/lisp/nneething hides /home/horn/Repos/el/emacs/lisp/gnus/nneething
~/Repos/el/gnus/lisp/mm-encode hides /home/horn/Repos/el/emacs/lisp/gnus/mm-encode
~/Repos/el/gnus/lisp/mm-util hides /home/horn/Repos/el/emacs/lisp/gnus/mm-util
~/Repos/el/gnus/lisp/rfc2047 hides /home/horn/Repos/el/emacs/lisp/gnus/rfc2047
~/Repos/el/gnus/lisp/nnml hides /home/horn/Repos/el/emacs/lisp/gnus/nnml
~/Repos/el/gnus/lisp/gnus-cus hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-cus
~/Repos/el/gnus/lisp/gnus-range hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-range
~/Repos/el/gnus/lisp/gnus-int hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-int
~/Repos/el/gnus/lisp/gnus-cloud hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-cloud
~/Repos/el/gnus/lisp/spam-stat hides /home/horn/Repos/el/emacs/lisp/gnus/spam-stat
~/Repos/el/gnus/lisp/nnmh hides /home/horn/Repos/el/emacs/lisp/gnus/nnmh
~/Repos/el/gnus/lisp/gnus-mlspl hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-mlspl
~/Repos/el/gnus/lisp/deuglify hides /home/horn/Repos/el/emacs/lisp/gnus/deuglify
~/Repos/el/gnus/lisp/gnus-gravatar hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-gravatar
~/Repos/el/gnus/lisp/nngateway hides /home/horn/Repos/el/emacs/lisp/gnus/nngateway
~/Repos/el/gnus/lisp/ietf-drums hides /home/horn/Repos/el/emacs/lisp/gnus/ietf-drums
~/Repos/el/gnus/lisp/mail-parse hides /home/horn/Repos/el/emacs/lisp/gnus/mail-parse
~/Repos/el/gnus/lisp/gnus-salt hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-salt
~/Repos/el/gnus/lisp/nnimap hides /home/horn/Repos/el/emacs/lisp/gnus/nnimap
~/Repos/el/gnus/lisp/gnus-draft hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-draft
~/Repos/el/gnus/lisp/mail-source hides /home/horn/Repos/el/emacs/lisp/gnus/mail-source
~/Repos/el/gnus/lisp/messcompat hides /home/horn/Repos/el/emacs/lisp/gnus/messcompat
~/Repos/el/gnus/lisp/pop3 hides /home/horn/Repos/el/emacs/lisp/gnus/pop3
~/Repos/el/gnus/lisp/nnmaildir hides /home/horn/Repos/el/emacs/lisp/gnus/nnmaildir
~/Repos/el/gnus/lisp/nnheader hides /home/horn/Repos/el/emacs/lisp/gnus/nnheader
~/Repos/el/gnus/lisp/gnus-cite hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-cite
~/Repos/el/gnus/lisp/nndiary hides /home/horn/Repos/el/emacs/lisp/gnus/nndiary
~/Repos/el/gnus/lisp/gnus-diary hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-diary
~/Repos/el/gnus/lisp/nnfolder hides /home/horn/Repos/el/emacs/lisp/gnus/nnfolder
~/Repos/el/gnus/lisp/gnus-art hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-art
~/Repos/el/gnus/lisp/gnus-demon hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-demon
~/Repos/el/gnus/lisp/mml-sec hides /home/horn/Repos/el/emacs/lisp/gnus/mml-sec
~/Repos/el/gnus/lisp/nnir hides /home/horn/Repos/el/emacs/lisp/gnus/nnir
~/Repos/el/gnus/lisp/mm-partial hides /home/horn/Repos/el/emacs/lisp/gnus/mm-partial
~/Repos/el/gnus/lisp/gnus-registry hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-registry
~/Repos/el/gnus/lisp/gnus-icalendar hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-icalendar
~/Repos/el/gnus/lisp/compface hides /home/horn/Repos/el/emacs/lisp/gnus/compface
~/Repos/el/gnus/lisp/gnus-fun hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-fun
~/Repos/el/gnus/lisp/gnus-start hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-start
~/Repos/el/gnus/lisp/smiley hides /home/horn/Repos/el/emacs/lisp/gnus/smiley
~/Repos/el/gnus/lisp/gnus-picon hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-picon
~/Repos/el/gnus/lisp/spam-report hides /home/horn/Repos/el/emacs/lisp/gnus/spam-report
~/Repos/el/gnus/lisp/nntp hides /home/horn/Repos/el/emacs/lisp/gnus/nntp
~/Repos/el/gnus/lisp/nnnil hides /home/horn/Repos/el/emacs/lisp/gnus/nnnil
~/Repos/el/gnus/lisp/nndir hides /home/horn/Repos/el/emacs/lisp/gnus/nndir
~/Repos/el/gnus/lisp/gnus-srvr hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-srvr
~/Repos/el/gnus/lisp/smime hides /home/horn/Repos/el/emacs/lisp/gnus/smime
~/Repos/el/gnus/lisp/nnvirtual hides /home/horn/Repos/el/emacs/lisp/gnus/nnvirtual
~/Repos/el/gnus/lisp/gnus-notifications hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-notifications
~/Repos/el/gnus/lisp/nnspool hides /home/horn/Repos/el/emacs/lisp/gnus/nnspool
~/Repos/el/gnus/lisp/gnus-group hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-group
~/Repos/el/gnus/lisp/gnus-bcklg hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-bcklg
~/Repos/el/gnus/lisp/gnus-util hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-util
~/Repos/el/gnus/lisp/gnus-sieve hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-sieve
~/Repos/el/gnus/lisp/nndraft hides /home/horn/Repos/el/emacs/lisp/gnus/nndraft
~/Repos/el/gnus/lisp/nnagent hides /home/horn/Repos/el/emacs/lisp/gnus/nnagent
~/Repos/el/gnus/lisp/gnus-spec hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-spec
~/Repos/el/gnus/lisp/gnus-bookmark hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-bookmark
~/Repos/el/gnus/lisp/mml1991 hides /home/horn/Repos/el/emacs/lisp/gnus/mml1991
~/Repos/el/gnus/lisp/rfc2231 hides /home/horn/Repos/el/emacs/lisp/gnus/rfc2231
~/Repos/el/gnus/lisp/yenc hides /home/horn/Repos/el/emacs/lisp/gnus/yenc
~/Repos/el/gnus/lisp/gnus-undo hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-undo
~/Repos/el/gnus/lisp/ecomplete hides /home/horn/Repos/el/emacs/lisp/gnus/ecomplete
~/Repos/el/gnus/lisp/legacy-gnus-agent hides /home/horn/Repos/el/emacs/lisp/gnus/legacy-gnus-agent
~/Repos/el/gnus/lisp/utf7 hides /home/horn/Repos/el/emacs/lisp/gnus/utf7
~/Repos/el/gnus/lisp/rtree hides /home/horn/Repos/el/emacs/lisp/gnus/rtree
~/Repos/el/gnus/lisp/gnus-uu hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-uu
~/Repos/el/gnus/lisp/gnus-ml hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-ml
~/Repos/el/gnus/lisp/sieve hides /home/horn/Repos/el/emacs/lisp/gnus/sieve
~/Repos/el/gnus/lisp/gnus hides /home/horn/Repos/el/emacs/lisp/gnus/gnus
~/Repos/el/gnus/lisp/mml hides /home/horn/Repos/el/emacs/lisp/gnus/mml
~/Repos/el/gnus/lisp/message hides /home/horn/Repos/el/emacs/lisp/gnus/message
~/Repos/el/gnus/lisp/mml-smime hides /home/horn/Repos/el/emacs/lisp/gnus/mml-smime
~/Repos/el/gnus/lisp/gnus-eform hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-eform
~/Repos/el/gnus/lisp/gnus-agent hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-agent
~/Repos/el/gnus/lisp/gnus-logic hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-logic
~/Repos/el/gnus/lisp/mm-extern hides /home/horn/Repos/el/emacs/lisp/gnus/mm-extern
~/Repos/el/gnus/lisp/nndoc hides /home/horn/Repos/el/emacs/lisp/gnus/nndoc
~/Repos/el/gnus/lisp/sieve-manage hides /home/horn/Repos/el/emacs/lisp/gnus/sieve-manage
~/Repos/el/gnus/lisp/mm-decode hides /home/horn/Repos/el/emacs/lisp/gnus/mm-decode
~/Repos/el/gnus/lisp/starttls hides /home/horn/Repos/el/emacs/lisp/gnus/starttls
~/Repos/el/gnus/lisp/gnus-dired hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-dired
~/Repos/el/gnus/lisp/nnbabyl hides /home/horn/Repos/el/emacs/lisp/gnus/nnbabyl
~/Repos/el/gnus/lisp/nnmbox hides /home/horn/Repos/el/emacs/lisp/gnus/nnmbox
~/Repos/el/gnus/lisp/gnus-win hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-win
~/Repos/el/gnus/lisp/gnus-async hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-async
~/Repos/el/gnus/lisp/mm-url hides /home/horn/Repos/el/emacs/lisp/gnus/mm-url
~/Repos/el/gnus/lisp/gnus-html hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-html
~/Repos/el/gnus/lisp/gssapi hides /home/horn/Repos/el/emacs/lisp/gnus/gssapi
~/Repos/el/gnus/lisp/mml2015 hides /home/horn/Repos/el/emacs/lisp/gnus/mml2015
~/Repos/el/gnus/lisp/nnrss hides /home/horn/Repos/el/emacs/lisp/gnus/nnrss
~/Repos/el/gnus/lisp/gnus-mh hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-mh
~/Repos/el/gnus/lisp/gnus-sum hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-sum
~/Repos/el/gnus/lisp/nnweb hides /home/horn/Repos/el/emacs/lisp/gnus/nnweb
~/Repos/el/gnus/lisp/mail-prsvr hides /home/horn/Repos/el/emacs/lisp/gnus/mail-prsvr
~/Repos/el/gnus/lisp/nnmairix hides /home/horn/Repos/el/emacs/lisp/gnus/nnmairix
~/Repos/el/gnus/lisp/plstore hides /home/horn/Repos/el/emacs/lisp/gnus/plstore
~/Repos/el/gnus/lisp/rfc2045 hides /home/horn/Repos/el/emacs/lisp/gnus/rfc2045
~/Repos/el/gnus/lisp/gnus-msg hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-msg
~/Repos/el/gnus/lisp/spam-wash hides /home/horn/Repos/el/emacs/lisp/gnus/spam-wash
~/Repos/el/gnus/lisp/gnus-score hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-score
~/Repos/el/gnus/lisp/mm-uu hides /home/horn/Repos/el/emacs/lisp/gnus/mm-uu
~/Repos/el/gnus/lisp/spam hides /home/horn/Repos/el/emacs/lisp/gnus/spam
~/Repos/el/gnus/lisp/mm-view hides /home/horn/Repos/el/emacs/lisp/gnus/mm-view
~/Repos/el/gnus/lisp/sieve-mode hides /home/horn/Repos/el/emacs/lisp/gnus/sieve-mode
~/Repos/el/gnus/lisp/html2text hides /home/horn/Repos/el/emacs/lisp/gnus/html2text
~/Repos/el/gnus/lisp/gnus-ems hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-ems
~/Repos/el/gnus/lisp/registry hides /home/horn/Repos/el/emacs/lisp/gnus/registry
~/Repos/el/gnus/lisp/auth-source hides /home/horn/Repos/el/emacs/lisp/gnus/auth-source
~/Repos/el/gnus/lisp/gravatar hides /home/horn/Repos/el/emacs/lisp/gnus/gravatar
~/Repos/el/gnus/lisp/flow-fill hides /home/horn/Repos/el/emacs/lisp/gnus/flow-fill
~/Repos/el/gnus/lisp/gmm-utils hides /home/horn/Repos/el/emacs/lisp/gnus/gmm-utils
~/Repos/el/gnus/lisp/mailcap hides /home/horn/Repos/el/emacs/lisp/gnus/mailcap
~/Repos/el/gnus/lisp/gnus-delay hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-delay
~/Repos/el/gnus/lisp/mm-bodies hides /home/horn/Repos/el/emacs/lisp/gnus/mm-bodies
~/Repos/el/gnus/lisp/mm-archive hides /home/horn/Repos/el/emacs/lisp/gnus/mm-archive
~/Repos/el/gnus/lisp/rfc1843 hides /home/horn/Repos/el/emacs/lisp/gnus/rfc1843
~/Repos/el/gnus/lisp/gnus-kill hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-kill
~/Repos/el/gnus/lisp/qp hides /home/horn/Repos/el/emacs/lisp/gnus/qp
~/Repos/el/gnus/lisp/score-mode hides /home/horn/Repos/el/emacs/lisp/gnus/score-mode
~/Repos/el/gnus/lisp/gnus-topic hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-topic
~/Repos/el/gnus/lisp/gnus-cache hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-cache
~/Repos/el/gnus/lisp/nnmail hides /home/horn/Repos/el/emacs/lisp/gnus/nnmail
~/Repos/el/gnus/lisp/gnus-vm hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-vm
~/Repos/el/gnus/lisp/gnus-sync hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-sync
~/Repos/el/gnus/lisp/nnoo hides /home/horn/Repos/el/emacs/lisp/gnus/nnoo
~/Repos/el/gnus/lisp/nnregistry hides /home/horn/Repos/el/emacs/lisp/gnus/nnregistry
~/Repos/el/gnus/lisp/gnus-dup hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-dup
~/Repos/el/gnus/lisp/parse-time hides /home/horn/Repos/el/emacs/lisp/calendar/parse-time
~/Repos/el/gnus/lisp/time-date hides /home/horn/Repos/el/emacs/lisp/calendar/time-date
Features:
(shadow sort gnus-cite emacsbug sendmail mm-archive crm debbugs-gnu
add-log debbugs soap-client url-http url-auth url-gw warnings hl-line
nndraft nnmh rot13 utf-7 gnutls network-stream nsm starttls nnml nnnil
gnus-agent gnus-srvr gnus-score score-mode nnvirtual gnus-cache
gnus-demon nntp spam spam-stat gnus-uu yenc gnus-msg gnus-gravatar
mail-extr gravatar gnus-topic nnir gnus-registry registry eieio-compat
eieio-base th-private smex ido seq filenotify debug eieio-opt speedbar
sb-image ezimage dframe colir color company-files company-oddmuse
company-keywords company-etags company-gtags company-dabbrev-code
company-dabbrev company-capf company-cmake company-xcode company-clang
company-semantic company-eclim company-template company-css company-nxml
company-bbdb company stratego-mode greql-mode tg-mode generic
preview-latex tex-site auto-loads cider tramp-sh cider-debug
cider-browse-ns cider-inspector cider-mode cider-repl cider-eldoc
cider-interaction spinner arc-mode archive-mode cider-overlays cider-doc
org-table org org-macro org-footnote org-pcomplete org-list org-faces
org-entities org-version ob-emacs-lisp ob ob-tangle ob-ref ob-lob
ob-table ob-exp org-src ob-keys ob-comint ob-core ob-eval org-compat
org-macs org-loaddefs cal-menu calendar cal-loaddefs cider-test
cider-stacktrace cider-client cider-util nrepl-client tramp tramp-compat
tramp-loaddefs trampver shell pcomplete queue ewoc etags xref project
dash clojure-mode paredit aggressive-indent epa-file epa epg rdictcc
google-contacts-message google-contacts xml url-cache google-oauth
google-contacts-gnus gnus-art mm-uu mml2015 mm-view mml-smime smime dig
gnus-sum gnus-group gnus-undo gnus-start gnus-cloud nnimap nnmail
mail-source tls utf7 netrc nnoo parse-time gnus-spec gnus-int gnus-range
gnus-win gnus gnus-ems gnus-compat url url-proxy url-privacy url-expand
url-methods url-history url-cookie url-domsuf url-util url-parse
auth-source password-cache url-vars mailcap nnheader gnus-util dired-x
em-term term ehelp esh-opt esh-ext esh-util highlight-symbol thingatpt
boxquote rect ecomplete message rfc822 mml mml-sec mm-decode mm-bodies
mm-encode mail-parse rfc2231 rfc2047 rfc2045 ietf-drums mm-util help-fns
mail-prsvr mailabbrev mail-utils gmm-utils mailheader server yasnippet
disp-table noutline outline pdf-occur ibuf-ext ibuffer tablist
tablist-filter semantic/wisent/comp semantic/wisent
semantic/wisent/wisent semantic/util-modes semantic/util semantic
semantic/tag semantic/lex semantic/fw eieio byte-opt bytecomp
byte-compile cconv eieio-core mode-local find-func cedet dired
pdf-isearch let-alist pdf-misc imenu pdf-tools compile comint ansi-color
cus-edit cus-start cus-load pdf-view bookmark pp jka-compr pdf-cache
pdf-info tq pdf-util format-spec image-mode browse-kill-ring derived
recentf tree-widget wid-edit highlight-parentheses cl iedit iedit-lib
cl-extra help-mode hydra lv counsel swiper cap-words superword subword
saveplace savehist paren ivy delsel icomplete mb-depth ace-window
easy-mmode cl-macs gv avy ring smart-mode-line-respectful-theme
smart-mode-line-light-theme cl-seq smart-mode-line rich-minority rx bs
elec-pair edmacro kmacro cl-loaddefs cl-lib gnus-load subr-x pcase
tsdh-light-theme finder-inf memory-usage-autoloads advice info package
easymenu epg-config time-date mule-util tooltip eldoc electric uniquify
ediff-hook vc-hooks lisp-float-type mwheel x-win term/common-win x-dnd
tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment
elisp-mode lisp-mode prog-mode register page menu-bar rfn-eshadow timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
frame 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 charscript
case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote dbusbind inotify
dynamic-setting system-font-setting font-render-setting move-toolbar gtk
x-toolkit x multi-tty make-network-process emacs)
Memory information:
((conses 16 639836 122215)
(symbols 48 53035 0)
(miscs 40 301 344)
(strings 32 164700 67149)
(string-bytes 1 5718922)
(vectors 16 50490)
(vector-slots 8 1133948 17525)
(floats 8 961 537)
(intervals 56 5318 0)
(buffers 976 29)
(heap 1024 83217 3736))
^ permalink raw reply [flat|nested] 36+ messages in thread* bug#21432: 25.0.50; file-notify-rm-watch (inotify) errors if watched dir is deleted
2015-09-08 6:36 bug#21432: 25.0.50; file-notify-rm-watch (inotify) errors if watched dir is deleted Tassilo Horn
@ 2015-09-08 7:47 ` Michael Albinus
2015-09-08 8:11 ` Tassilo Horn
2015-09-08 15:51 ` Eli Zaretskii
2015-09-08 15:49 ` Eli Zaretskii
2015-09-20 17:23 ` Michael Albinus
2 siblings, 2 replies; 36+ messages in thread
From: Michael Albinus @ 2015-09-08 7:47 UTC (permalink / raw)
To: Tassilo Horn; +Cc: 21432
Tassilo Horn <tsdh@gnu.org> writes:
Hi Tassilo,
> I don't have a strong opinion about what the right behavior would be but
> at least it seems inconsistent that you get the error only with deleted
> directories. I guess the best solution was if `file-notify-rm-watch'
> never signaled an error (then the docs can stay as they are), and there
> would be some `file-notify-valid-p' predicate which would test if a
> given descriptor still denotes a valid file or directory. I guess the
> latter has probably some function equivalent in the respective backend
> APIs, and even if not, it can be implemented by inspecting
> `file-notify-descriptors'.
`file-notify-rm-watch' is just a cleanup function, it's not worth to add
some error handling. I will wrap the call of the native handlers by
catching `file-notify-error'. Alternatively, `inotify-rm-watch' could be
adapted not to raise an error in this case.
`file-notify-valid-p' is a nice idea; I will see how I could add it. At
least for the w32 case I would need some help from Eli, in order to
see whether the native library supports such a check.
Best regards, Michael.
^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#21432: 25.0.50; file-notify-rm-watch (inotify) errors if watched dir is deleted
2015-09-08 7:47 ` Michael Albinus
@ 2015-09-08 8:11 ` Tassilo Horn
2015-09-08 15:51 ` Eli Zaretskii
1 sibling, 0 replies; 36+ messages in thread
From: Tassilo Horn @ 2015-09-08 8:11 UTC (permalink / raw)
To: Michael Albinus; +Cc: 21432
Michael Albinus <michael.albinus@gmx.de> writes:
Hi Michael,
>> I don't have a strong opinion about what the right behavior would be
>> but at least it seems inconsistent that you get the error only with
>> deleted directories. I guess the best solution was if
>> `file-notify-rm-watch' never signaled an error (then the docs can
>> stay as they are), and there would be some `file-notify-valid-p'
>> predicate which would test if a given descriptor still denotes a
>> valid file or directory. I guess the latter has probably some
>> function equivalent in the respective backend APIs, and even if not,
>> it can be implemented by inspecting `file-notify-descriptors'.
>
> `file-notify-rm-watch' is just a cleanup function, it's not worth to
> add some error handling. I will wrap the call of the native handlers
> by catching `file-notify-error'. Alternatively, `inotify-rm-watch'
> could be adapted not to raise an error in this case.
Great, thanks.
> `file-notify-valid-p' is a nice idea; I will see how I could add it.
> At least for the w32 case I would need some help from Eli, in order to
> see whether the native library supports such a check.
I just wanted to write that such a predicate would not strictly be
needed because if one really cares, she could determine when a
descriptor becomes invalid by handling all delete notifications. But
that's not really true because when watching a directory, you only
receive events for the contents of the directory, not for the directory
itself. That is, if you want to receive notifications about changes to
your watched directory itself, then you need to watch also its parent
directory.
Bye,
Tassilo
^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#21432: 25.0.50; file-notify-rm-watch (inotify) errors if watched dir is deleted
2015-09-08 7:47 ` Michael Albinus
2015-09-08 8:11 ` Tassilo Horn
@ 2015-09-08 15:51 ` Eli Zaretskii
1 sibling, 0 replies; 36+ messages in thread
From: Eli Zaretskii @ 2015-09-08 15:51 UTC (permalink / raw)
To: Michael Albinus; +Cc: 21432, tsdh
> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: 21432@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>
> Date: Tue, 08 Sep 2015 09:47:07 +0200
>
> `file-notify-valid-p' is a nice idea; I will see how I could add it. At
> least for the w32 case I would need some help from Eli, in order to
> see whether the native library supports such a check.
What happens on w32 when a watched directory is deleted is that the
thread which watches the changes exits (with an abnormal status), but
the object created to watch the changes still exists, and can be
easily tested for being "invalid".
So if you want to implement file-notify-valid-p, go ahead; the w32
side will be almost trivial.
^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#21432: 25.0.50; file-notify-rm-watch (inotify) errors if watched dir is deleted
2015-09-08 6:36 bug#21432: 25.0.50; file-notify-rm-watch (inotify) errors if watched dir is deleted Tassilo Horn
2015-09-08 7:47 ` Michael Albinus
@ 2015-09-08 15:49 ` Eli Zaretskii
2015-09-08 16:01 ` Michael Albinus
2015-09-20 17:23 ` Michael Albinus
2 siblings, 1 reply; 36+ messages in thread
From: Eli Zaretskii @ 2015-09-08 15:49 UTC (permalink / raw)
To: Tassilo Horn; +Cc: 21432
> From: Tassilo Horn <tsdh@gnu.org>
> Date: Tue, 08 Sep 2015 08:36:06 +0200
>
> Right now, (at least) the inotify version of `file-notify-rm-watch'
> signals an error in case the given descriptor denotes a directory which
> has been deleted in the meantime. If it denotes a file which has been
> deleted, no error is signaled.
>
> Here's a receipe:
>
> (require 'filenotify)
> (let* ((flags '(change))
> (handler (lambda () nil))
> (file (make-temp-file "foo"))
> (file-watch (file-notify-add-watch file flags handler))
> (dir (make-temp-file "bar" t))
> (dir-watch (file-notify-add-watch dir flags handler)))
> (delete-file file)
> (delete-directory dir)
> (file-notify-rm-watch file-watch) ;; works
> (message "Removed file watch")
> (file-notify-rm-watch dir-watch) ;; signals an error
> (message "Removed directory watch"))
>
> The documentation does not define any specific behavior for these
> situation, so this is currently a gray area which makes it hard for
> package developers to develop something which will work right accross
> the different notification backends.
>
> I don't have a strong opinion about what the right behavior would be but
> at least it seems inconsistent that you get the error only with deleted
> directories.
There is no "right" behavior. What you see is what the back-end
reports to us. If we want Emacs to be smarter, it's the job of the
application, not of filenotify.el.
^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#21432: 25.0.50; file-notify-rm-watch (inotify) errors if watched dir is deleted
2015-09-08 15:49 ` Eli Zaretskii
@ 2015-09-08 16:01 ` Michael Albinus
2015-09-12 10:18 ` Michael Albinus
0 siblings, 1 reply; 36+ messages in thread
From: Michael Albinus @ 2015-09-08 16:01 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 21432, Tassilo Horn
Eli Zaretskii <eliz@gnu.org> writes:
>> I don't have a strong opinion about what the right behavior would be but
>> at least it seems inconsistent that you get the error only with deleted
>> directories.
>
> There is no "right" behavior. What you see is what the back-end
> reports to us. If we want Emacs to be smarter, it's the job of the
> application, not of filenotify.el.
Well, filenotify.el shall abstract from the different back-ends. Being
quite when the native rm-watch fails seems to be appropriate.
Best regards, Michael.
^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#21432: 25.0.50; file-notify-rm-watch (inotify) errors if watched dir is deleted
2015-09-08 16:01 ` Michael Albinus
@ 2015-09-12 10:18 ` Michael Albinus
2015-09-12 15:11 ` Eli Zaretskii
0 siblings, 1 reply; 36+ messages in thread
From: Michael Albinus @ 2015-09-12 10:18 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 21432, Tassilo Horn
Michael Albinus <michael.albinus@gmx.de> writes:
> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> I don't have a strong opinion about what the right behavior would be but
>>> at least it seems inconsistent that you get the error only with deleted
>>> directories.
>>
>> There is no "right" behavior. What you see is what the back-end
>> reports to us. If we want Emacs to be smarter, it's the job of the
>> application, not of filenotify.el.
>
> Well, filenotify.el shall abstract from the different back-ends. Being
> quiet when the native rm-watch fails seems to be appropriate.
I've checked, all three Emacs libraries inotify, gfilenotify and
w32notify return an error when *-rm-watch detects a problem.
`file-notify-rm-watch' could propagate this error. The manual
shall be extended then.
At least inotify removes a watch internally, when it detects that the
file/directoy to be watched does not exist any longer. gfilenotify and
w32notify do not seem to to care.
Shall we unify this behaviour? I'm not in favor of the inotify
behaviour, the libraries shall raise a final signal instead that the
watch is stopped. filenotify shall propagate this then, for example as
`stopped' event or something like this.
Last point, I've observed that inotify and gfilenotify raise a
`file-notify-error' when needed. w32notify raises a `file-error'.
Shouldn't it raise also `file-notify-error'?.
Best regards, Michael.
^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#21432: 25.0.50; file-notify-rm-watch (inotify) errors if watched dir is deleted
2015-09-12 10:18 ` Michael Albinus
@ 2015-09-12 15:11 ` Eli Zaretskii
2015-09-12 18:09 ` Michael Albinus
2015-09-14 7:35 ` Eli Zaretskii
0 siblings, 2 replies; 36+ messages in thread
From: Eli Zaretskii @ 2015-09-12 15:11 UTC (permalink / raw)
To: Michael Albinus; +Cc: 21432, tsdh
> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: Tassilo Horn <tsdh@gnu.org>, 21432@debbugs.gnu.org
> Date: Sat, 12 Sep 2015 12:18:01 +0200
>
> Michael Albinus <michael.albinus@gmx.de> writes:
>
> > Eli Zaretskii <eliz@gnu.org> writes:
> >
> >>> I don't have a strong opinion about what the right behavior would be but
> >>> at least it seems inconsistent that you get the error only with deleted
> >>> directories.
> >>
> >> There is no "right" behavior. What you see is what the back-end
> >> reports to us. If we want Emacs to be smarter, it's the job of the
> >> application, not of filenotify.el.
> >
> > Well, filenotify.el shall abstract from the different back-ends. Being
> > quiet when the native rm-watch fails seems to be appropriate.
>
> I've checked, all three Emacs libraries inotify, gfilenotify and
> w32notify return an error when *-rm-watch detects a problem.
> `file-notify-rm-watch' could propagate this error. The manual
> shall be extended then.
But the issue comes up before you remove the watch. You have a watch
that is in fact inoperable, but the application might not know about
that, or get hit by a signal out of nowhere.
So I think having a validation function is a good idea.
> At least inotify removes a watch internally, when it detects that the
> file/directoy to be watched does not exist any longer.
That's a bug, IMO: it shouldn't.
> gfilenotify and w32notify do not seem to to care.
In w32notify, I did that on purpose: it's not the business of the tail
to wag the dog. Low-level functions has no business calling
higher-level APIs on their own.
> Shall we unify this behaviour? I'm not in favor of the inotify
> behaviour, the libraries shall raise a final signal instead that the
> watch is stopped. filenotify shall propagate this then, for example as
> `stopped' event or something like this.
I don't think you can easily raise a signal. I think we should
provide a validate function for the applications to use.
> Last point, I've observed that inotify and gfilenotify raise a
> `file-notify-error' when needed. w32notify raises a `file-error'.
> Shouldn't it raise also `file-notify-error'?.
Yes, it should. ('file-notify-error' didn't exist when I developed
w32notify.c.)
^ permalink raw reply [flat|nested] 36+ messages in thread* bug#21432: 25.0.50; file-notify-rm-watch (inotify) errors if watched dir is deleted
2015-09-12 15:11 ` Eli Zaretskii
@ 2015-09-12 18:09 ` Michael Albinus
2015-09-13 19:23 ` Michael Albinus
2015-09-14 7:35 ` Eli Zaretskii
1 sibling, 1 reply; 36+ messages in thread
From: Michael Albinus @ 2015-09-12 18:09 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 21432, tsdh
Eli Zaretskii <eliz@gnu.org> writes:
>> I've checked, all three Emacs libraries inotify, gfilenotify and
>> w32notify return an error when *-rm-watch detects a problem.
>> `file-notify-rm-watch' could propagate this error. The manual
>> shall be extended then.
>
> But the issue comes up before you remove the watch. You have a watch
> that is in fact inoperable, but the application might not know about
> that, or get hit by a signal out of nowhere.
>
> So I think having a validation function is a good idea.
Yes. I've started to write a prototype for inotify.c, will show when it
works (slow progress, you know :-( )
>> At least inotify removes a watch internally, when it detects that the
>> file/directoy to be watched does not exist any longer.
>
> That's a bug, IMO: it shouldn't.
I tend to agree. Will check further with inotify.c, but likely we should
discard this "feature".
>> Shall we unify this behaviour? I'm not in favor of the inotify
>> behaviour, the libraries shall raise a final signal instead that the
>> watch is stopped. filenotify shall propagate this then, for example as
>> `stopped' event or something like this.
>
> I don't think you can easily raise a signal. I think we should
> provide a validate function for the applications to use.
At least for inotify, it is built-in. It sends the `ignored' signal when
the directory or file being watch disappears, due to a delete, rename, or
unmount, whatever:
--8<---------------cut here---------------start------------->8---
(progn
(trace-function 'file-notify-handle-event)
(write-region "any text" nil "/tmp/xxx")
(inotify-add-watch "/tmp/xxx" 'all-events 'ignore)
(delete-file "/tmp/xxx"))
======================================================================
1 -> (file-notify-handle-event (file-notify (1 (attrib) nil 0) ignore))
1 <- file-notify-handle-event: nil
======================================================================
1 -> (file-notify-handle-event (file-notify (1 (delete-self) nil 0) ignore))
1 <- file-notify-handle-event: nil
======================================================================
1 -> (file-notify-handle-event (file-notify (1 (ignored) nil 0) ignore))
1 <- file-notify-handle-event: nil
--8<---------------cut here---------------end--------------->8---
For gfilenotify it isn't such simple, unfortunately.
Best regards, Michael.
^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#21432: 25.0.50; file-notify-rm-watch (inotify) errors if watched dir is deleted
2015-09-12 18:09 ` Michael Albinus
@ 2015-09-13 19:23 ` Michael Albinus
2015-09-14 6:08 ` Tassilo Horn
0 siblings, 1 reply; 36+ messages in thread
From: Michael Albinus @ 2015-09-13 19:23 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 21432, tsdh
Michael Albinus <michael.albinus@gmx.de> writes:
>> So I think having a validation function is a good idea.
>
> Yes. I've started to write a prototype for inotify.c, will show when it
> works (slow progress, you know :-( )
I've committed a patch to the trunk, adding `file-notify-valid-p' and
its native implementations in inotify.c and tramp.el. Comments welcome.
I know, documentation in the elisp manual is missing. I'll add it later,
and also the native implementation in gfilenotify.c.
Test cases, anywhere?
Best regards, Michael.
^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#21432: 25.0.50; file-notify-rm-watch (inotify) errors if watched dir is deleted
2015-09-13 19:23 ` Michael Albinus
@ 2015-09-14 6:08 ` Tassilo Horn
2015-09-14 7:08 ` Eli Zaretskii
0 siblings, 1 reply; 36+ messages in thread
From: Tassilo Horn @ 2015-09-14 6:08 UTC (permalink / raw)
To: Michael Albinus; +Cc: 21432
Michael Albinus <michael.albinus@gmx.de> writes:
Hi Michael,
>>> So I think having a validation function is a good idea.
>>
>> Yes. I've started to write a prototype for inotify.c, will show when
>> it works (slow progress, you know :-( )
>
> I've committed a patch to the trunk, adding `file-notify-valid-p' and
> its native implementations in inotify.c and tramp.el. Comments
> welcome.
>
> I know, documentation in the elisp manual is missing. I'll add it
> later, and also the native implementation in gfilenotify.c.
>
> Test cases, anywhere?
I've added two tests, one for plain files and one for directories. They
are "green" right now but I think they should not.
What seems wrong to me is that the descriptors stay valid even when the
watched file or directory is deleted. For files this might be ok
(though maybe inotify-specific) because when I create a new file with
the same name, the watch will trigger.
However, the current hehavior is certainly wrong for directories. When
I deleted the watched directory, the descriptor is still valid, but
calling file-notify-rm-watch on it signals an error.
Bye,
Tassilo
^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#21432: 25.0.50; file-notify-rm-watch (inotify) errors if watched dir is deleted
2015-09-14 6:08 ` Tassilo Horn
@ 2015-09-14 7:08 ` Eli Zaretskii
2015-09-14 7:40 ` Tassilo Horn
0 siblings, 1 reply; 36+ messages in thread
From: Eli Zaretskii @ 2015-09-14 7:08 UTC (permalink / raw)
To: Tassilo Horn; +Cc: michael.albinus, 21432
> From: Tassilo Horn <tsdh@gnu.org>
> Cc: Eli Zaretskii <eliz@gnu.org>, 21432@debbugs.gnu.org
> Date: Mon, 14 Sep 2015 08:08:20 +0200
>
> Michael Albinus <michael.albinus@gmx.de> writes:
>
> Hi Michael,
>
> >>> So I think having a validation function is a good idea.
> >>
> >> Yes. I've started to write a prototype for inotify.c, will show when
> >> it works (slow progress, you know :-( )
> >
> > I've committed a patch to the trunk, adding `file-notify-valid-p' and
> > its native implementations in inotify.c and tramp.el. Comments
> > welcome.
I've added a w32 implementation in w32notify.c.
> I've added two tests, one for plain files and one for directories. They
> are "green" right now but I think they should not.
I think you are testing this incorrectly.
> What seems wrong to me is that the descriptors stay valid even when the
> watched file or directory is deleted. For files this might be ok
> (though maybe inotify-specific) because when I create a new file with
> the same name, the watch will trigger.
>
> However, the current hehavior is certainly wrong for directories. When
> I deleted the watched directory, the descriptor is still valid, but
> calling file-notify-rm-watch on it signals an error.
AFAIR, filenotify.el watches the parent directory of the
file/directory you asked it to watch. So to see the invalid-p method
in action you need to remove the parent, not the directory itself.
^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#21432: 25.0.50; file-notify-rm-watch (inotify) errors if watched dir is deleted
2015-09-14 7:08 ` Eli Zaretskii
@ 2015-09-14 7:40 ` Tassilo Horn
2015-09-14 7:56 ` Tassilo Horn
0 siblings, 1 reply; 36+ messages in thread
From: Tassilo Horn @ 2015-09-14 7:40 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: michael.albinus, 21432
Eli Zaretskii <eliz@gnu.org> writes:
>> What seems wrong to me is that the descriptors stay valid even when
>> the watched file or directory is deleted. For files this might be ok
>> (though maybe inotify-specific) because when I create a new file with
>> the same name, the watch will trigger.
>>
>> However, the current hehavior is certainly wrong for directories.
>> When I deleted the watched directory, the descriptor is still valid,
>> but calling file-notify-rm-watch on it signals an error.
>
> AFAIR, filenotify.el watches the parent directory of the
> file/directory you asked it to watch. So to see the invalid-p method
> in action you need to remove the parent, not the directory itself.
Ah, I see. I'll adapt the tests accordingly.
Bye,
Tassilo
^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#21432: 25.0.50; file-notify-rm-watch (inotify) errors if watched dir is deleted
2015-09-14 7:40 ` Tassilo Horn
@ 2015-09-14 7:56 ` Tassilo Horn
2015-09-14 13:22 ` Eli Zaretskii
0 siblings, 1 reply; 36+ messages in thread
From: Tassilo Horn @ 2015-09-14 7:56 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: michael.albinus, 21432
Tassilo Horn <tsdh@gnu.org> writes:
>>> What seems wrong to me is that the descriptors stay valid even when
>>> the watched file or directory is deleted. For files this might be
>>> ok (though maybe inotify-specific) because when I create a new file
>>> with the same name, the watch will trigger.
>>>
>>> However, the current hehavior is certainly wrong for directories.
>>> When I deleted the watched directory, the descriptor is still valid,
>>> but calling file-notify-rm-watch on it signals an error.
>>
>> AFAIR, filenotify.el watches the parent directory of the
>> file/directory you asked it to watch. So to see the invalid-p method
>> in action you need to remove the parent, not the directory itself.
>
> Ah, I see. I'll adapt the tests accordingly.
Done, however the descriptors still don't become invalid when deleting
the parent directory of the watched file or directory. I guess, that's
a problem in the inotify and TRAMP implementations then.
Bye,
Tassilo
^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#21432: 25.0.50; file-notify-rm-watch (inotify) errors if watched dir is deleted
2015-09-14 7:56 ` Tassilo Horn
@ 2015-09-14 13:22 ` Eli Zaretskii
2015-09-14 20:23 ` Michael Albinus
2015-09-15 5:53 ` Tassilo Horn
0 siblings, 2 replies; 36+ messages in thread
From: Eli Zaretskii @ 2015-09-14 13:22 UTC (permalink / raw)
To: Tassilo Horn; +Cc: michael.albinus, 21432
> From: Tassilo Horn <tsdh@gnu.org>
> Cc: michael.albinus@gmx.de, 21432@debbugs.gnu.org
> Date: Mon, 14 Sep 2015 09:56:12 +0200
>
> >> AFAIR, filenotify.el watches the parent directory of the
> >> file/directory you asked it to watch. So to see the invalid-p method
> >> in action you need to remove the parent, not the directory itself.
> >
> > Ah, I see. I'll adapt the tests accordingly.
>
> Done, however the descriptors still don't become invalid when deleting
> the parent directory of the watched file or directory. I guess, that's
> a problem in the inotify and TRAMP implementations then.
No, I think it's a problem with our mental model of what happens. The
file notifications use the Emacs event loop, and Emacs won't check for
events until it's idle. So calling file-notify-valid-p as part of the
test ends up doing that _before_ the directory deletion notification
is read by Emacs and invalidates the watch. I actually see the
message saying the watch is valid before the notification comes in and
its message is inserted into *Messages*.
The following simple test case works with w32notify:
(setq mydir "/tmp/x")
(make-directory mydir t)
(setq myfile "/tmp/x/y")
(write-region "foo\n" nil myfile)
(setq w (w32notify-add-watch mydir '(file-name attributes size last-write-time)
(lambda (event) (message "%s" event))))
(message "valid: %s" (w32notify-valid-p w))
(delete-directory mydir t)
(run-with-idle-timer 1 nil
(lambda ()
(message "valid: %s" (w32notify-valid-p w))))
When I run the above snippet with eval-region, I see these messages in
*Messages*:
Wrote d:/tmp/x/y
valid: t
(100161480 modified y)
(100161480 removed y)
valid: nil
Try something similar with inotify and see if you see the same basic
issue. If you do, I trust you will think of a way to modify the tests
so that validation does do its thing.
^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#21432: 25.0.50; file-notify-rm-watch (inotify) errors if watched dir is deleted
2015-09-14 13:22 ` Eli Zaretskii
@ 2015-09-14 20:23 ` Michael Albinus
2015-09-15 7:38 ` Eli Zaretskii
2015-09-15 5:53 ` Tassilo Horn
1 sibling, 1 reply; 36+ messages in thread
From: Michael Albinus @ 2015-09-14 20:23 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 21432, Tassilo Horn
Eli Zaretskii <eliz@gnu.org> writes:
> No, I think it's a problem with our mental model of what happens. The
> file notifications use the Emacs event loop, and Emacs won't check for
> events until it's idle. So calling file-notify-valid-p as part of the
> test ends up doing that _before_ the directory deletion notification
> is read by Emacs and invalidates the watch. I actually see the
> message saying the watch is valid before the notification comes in and
> its message is inserted into *Messages*.
>
> Try something similar with inotify and see if you see the same basic
> issue. If you do, I trust you will think of a way to modify the tests
> so that validation does do its thing.
I've adapted `file-notify-test04-file-validity' and
`file-notify-test05-dir-validity', and they pass the tests now for the
inotify case. Hopefully, it is the same for w32notify.
Implementation for gfilenotify and Tramp will follow.
While being there, I have made also `file-notify-rm-watch' more robust
by ignoring all `file-notify-error's. This was the initial trigger for
bug#21432.
Best regards, Michael.
^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#21432: 25.0.50; file-notify-rm-watch (inotify) errors if watched dir is deleted
2015-09-14 20:23 ` Michael Albinus
@ 2015-09-15 7:38 ` Eli Zaretskii
2015-09-15 8:00 ` Michael Albinus
0 siblings, 1 reply; 36+ messages in thread
From: Eli Zaretskii @ 2015-09-15 7:38 UTC (permalink / raw)
To: Michael Albinus; +Cc: 21432, tsdh
> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: Tassilo Horn <tsdh@gnu.org>, 21432@debbugs.gnu.org
> Date: Mon, 14 Sep 2015 22:23:36 +0200
>
> I've adapted `file-notify-test04-file-validity' and
> `file-notify-test05-dir-validity', and they pass the tests now for the
> inotify case. Hopefully, it is the same for w32notify.
No, it fails:
Test file-notify-test04-file-validity condition:
(ert-test-failed
((should
(equal '...
(mapcar ... events)))
:form
(equal
(created changed deleted)
nil)
:value nil :explanation
(different-types
(created changed deleted)
nil)))
FAILED 9/12 file-notify-test04-file-validity
I guess the file-notify--test-with-events macro doesn't allow events
to come in on w32, but I have no idea how to debug this.
Moreover, file-notify-test05-dir-validity also fails:
Test file-notify-test05-dir-validity condition:
(ert-test-failed
((should-not
(file-notify-valid-p file-notify--test-desc))
:form
(file-notify-valid-p 91670672)
:value t))
FAILED 11/12 file-notify-test05-dir-validity
The latter could be because of the batch mode (it passes when I invoke
it interactively). But the former fails in interactive session as
well, so it's a real problem. Suggestions for debugging it are
welcome.
^ permalink raw reply [flat|nested] 36+ messages in thread* bug#21432: 25.0.50; file-notify-rm-watch (inotify) errors if watched dir is deleted
2015-09-15 7:38 ` Eli Zaretskii
@ 2015-09-15 8:00 ` Michael Albinus
2015-09-15 8:22 ` Eli Zaretskii
0 siblings, 1 reply; 36+ messages in thread
From: Michael Albinus @ 2015-09-15 8:00 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 21432, tsdh
Eli Zaretskii <eliz@gnu.org> writes:
>> I've adapted `file-notify-test04-file-validity' and
>> `file-notify-test05-dir-validity', and they pass the tests now for the
>> inotify case. Hopefully, it is the same for w32notify.
>
> No, it fails:
>
> Test file-notify-test04-file-validity condition:
> (ert-test-failed
> ((should
> (equal '...
> (mapcar ... events)))
> :form
> (equal
> (created changed deleted)
> nil)
> :value nil :explanation
> (different-types
> (created changed deleted)
> nil)))
> FAILED 9/12 file-notify-test04-file-validity
>
> I guess the file-notify--test-with-events macro doesn't allow events
> to come in on w32, but I have no idea how to debug this.
After loading file-notify-tests.el, trace-function for
file-notify-handle-event, file-notify-callback,
file-notify--test-event-handler. Run only file-notify-test04-file-validity.
Show the trace buffer.
Best regards, Michael.
^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#21432: 25.0.50; file-notify-rm-watch (inotify) errors if watched dir is deleted
2015-09-15 8:00 ` Michael Albinus
@ 2015-09-15 8:22 ` Eli Zaretskii
2015-09-15 11:54 ` Michael Albinus
0 siblings, 1 reply; 36+ messages in thread
From: Eli Zaretskii @ 2015-09-15 8:22 UTC (permalink / raw)
To: Michael Albinus; +Cc: 21432, tsdh
> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: tsdh@gnu.org, 21432@debbugs.gnu.org
> Date: Tue, 15 Sep 2015 10:00:10 +0200
>
> > I guess the file-notify--test-with-events macro doesn't allow events
> > to come in on w32, but I have no idea how to debug this.
>
> After loading file-notify-tests.el, trace-function for
> file-notify-handle-event, file-notify-callback,
> file-notify--test-event-handler. Run only file-notify-test04-file-validity.
> Show the trace buffer.
Here:
======================================================================
1 -> (file-notify-handle-event (file-notify (100272320 added ".#-emacsa05420") file-notify-callback))
| 2 -> (file-notify-callback (100272320 added ".#-emacsa05420"))
| 2 <- file-notify-callback: nil
1 <- file-notify-handle-event: nil
======================================================================
1 -> (file-notify-handle-event (file-notify (100272320 modified ".#-emacsa05420") file-notify-callback))
| 2 -> (file-notify-callback (100272320 modified ".#-emacsa05420"))
| 2 <- file-notify-callback: nil
1 <- file-notify-handle-event: nil
I'm confused: why does it mention a lock file instead of some file in
temporary-file-directory? Is some variable missing a value?
^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#21432: 25.0.50; file-notify-rm-watch (inotify) errors if watched dir is deleted
2015-09-15 8:22 ` Eli Zaretskii
@ 2015-09-15 11:54 ` Michael Albinus
2015-09-15 12:51 ` Eli Zaretskii
0 siblings, 1 reply; 36+ messages in thread
From: Michael Albinus @ 2015-09-15 11:54 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 21432, tsdh
Eli Zaretskii <eliz@gnu.org> writes:
> ======================================================================
> 1 -> (file-notify-handle-event (file-notify (100272320 added
> ".#-emacsa05420") file-notify-callback))
> | 2 -> (file-notify-callback (100272320 added ".#-emacsa05420"))
> | 2 <- file-notify-callback: nil
> 1 <- file-notify-handle-event: nil
> ======================================================================
> 1 -> (file-notify-handle-event (file-notify (100272320 modified
> ".#-emacsa05420") file-notify-callback))
> | 2 -> (file-notify-callback (100272320 modified ".#-emacsa05420"))
> | 2 <- file-notify-callback: nil
> 1 <- file-notify-handle-event: nil
>
> I'm confused: why does it mention a lock file instead of some file in
> temporary-file-directory? Is some variable missing a value?
Well, the lock files are from the write-region call. I see something
similar for inotify:
======================================================================
1 -> (file-notify-handle-event (file-notify (2 (create) ".#file-notify-test20231Yhx" 0) file-notify-callback))
| 2 -> (file-notify-callback (2 (create) ".#file-notify-test20231Yhx" 0))
| 2 <- file-notify-callback: nil
1 <- file-notify-handle-event: nil
======================================================================
1 -> (file-notify-handle-event (file-notify (2 (create) "file-notify-test20231Yhx" 0) file-notify-callback))
| 2 -> (file-notify-callback (2 (create) "file-notify-test20231Yhx" 0))
| | 3 -> (file-notify--test-event-handler ((2 . "file-notify-test20231Yhx") created "/tmp/file-notify-test-parent20231LXr/file-notify-test20231Yhx"))
| | 3 <- file-notify--test-event-handler: ([cl-struct-ert-test-passed #2="" ((#3=(should (equal (car file-notify--test-event) file-notify--test-desc)) :form (equal (1 . #1="file-notify-test20231-Ml") #4=(1 . #1#)) :value t :explanation nil) (#5=(should (string-equal (file-notify--event-file-name file-notify--test-event) file-notify--test-tmpfile)) :form (string-equal "/tmp/file-notify-test-parent20231MPA/file-notify-test20231-Ml" #6="/tmp/file-notify-test-parent20231MPA/file-notify-test20231-Ml") :value t))] [cl-struct-ert-test-passed #2# ((#3# :form (equal (1 . #1#) #4#) :value t :explanation nil) (#5# :form (string-equal "/tmp/file-notify-test-parent20231MPA/file-notify-test20231-Ml" #6#) :value t))] [cl-struct-ert-test-passed #2# ((#3# :form (equal (1 . #1#) #4#) :value t :explanation nil) (#5# :form (string-equal "/tmp/file-notify-test-parent20231MPA/file-notify-test20231-Ml" #6#) :value t))] [cl-struct-ert-test-passed #2# ((#3# :form (equal (2 . #7="file-notify-test20231Yhx") (2 . #7#)) :value t :explanation nil) (#5# :form (string-equal "/tmp/file-notify-test-parent20231LXr/file-notify-test20231Yhx" "/tmp/file-notify-test-parent20231LXr/file-notify-test20231Yhx") :value t))])
| 2 <- file-notify-callback: nil
1 <- file-notify-handle-event: nil
======================================================================
1 -> (file-notify-handle-event (file-notify (2 (modify) "file-notify-test20231Yhx" 0) file-notify-callback))
| 2 -> (file-notify-callback (2 (modify) "file-notify-test20231Yhx" 0))
| | 3 -> (file-notify--test-event-handler ((2 . "file-notify-test20231Yhx") changed "/tmp/file-notify-test-parent20231LXr/file-notify-test20231Yhx"))
| | 3 <- file-notify--test-event-handler: ([cl-struct-ert-test-passed #2="" ((#3=(should (equal (car file-notify--test-event) file-notify--test-desc)) :form (equal (1 . #1="file-notify-test20231-Ml") #4=(1 . #1#)) :value t :explanation nil) (#5=(should (string-equal (file-notify--event-file-name file-notify--test-event) file-notify--test-tmpfile)) :form (string-equal "/tmp/file-notify-test-parent20231MPA/file-notify-test20231-Ml" #6="/tmp/file-notify-test-parent20231MPA/file-notify-test20231-Ml") :value t))] [cl-struct-ert-test-passed #2# ((#3# :form (equal (1 . #1#) #4#) :value t :explanation nil) (#5# :form (string-equal "/tmp/file-notify-test-parent20231MPA/file-notify-test20231-Ml" #6#) :value t))] [cl-struct-ert-test-passed #2# ((#3# :form (equal (1 . #1#) #4#) :value t :explanation nil) (#5# :form (string-equal "/tmp/file-notify-test-parent20231MPA/file-notify-test20231-Ml" #6#) :value t))] [cl-struct-ert-test-passed #2# ((#3# :form (equal (2 . #7="file-notify-test20231Yhx") #8=(2 . #7#)) :value t :explanation nil) (#5# :form (string-equal "/tmp/file-notify-test-parent20231LXr/file-notify-test20231Yhx" #9="/tmp/file-notify-test-parent20231LXr/file-notify-test20231Yhx") :value t))] [cl-struct-ert-test-passed #2# ((#3# :form (equal (2 . #7#) #8#) :value t :explanation nil) (#5# :form (string-equal "/tmp/file-notify-test-parent20231LXr/file-notify-test20231Yhx" #9#) :value t))])
| 2 <- file-notify-callback: nil
1 <- file-notify-handle-event: nil
======================================================================
1 -> (file-notify-handle-event (file-notify (2 (delete) ".#file-notify-test20231Yhx" 0) file-notify-callback))
| 2 -> (file-notify-callback (2 (delete) ".#file-notify-test20231Yhx" 0))
| 2 <- file-notify-callback: nil
1 <- file-notify-handle-event: nil
======================================================================
1 -> (file-notify-handle-event (file-notify (2 (delete) "file-notify-test20231Yhx" 0) file-notify-callback))
| 2 -> (file-notify-callback (2 (delete) "file-notify-test20231Yhx" 0))
| | 3 -> (file-notify--test-event-handler ((2 . "file-notify-test20231Yhx") deleted "/tmp/file-notify-test-parent20231LXr/file-notify-test20231Yhx"))
| | 3 <- file-notify--test-event-handler: ([cl-struct-ert-test-passed #2="" ((#3=(should (equal (car file-notify--test-event) file-notify--test-desc)) :form (equal (1 . #1="file-notify-test20231-Ml") #4=(1 . #1#)) :value t :explanation nil) (#5=(should (string-equal (file-notify--event-file-name file-notify--test-event) file-notify--test-tmpfile)) :form (string-equal "/tmp/file-notify-test-parent20231MPA/file-notify-test20231-Ml" #6="/tmp/file-notify-test-parent20231MPA/file-notify-test20231-Ml") :value t))] [cl-struct-ert-test-passed #2# ((#3# :form (equal (1 . #1#) #4#) :value t :explanation nil) (#5# :form (string-equal "/tmp/file-notify-test-parent20231MPA/file-notify-test20231-Ml" #6#) :value t))] [cl-struct-ert-test-passed #2# ((#3# :form (equal (1 . #1#) #4#) :value t :explanation nil) (#5# :form (string-equal "/tmp/file-notify-test-parent20231MPA/file-notify-test20231-Ml" #6#) :value t))] [cl-struct-ert-test-passed #2# ((#3# :form (equal (2 . #7="file-notify-test20231Yhx") #8=(2 . #7#)) :value t :explanation nil) (#5# :form (string-equal "/tmp/file-notify-test-parent20231LXr/file-notify-test20231Yhx" #9="/tmp/file-notify-test-parent20231LXr/file-notify-test20231Yhx") :value t))] [cl-struct-ert-test-passed #2# ((#3# :form (equal (2 . #7#) #8#) :value t :explanation nil) (#5# :form (string-equal "/tmp/file-notify-test-parent20231LXr/file-notify-test20231Yhx" #9#) :value t))] [cl-struct-ert-test-passed #2# ((#3# :form (equal (2 . #7#) #8#) :value t :explanation nil) (#5# :form (string-equal "/tmp/file-notify-test-parent20231LXr/file-notify-test20231Yhx" #9#) :value t))])
| 2 <- file-notify-callback: nil
1 <- file-notify-handle-event: nil
======================================================================
1 -> (file-notify-handle-event (file-notify (2 (ignored) nil 0) file-notify-callback))
| 2 -> (file-notify-callback (2 (ignored) nil 0))
| 2 <- file-notify-callback: nil
1 <- file-notify-handle-event: nil
`file-notify--test-event-handler' hasn't been called for the lock files,
because it was enabled for the test file only (that's the intention of
this test case). It isn't clear to me why
`file-notify--test-event-handler' hasn't been called for your test
file. That must be something in w32notify.c.
Best regards, Michael.
^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#21432: 25.0.50; file-notify-rm-watch (inotify) errors if watched dir is deleted
2015-09-15 11:54 ` Michael Albinus
@ 2015-09-15 12:51 ` Eli Zaretskii
2015-09-15 12:56 ` Michael Albinus
2015-09-16 14:45 ` Michael Albinus
0 siblings, 2 replies; 36+ messages in thread
From: Eli Zaretskii @ 2015-09-15 12:51 UTC (permalink / raw)
To: Michael Albinus; +Cc: 21432, tsdh
> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: tsdh@gnu.org, 21432@debbugs.gnu.org
> Date: Tue, 15 Sep 2015 13:54:08 +0200
>
> It isn't clear to me why `file-notify--test-event-handler' hasn't
> been called for your test file. That must be something in
> w32notify.c.
What kind of "something"? Notifications do work, and the rest of the
tests pass. So it must be something with this particular test.
I think the problem is due to the fact that the directory is deleted
inside the file-notify--test-with-events form: doing that invalidates
the watch, so the events are not reported. If I remove this line from
the macro body:
(delete-directory temporary-file-directory t)
then the notifications are received as expected:
Test file-notify-test04-file-validity condition:
(ert-test-failed
((should
(equal '...
(mapcar ... events)))
:form
(equal
(created changed deleted)
(created changed))
:value nil :explanation
(proper-lists-of-different-length 3 2
(created changed deleted)
(created changed)
first-mismatch-at 2)))
(There's no "deleted" because it's caused by delete-directory call
which I removed.)
So I modified the test to have the directory deletion outside of the
macro, and the test now passes. I also increased the timeout of
read-event, because 0.1 was borderline: it sometimes worked and
sometimes didn't.
Please see if the modified tests work with inotify (they did for me on
GNU/Linux).
^ permalink raw reply [flat|nested] 36+ messages in thread* bug#21432: 25.0.50; file-notify-rm-watch (inotify) errors if watched dir is deleted
2015-09-15 12:51 ` Eli Zaretskii
@ 2015-09-15 12:56 ` Michael Albinus
2015-09-16 14:45 ` Michael Albinus
1 sibling, 0 replies; 36+ messages in thread
From: Michael Albinus @ 2015-09-15 12:56 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 21432, tsdh
Eli Zaretskii <eliz@gnu.org> writes:
> So I modified the test to have the directory deletion outside of the
> macro, and the test now passes. I also increased the timeout of
> read-event, because 0.1 was borderline: it sometimes worked and
> sometimes didn't.
>
> Please see if the modified tests work with inotify (they did for me on
> GNU/Linux).
Works here. And also `file-notify-test04-file-validity-remote', which
did fail before. Thanks.
Best regards, Michael.
^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#21432: 25.0.50; file-notify-rm-watch (inotify) errors if watched dir is deleted
2015-09-15 12:51 ` Eli Zaretskii
2015-09-15 12:56 ` Michael Albinus
@ 2015-09-16 14:45 ` Michael Albinus
2015-09-16 17:08 ` Eli Zaretskii
1 sibling, 1 reply; 36+ messages in thread
From: Michael Albinus @ 2015-09-16 14:45 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 21432, tsdh
Eli Zaretskii <eliz@gnu.org> writes:
> I think the problem is due to the fact that the directory is deleted
> inside the file-notify--test-with-events form: doing that invalidates
> the watch, so the events are not reported. If I remove this line from
> the macro body:
>
> So I modified the test to have the directory deletion outside of the
> macro, and the test now passes. I also increased the timeout of
> read-event, because 0.1 was borderline: it sometimes worked and
> sometimes didn't.
I've checked further. In `file-notify-test04-file-validity', you have
also removed the final check for `file-notify-valid-p':
;; After deleting the parent, the descriptor must not be valid
;; anymore.
- (should-not (file-notify-valid-p file-notify--test-desc)))
+ (delete-directory temporary-file-directory t)
+ (read-event nil nil 0.5))
Was this by intention? The whole test case is about this check. And
maybe this is also the reason that it passes now the remote test case,
surprisingly.
Best regards, Michael.
^ permalink raw reply [flat|nested] 36+ messages in thread* bug#21432: 25.0.50; file-notify-rm-watch (inotify) errors if watched dir is deleted
2015-09-16 14:45 ` Michael Albinus
@ 2015-09-16 17:08 ` Eli Zaretskii
2015-09-16 17:26 ` Michael Albinus
0 siblings, 1 reply; 36+ messages in thread
From: Eli Zaretskii @ 2015-09-16 17:08 UTC (permalink / raw)
To: Michael Albinus; +Cc: 21432, tsdh
> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: tsdh@gnu.org, 21432@debbugs.gnu.org
> Date: Wed, 16 Sep 2015 16:45:56 +0200
>
> I've checked further. In `file-notify-test04-file-validity', you have
> also removed the final check for `file-notify-valid-p':
>
> ;; After deleting the parent, the descriptor must not be valid
> ;; anymore.
> - (should-not (file-notify-valid-p file-notify--test-desc)))
> + (delete-directory temporary-file-directory t)
> + (read-event nil nil 0.5))
Oops!
> Was this by intention?
No.
> The whole test case is about this check. And maybe this is also the
> reason that it passes now the remote test case, surprisingly.
Does it work for you if you add the test after read-event? It fails
here, i.e. the watch is still valid.
^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#21432: 25.0.50; file-notify-rm-watch (inotify) errors if watched dir is deleted
2015-09-16 17:08 ` Eli Zaretskii
@ 2015-09-16 17:26 ` Michael Albinus
2015-09-16 17:55 ` Eli Zaretskii
0 siblings, 1 reply; 36+ messages in thread
From: Michael Albinus @ 2015-09-16 17:26 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 21432, tsdh
Eli Zaretskii <eliz@gnu.org> writes:
>> The whole test case is about this check. And maybe this is also the
>> reason that it passes now the remote test case, surprisingly.
>
> Does it work for you if you add the test after read-event? It fails
> here, i.e. the watch is still valid.
Yes, it works for inotify. And `file-notify-test04-file-validity-remote'
fails as expected, 'cos I haven't fixed it yet in Tramp.
For inotify it is obvious that it shall work. All inotify watches are
based on inodes. If a file is watched by inotify, and the parent
directory of the file is deleted, the inode of the file itself disappears.
I don't know how it works with w32notify internally. And I don't know
yet how it will behave with gfilenotify, all checks for that backend I
have moved to later.
Best regards, Michael.
^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#21432: 25.0.50; file-notify-rm-watch (inotify) errors if watched dir is deleted
2015-09-16 17:26 ` Michael Albinus
@ 2015-09-16 17:55 ` Eli Zaretskii
2015-09-16 18:28 ` Michael Albinus
0 siblings, 1 reply; 36+ messages in thread
From: Eli Zaretskii @ 2015-09-16 17:55 UTC (permalink / raw)
To: Michael Albinus; +Cc: 21432, tsdh
> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: tsdh@gnu.org, 21432@debbugs.gnu.org
> Date: Wed, 16 Sep 2015 19:26:50 +0200
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> The whole test case is about this check. And maybe this is also the
> >> reason that it passes now the remote test case, surprisingly.
> >
> > Does it work for you if you add the test after read-event? It fails
> > here, i.e. the watch is still valid.
>
> Yes, it works for inotify. And `file-notify-test04-file-validity-remote'
> fails as expected, 'cos I haven't fixed it yet in Tramp.
>
> For inotify it is obvious that it shall work. All inotify watches are
> based on inodes. If a file is watched by inotify, and the parent
> directory of the file is deleted, the inode of the file itself disappears.
>
> I don't know how it works with w32notify internally. And I don't know
> yet how it will behave with gfilenotify, all checks for that backend I
> have moved to later.
It works for w32notify if I run the test in an interactive session.
It only fails in batch mode. Since the batch-mode operation of
w32notify is fragile (there's no input threads to send the message
to), and we have already wasted too much time on this tiny feature,
feel free to skip that test when in batch mode and w32notify back-end
is used.
^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#21432: 25.0.50; file-notify-rm-watch (inotify) errors if watched dir is deleted
2015-09-16 17:55 ` Eli Zaretskii
@ 2015-09-16 18:28 ` Michael Albinus
0 siblings, 0 replies; 36+ messages in thread
From: Michael Albinus @ 2015-09-16 18:28 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 21432, tsdh
Eli Zaretskii <eliz@gnu.org> writes:
> It works for w32notify if I run the test in an interactive session.
> It only fails in batch mode. Since the batch-mode operation of
> w32notify is fragile (there's no input threads to send the message
> to), and we have already wasted too much time on this tiny feature,
> feel free to skip that test when in batch mode and w32notify back-end
> is used.
Done.
^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#21432: 25.0.50; file-notify-rm-watch (inotify) errors if watched dir is deleted
2015-09-14 13:22 ` Eli Zaretskii
2015-09-14 20:23 ` Michael Albinus
@ 2015-09-15 5:53 ` Tassilo Horn
1 sibling, 0 replies; 36+ messages in thread
From: Tassilo Horn @ 2015-09-15 5:53 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: michael.albinus, 21432
Eli Zaretskii <eliz@gnu.org> writes:
>> Done, however the descriptors still don't become invalid when
>> deleting the parent directory of the watched file or directory. I
>> guess, that's a problem in the inotify and TRAMP implementations
>> then.
>
> No, I think it's a problem with our mental model of what happens. The
> file notifications use the Emacs event loop, and Emacs won't check for
> events until it's idle. So calling file-notify-valid-p as part of the
> test ends up doing that _before_ the directory deletion notification
> is read by Emacs and invalidates the watch.
Yes, you are right. Michael already fixed the tests by waiting for the
file notifications before calling `file-notify-valid-p' and then we get
the expected results (well, not yet with remote files).
Bye,
Tassilo
^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#21432: 25.0.50; file-notify-rm-watch (inotify) errors if watched dir is deleted
2015-09-12 15:11 ` Eli Zaretskii
2015-09-12 18:09 ` Michael Albinus
@ 2015-09-14 7:35 ` Eli Zaretskii
2015-09-14 7:37 ` Michael Albinus
2015-09-15 13:02 ` Michael Albinus
1 sibling, 2 replies; 36+ messages in thread
From: Eli Zaretskii @ 2015-09-14 7:35 UTC (permalink / raw)
To: michael.albinus; +Cc: 21432, tsdh
> Date: Sat, 12 Sep 2015 18:11:37 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 21432@debbugs.gnu.org, tsdh@gnu.org
>
> > Last point, I've observed that inotify and gfilenotify raise a
> > `file-notify-error' when needed. w32notify raises a `file-error'.
> > Shouldn't it raise also `file-notify-error'?.
>
> Yes, it should.
I've done that now.
I find the way inotify.c and gfilenotify.c report errors suboptimal:
they don't report the errno value and the related data, so the error
messages tell less than they could. I went the way similar to
report_file_error instead. Maybe the other back-ends should follow
suit.
^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#21432: 25.0.50; file-notify-rm-watch (inotify) errors if watched dir is deleted
2015-09-14 7:35 ` Eli Zaretskii
@ 2015-09-14 7:37 ` Michael Albinus
2015-09-15 13:02 ` Michael Albinus
1 sibling, 0 replies; 36+ messages in thread
From: Michael Albinus @ 2015-09-14 7:37 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 21432, tsdh
Eli Zaretskii <eliz@gnu.org> writes:
> I find the way inotify.c and gfilenotify.c report errors suboptimal:
> they don't report the errno value and the related data, so the error
> messages tell less than they could. I went the way similar to
> report_file_error instead. Maybe the other back-ends should follow
> suit.
Will do.
Best regards, Michael.
^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#21432: 25.0.50; file-notify-rm-watch (inotify) errors if watched dir is deleted
2015-09-14 7:35 ` Eli Zaretskii
2015-09-14 7:37 ` Michael Albinus
@ 2015-09-15 13:02 ` Michael Albinus
2015-09-15 13:56 ` Eli Zaretskii
1 sibling, 1 reply; 36+ messages in thread
From: Michael Albinus @ 2015-09-15 13:02 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 21432, tsdh
Eli Zaretskii <eliz@gnu.org> writes:
> I find the way inotify.c and gfilenotify.c report errors suboptimal:
> they don't report the errno value and the related data, so the error
> messages tell less than they could. I went the way similar to
> report_file_error instead. Maybe the other back-ends should follow
> suit.
I've changed it in inotify.c. I've simply cloned your
report_w32notify_error, called it report_inotify_error, and adapted all
error reporting places.
However, wouldn't it be better to have a common function the three
backends will use? A report_filenotify_error function in fileio.c?
Best regards, Michael.
^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#21432: 25.0.50; file-notify-rm-watch (inotify) errors if watched dir is deleted
2015-09-08 6:36 bug#21432: 25.0.50; file-notify-rm-watch (inotify) errors if watched dir is deleted Tassilo Horn
2015-09-08 7:47 ` Michael Albinus
2015-09-08 15:49 ` Eli Zaretskii
@ 2015-09-20 17:23 ` Michael Albinus
2015-09-20 19:19 ` Eli Zaretskii
2 siblings, 1 reply; 36+ messages in thread
From: Michael Albinus @ 2015-09-20 17:23 UTC (permalink / raw)
To: Tassilo Horn; +Cc: 21432
Tassilo Horn <tsdh@gnu.org> writes:
> Right now, (at least) the inotify version of `file-notify-rm-watch'
> signals an error in case the given descriptor denotes a directory which
> has been deleted in the meantime. If it denotes a file which has been
> deleted, no error is signaled.
I believe, everything what has been discussed in the course of this bug
has been fixed now. I've committed a final patch for the Tramp case, and
I have extended the test cases slightly with this patch. Inotify and
Tramp tests pass all test cases.
If there's no problem left for w32notify, I believe we can close this bug.
There is still something to do for the gfilenotify case, but this I
could do outside this report.
Best regards, Michael.
^ permalink raw reply [flat|nested] 36+ messages in thread
end of thread, other threads:[~2015-09-21 13:40 UTC | newest]
Thread overview: 36+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-09-08 6:36 bug#21432: 25.0.50; file-notify-rm-watch (inotify) errors if watched dir is deleted Tassilo Horn
2015-09-08 7:47 ` Michael Albinus
2015-09-08 8:11 ` Tassilo Horn
2015-09-08 15:51 ` Eli Zaretskii
2015-09-08 15:49 ` Eli Zaretskii
2015-09-08 16:01 ` Michael Albinus
2015-09-12 10:18 ` Michael Albinus
2015-09-12 15:11 ` Eli Zaretskii
2015-09-12 18:09 ` Michael Albinus
2015-09-13 19:23 ` Michael Albinus
2015-09-14 6:08 ` Tassilo Horn
2015-09-14 7:08 ` Eli Zaretskii
2015-09-14 7:40 ` Tassilo Horn
2015-09-14 7:56 ` Tassilo Horn
2015-09-14 13:22 ` Eli Zaretskii
2015-09-14 20:23 ` Michael Albinus
2015-09-15 7:38 ` Eli Zaretskii
2015-09-15 8:00 ` Michael Albinus
2015-09-15 8:22 ` Eli Zaretskii
2015-09-15 11:54 ` Michael Albinus
2015-09-15 12:51 ` Eli Zaretskii
2015-09-15 12:56 ` Michael Albinus
2015-09-16 14:45 ` Michael Albinus
2015-09-16 17:08 ` Eli Zaretskii
2015-09-16 17:26 ` Michael Albinus
2015-09-16 17:55 ` Eli Zaretskii
2015-09-16 18:28 ` Michael Albinus
2015-09-15 5:53 ` Tassilo Horn
2015-09-14 7:35 ` Eli Zaretskii
2015-09-14 7:37 ` Michael Albinus
2015-09-15 13:02 ` Michael Albinus
2015-09-15 13:56 ` Eli Zaretskii
2015-09-16 13:54 ` Michael Albinus
2015-09-20 17:23 ` Michael Albinus
2015-09-20 19:19 ` Eli Zaretskii
2015-09-21 13:40 ` Michael Albinus
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).