From unknown Mon Jun 16 23:47:11 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#49261 <49261@debbugs.gnu.org> To: bug#49261 <49261@debbugs.gnu.org> Subject: Status: 28.0.50; File Locking Breaks Presumptuous Toolchains Reply-To: bug#49261 <49261@debbugs.gnu.org> Date: Tue, 17 Jun 2025 06:47:11 +0000 retitle 49261 28.0.50; File Locking Breaks Presumptuous Toolchains reassign 49261 emacs submitter 49261 Mallchad Skeghyeph severity 49261 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Mon Jun 28 14:27:33 2021 Received: (at submit) by debbugs.gnu.org; 28 Jun 2021 18:27:34 +0000 Received: from localhost ([127.0.0.1]:52498 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lxvyl-0000Rp-7q for submit@debbugs.gnu.org; Mon, 28 Jun 2021 14:27:33 -0400 Received: from lists.gnu.org ([209.51.188.17]:34332) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lxvDV-0007fh-9b for submit@debbugs.gnu.org; Mon, 28 Jun 2021 13:38:42 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:39124) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lxvDP-0008Az-Bj for bug-gnu-emacs@gnu.org; Mon, 28 Jun 2021 13:38:37 -0400 Received: from mail-ej1-x62f.google.com ([2a00:1450:4864:20::62f]:42567) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lxvDK-0001EH-MK for bug-gnu-emacs@gnu.org; Mon, 28 Jun 2021 13:38:35 -0400 Received: by mail-ej1-x62f.google.com with SMTP id bg14so31273330ejb.9 for ; Mon, 28 Jun 2021 10:38:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=JDqwvzrTZJVgH7B48faOiK3lXl1KEmsLiapuWjZyqL4=; b=EGFYLt6vcTkd4l613vGtF+Hp5NLKQvZP8l/+wIjx/mEVB+OBPr0D7NSs6zbmtFMUbf PTG7JLlZfkyDlUdRkfpBsgJaVw0gMXxtXJ3F/jgj4T0aRqtJhREb7v+zIuUUjiHPokcN hEmH+cP7ZcN7+oQxdnGXsbNBezQhH7I/dRMtyMVkhR+w8EeXiq6tiSL0K0T31qaHDaue JLksrENnDalwUdWamOL/ur96TQn4Kbq1Dsqlkk6lEvrwnKcIuoWN+m9pdQsTlrwhZHcF sY4ppIyd/R8U0tg7Hwg8vANnSjCRFcfYWyP/JWv20NhuwldPnX2N8do3CPMXQLVibUWo taTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=JDqwvzrTZJVgH7B48faOiK3lXl1KEmsLiapuWjZyqL4=; b=MknExUBO/KI5HlY27tGPsASt6boaTEcHwZnjF9/izessOAlJFT1GAXMiGkYeFbqBj8 CD/zML6e7G6lElX6lutata/7PIjrD33gViH9QlAMN1v8PT91dQe5ZASnNe4cyZavCB+J rYQLRR61n6/WNgftHdzNC5vSvQolsx8EKIBee9a4VMhkTXdguDwpLlPKNJEFQbRSJuL5 nxd+cvOs9vf+new1JIfyjhduoQjo4BQtABpY6VsXqrVtbFau42dZhTdf0DccbKoZN4Wz zNw13p5ZUX65QtVy4oEqfepUYYRXSXLwC9vdS4aW/6tpl7Gtue3S/kfcsqXMGM5lmdyy eY1g== X-Gm-Message-State: AOAM533SJ3m9tgjtOBTiQmgEKT3r91BpypPUrD/q/SrmTjcoYMuWN9Zc wCmWxZ6eBAbvK/elZjtT1NkYl7jNr7G4OjnSN0duBPYac70= X-Google-Smtp-Source: ABdhPJyzt89ilkFFro1V3JfLK6zWx7xBn67Oeln3KYUEMm6HWYIKL4DIAKSxGpXPcSUOhu/+1a7Iqt4cTzALuyJeyCU= X-Received: by 2002:a17:906:470c:: with SMTP id y12mr26095853ejq.54.1624901906948; Mon, 28 Jun 2021 10:38:26 -0700 (PDT) MIME-Version: 1.0 From: Mallchad Skeghyeph Date: Mon, 28 Jun 2021 18:38:16 +0100 Message-ID: Subject: 28.0.50; File Locking Breaks Presumptuous Toolchains To: bug-gnu-emacs@gnu.org Content-Type: multipart/alternative; boundary="000000000000f5644105c5d6f473" Received-SPF: pass client-ip=2a00:1450:4864:20::62f; envelope-from=ncaprisunfan@gmail.com; helo=mail-ej1-x62f.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Mon, 28 Jun 2021 14:27:29 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) --000000000000f5644105c5d6f473 Content-Type: text/plain; charset="UTF-8" Date: Mon, 28 Jun 2021 18:36:19 +0100 Message-ID: <878s2tx564.fsf@gmail.com> I've found for a little while now that a few default behaviors of GNU emacs pollutes directories. In the worst cases this can actually break programs, especially software toolchains, where they assume a partition kind of file should be pretend, and mistakenly tries to work with the file lock. Another one of this files is backups and autosaves. Ideally I would like the file lock and backup files to be placed in a central directory, rather than the same directory as the file in question. After researching this problem I can see I'm not alone, and others have felt this way for far longer than I have. I have looked into seeing if I could change this manually, for backups I can, for file locks I have to dive into the source code, and after looking I fear I would be knee deep in a very long rabbit hole without having something more to work with. I've not touched the source for this project before, only looked. In GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.29, cairo version 1.17.4) of 2021-06-20 built on m-arch-asus Repository revision: 01b0a909b5ca858a09484821cc866127652f4153 Repository branch: makepkg Windowing system distributor 'System Description: Arch Linux Configured using: 'configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib --localstatedir=/var --mandir=/usr/share/man --with-gameuser=:games --with-sound=alsa --with-modules --without-gconf --without-gsettings --with-native-compilation --with-pgtk --enable-link-time-optimization --with-x-toolkit=gtk3 --without-xaw3d --without-m17n-flt --with-cairo --with-xwidgets --without-compress-install 'CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fno-plt -g -flto -fuse-linker-plugin -fuse-ld=gold -g -flto -fuse-linker-plugin -fuse-ld=gold' CPPFLAGS=-D_FORTIFY_SOURCE=2 LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now' Configured features: ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM HARFBUZZ JPEG JSON LCMS2 LIBOTF LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PGTK PNG RSVG SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS XIM XWIDGETS GTK3 ZLIB Important settings: value of $LANG: en_US.UTF-8 locale-coding-system: utf-8-unix Major mode: Fundamental Minor modes in effect: company-tng-mode: t beacon-mode: t centaur-tabs-mode: t global-highlight-parentheses-mode: t smartparens-global-mode: t smooth-scrolling-mode: t sublimity-mode: t global-whitespace-mode: t global-subword-mode: t treemacs-filewatch-mode: t treemacs-follow-mode: t treemacs-git-mode: deferred treemacs-fringe-indicator-mode: t global-hl-line-mode: t helm-mode: t projectile-mode: t zoom-mode: t ws-butler-global-mode: t volatile-highlights-mode: t global-undo-tree-mode: t helm-autoresize-mode: t helm--remap-mouse-mode: t global-git-commit-mode: t magit-auto-revert-mode: t global-hungry-delete-mode: t global-hl-todo-mode: t recentf-mode: t shell-dirtrack-mode: t async-bytecomp-package-mode: t override-global-mode: t tooltip-mode: t global-eldoc-mode: t mouse-wheel-mode: t file-name-shadow-mode: t global-font-lock-mode: t blink-cursor-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t line-number-mode: t global-visual-line-mode: t Load-path shadows: /home/mallchad/.emacs.d/elpa/cmake-mode-20210104.1831/cmake-mode hides /usr/share/emacs/site-lisp/cmake-mode /home/mallchad/.emacs.d/elpa/transient-20210525.1141/transient hides /usr/share/emacs/28.0.50/lisp/transient Features: (gnus-async gnus-agent gnus-srvr gnus-score score-mode nnvirtual nntp gnus-ml gnus-msg nndoc gnus-cache gnus-dup debbugs-gnu debbugs soap-client rng-xsd rng-dt rng-util xsd-regexp tar-mode arc-mode archive-mode mm-archive url-http url-gw url-cache url-auth mailclient shadow sort mail-extr emacsbug sendmail vc bug-reference mule-util cl-print help-fns tabify image-file image-converter magit-extras org-indent 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 gnus-group gnus-undo gnus-start gnus-dbus gnus-cloud nnimap nnmail mail-source utf7 netrc nnoo gnus-spec gnus-int gnus-range gnus-win gnus nnheader ol-docview doc-view jka-compr ol-bibtex bibtex ol-bbdb ol-w3m sh-script smie executable backup-each-save cus-edit cus-start cus-load ffap dabbrev find-file helm-command helm-elisp helm-eval edebug backtrace lsp-diagnostics lsp-headerline lsp-icons lsp-modeline vc-git vc-dispatcher lsp-zig lsp-steep lsp-svelte lsp-sqls lsp-yaml lsp-xml lsp-vimscript lsp-vhdl lsp-vetur lsp-html lsp-verilog lsp-vala lsp-v lsp-terraform lsp-tex lsp-sorbet lsp-solargraph lsp-rust lsp-rf lsp-r lsp-purescript lsp-pylsp lsp-pyls lsp-pwsh lsp-php lsp-perl lsp-ocaml lsp-nix lsp-nim lsp-markdown lsp-lua lsp-kotlin lsp-json lsp-javascript lsp-haxe lsp-groovy lsp-hack lsp-go lsp-completion lsp-gdscript lsp-fsharp lsp-fortran lsp-eslint lsp-erlang lsp-elixir lsp-elm lsp-dockerfile lsp-dhall lsp-d lsp-css lsp-csharp lsp-crystal lsp-cmake lsp-clojure lsp-clangd dom lsp-beancount lsp-bash lsp-angular lsp-ada lsp-actionscript winner tramp-archive tramp-gvfs dbus helm-x-files helm-for-files helm-bookmark helm-adaptive helm-info helm-external helm-net xml aggressive-indent company-oddmuse company-keywords company-etags company-gtags company-dabbrev-code company-dabbrev company-files company-clang company-capf company-cmake company-semantic company-template company-bbdb company-tng company rainbow-delimiters rainbow-mode page-break-lines display-line-numbers linum init beacon centaur-tabs centaur-tabs-interactive centaur-tabs-functions centaur-tabs-elements powerline powerline-separators powerline-themes highlight-parentheses smartparens-config smartparens-javascript smartparens-rst smartparens-org smartparens-markdown smartparens-text smartparens-c smartparens smooth-scrolling sublimity-scroll sublimity disp-table whitespace cap-words superword subword lsp-treemacs lsp-treemacs-themes treemacs treemacs-header-line treemacs-compatibility treemacs-mode treemacs-bookmarks treemacs-interface treemacs-extensions treemacs-mouse-interface treemacs-tags treemacs-persistence treemacs-filewatch-mode treemacs-follow-mode treemacs-rendering treemacs-async treemacs-workspaces treemacs-dom treemacs-visuals treemacs-fringe-indicator treemacs-scope pulse treemacs-faces treemacs-icons treemacs-themes treemacs-core-utils pfuture hl-line treemacs-logging treemacs-customization treemacs-macros lsp-origami lsp-ui lsp-ui-flycheck lsp-ui-doc xwidget image-mode exif magit-bookmark bookmark goto-addr lsp-ui-imenu lsp-ui-peek lsp-ui-sideline face-remap lsp-ui-util lsp-mode lsp-protocol spinner network-stream nsm markdown-mode inline ewoc origami origami-parsers helm-mode helm-config helm-swoop helm-rg pcase helm-projectile helm-files helm-tags helm-buffers helm-occur helm-locate helm-types projectile grep ibuf-ext ibuffer ibuffer-loaddefs helm-flycheck flycheck-inline csproj-mode org-cliplink org-cliplink-transport org-cliplink-string em-glob esh-util zoom ws-butler volatile-highlights visual-fill-column vlf-setup vlf vlf-base vlf-tune visible-mark undo-tree smart-yank restart-emacs desktop frameset rainbow-blocks org-super-agenda ts org-habit org-agenda org-refile org-noter org-element avl-tree 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 ol org-keys org-compat org-macs org-loaddefs cal-menu calendar cal-loaddefs omnisharp omnisharp-unit-test-actions omnisharp-code-structure omnisharp-server-installation gnutls omnisharp-format-actions omnisharp-solution-actions omnisharp-helm-integration helm-grep helm-regexp helm-utils helm-help helm helm-global-bindings helm-easymenu helm-source helm-multi-match helm-lib omnisharp-navigation-actions omnisharp-current-symbol-actions omnisharp-auto-complete-actions omnisharp-server-actions omnisharp-http-utils omnisharp-utils omnisharp-server-management omnisharp-settings f s flycheck find-func etags fileloop generator xref project popup ido csharp-mode csharp-compilation cc-langs json-mode json-reformat json-snatcher js cc-mode cc-fonts cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs multiple-cursors mc-separate-operations rectangular-region-mode mc-mark-pop mc-edit-lines mc-hide-unmatched-lines-mode mc-mark-more mc-cycle-cursors multiple-cursors-core advice rect 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 diff-mode git-commit log-edit message rmc puny rfc822 mml mml-sec epa derived epg epg-config gnus-util rmail rmail-loaddefs mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045 mm-util ietf-drums mail-prsvr mailabbrev mail-utils gmm-utils mailheader pcvs-util add-log magit-core magit-autorevert autorevert filenotify magit-margin magit-transient magit-process with-editor server magit-mode transient magit-git magit-section magit-utils crm hydra lv hungry-delete hl-todo god-mode free-keys fireplace dashboard dashboard-widgets time recentf tree-widget wid-edit cmake-mode rst compile text-property-search crux tramp tramp-loaddefs trampver tramp-integration files-x tramp-compat shell pcomplete comint ansi-color parse-time iso8601 time-date ls-lisp format-spec thingatpt edmacro kmacro avy ring sanityinc-tomorrow-night-theme color-theme-sanityinc-tomorrow color all-the-icons all-the-icons-faces data-material data-weathericons data-octicons data-fileicons data-faicons data-alltheicons async-bytecomp async flyspell ispell req-package view req-package-cycles req-package-args req-package-hooks ht log4e dash 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 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 el-get-custom el-get-core autoload radix-tree lisp-mnt dired dired-loaddefs use-package use-package-ensure use-package-delight use-package-diminish use-package-bind-key bind-key easy-mmode use-package-core cl cemacs-utility finder-inf info 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 eieio-loaddefs password-cache json map url-vars comp comp-cstr warnings subr-x rx cl-seq cl-macs cl-extra help-mode seq byte-opt gv cl-loaddefs cl-lib bytecomp byte-compile cconv iso-transl tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel term/pgtk-win pgtk-win term/common-win tool-bar dnd fontset image regexp-opt fringe tabulated-list replace newcomment text-mode elisp-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 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 xwidget-internal dbusbind inotify dynamic-setting font-render-setting cairo move-toolbar gtk x-toolkit pgtk lcms2 multi-tty make-network-process native-compile emacs) Memory information: ((conses 16 1366260 1278287) (symbols 48 71661 1845) (strings 32 821605 302207) (string-bytes 1 15366299) (vectors 16 808670) (vector-slots 8 8340068 966354) (floats 8 3607 3481) (intervals 56 38157 23043) (buffers 992 69)) --000000000000f5644105c5d6f473 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Date: Mon, 28 Jun 2021 18:36:19 +0100
Message-ID: <<= a href=3D"mailto:878s2tx564.fsf@gmail.com">878s2tx564.fsf@gmail.com>=
I've found for a little while now that a few default behaviors of G= NU
emacs pollutes directories.
In the worst cases this can actually b= reak programs, especially software
toolchains, where they assume a parti= tion kind of file should be
pretend, and mistakenly tries to work with t= he file lock.
Another one of this files is backups and autosaves.
Ideally I would like the file lock and backup files to be placed in a
c= entral directory,
rather than the same directory as the file in questio= n.
After researching this problem I can see I'm not alone, and other= s have
felt this way for far longer than I have.

I have looked in= to seeing if I could change this manually,
for backups I can,
for fil= e locks I have to dive into the source code, and after looking I
fear I = would be knee deep in a very long rabbit hole without having
something m= ore to work with.
I've not touched the source for this project befor= e, only looked.

In GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, = GTK+ Version 3.24.29, cairo version 1.17.4)
=C2=A0of 2021-06-20 built on= m-arch-asus
Repository revision: 01b0a909b5ca858a09484821cc866127652f41= 53
Repository branch: makepkg
Windowing system distributor 'Syste= m Description: Arch Linux

Configured using:
=C2=A0'configure = --prefix=3D/usr --sysconfdir=3D/etc --libexecdir=3D/usr/lib
=C2=A0--loca= lstatedir=3D/var --mandir=3D/usr/share/man --with-gameuser=3D:games
=C2= =A0--with-sound=3Dalsa --with-modules --without-gconf --without-gsettings=C2=A0--with-native-compilation --with-pgtk --enable-link-time-optimizati= on
=C2=A0--with-x-toolkit=3Dgtk3 --without-xaw3d --without-m17n-flt --wi= th-cairo
=C2=A0--with-xwidgets --without-compress-install 'CFLAGS=3D= -march=3Dx86-64
=C2=A0-mtune=3Dgeneric -O2 -pipe -fno-plt -g -flto -fuse= -linker-plugin
=C2=A0-fuse-ld=3Dgold -g -flto -fuse-linker-plugin -fuse-= ld=3Dgold'
=C2=A0CPPFLAGS=3D-D_FORTIFY_SOURCE=3D2
=C2=A0LDFLAGS= =3D-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now'

Configured= features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM HARFBUZZ JPEG= JSON LCMS2
LIBOTF LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY= PDUMPER
PGTK PNG RSVG SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS XI= M
XWIDGETS GTK3 ZLIB

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

Major mode:= Fundamental

Minor modes in effect:
=C2=A0 company-tng-mode: t=C2=A0 beacon-mode: t
=C2=A0 centaur-tabs-mode: t
=C2=A0 global-high= light-parentheses-mode: t
=C2=A0 smartparens-global-mode: t
=C2=A0 sm= ooth-scrolling-mode: t
=C2=A0 sublimity-mode: t
=C2=A0 global-whitesp= ace-mode: t
=C2=A0 global-subword-mode: t
=C2=A0 treemacs-filewatch-m= ode: t
=C2=A0 treemacs-follow-mode: t
=C2=A0 treemacs-git-mode: defer= red
=C2=A0 treemacs-fringe-indicator-mode: t
=C2=A0 global-hl-line-mo= de: t
=C2=A0 helm-mode: t
=C2=A0 projectile-mode: t
=C2=A0 zoom-mo= de: t
=C2=A0 ws-butler-global-mode: t
=C2=A0 volatile-highlights-mode= : t
=C2=A0 global-undo-tree-mode: t
=C2=A0 helm-autoresize-mode: t=C2=A0 helm--remap-mouse-mode: t
=C2=A0 global-git-commit-mode: t
= =C2=A0 magit-auto-revert-mode: t
=C2=A0 global-hungry-delete-mode: t
= =C2=A0 global-hl-todo-mode: t
=C2=A0 recentf-mode: t
=C2=A0 shell-dir= track-mode: t
=C2=A0 async-bytecomp-package-mode: t
=C2=A0 override-g= lobal-mode: t
=C2=A0 tooltip-mode: t
=C2=A0 global-eldoc-mode: t
= =C2=A0 mouse-wheel-mode: t
=C2=A0 file-name-shadow-mode: t
=C2=A0 glo= bal-font-lock-mode: t
=C2=A0 blink-cursor-mode: t
=C2=A0 auto-composi= tion-mode: t
=C2=A0 auto-encryption-mode: t
=C2=A0 auto-compression-m= ode: t
=C2=A0 line-number-mode: t
=C2=A0 global-visual-line-mode: t
Load-path shadows:
/home/mallchad/.emacs.d/elpa/cmake-mode-2021010= 4.1831/cmake-mode hides /usr/share/emacs/site-lisp/cmake-mode
/home/mall= chad/.emacs.d/elpa/transient-20210525.1141/transient hides /usr/share/emacs= /28.0.50/lisp/transient

Features:
(gnus-async gnus-agent gnus-srv= r gnus-score score-mode nnvirtual nntp
gnus-ml gnus-msg nndoc gnus-cache= gnus-dup debbugs-gnu debbugs
soap-client rng-xsd rng-dt rng-util xsd-re= gexp tar-mode arc-mode
archive-mode mm-archive url-http url-gw url-cache= url-auth mailclient
shadow sort mail-extr emacsbug sendmail vc bug-refe= rence mule-util
cl-print help-fns tabify image-file image-converter magi= t-extras
org-indent ol-eww eww xdg url-queue mm-url ol-rmail ol-mhe ol-i= rc
ol-info ol-gnus nnselect gnus-search eieio-opt speedbar ezimage dfram= e
gnus-art mm-uu mml2015 mm-view mml-smime smime dig gnus-sum shr kinsok= u
svg gnus-group gnus-undo gnus-start gnus-dbus gnus-cloud nnimap nnmail=
mail-source utf7 netrc nnoo gnus-spec gnus-int gnus-range gnus-win gnus=
nnheader ol-docview doc-view jka-compr ol-bibtex bibtex ol-bbdb ol-w3m<= br>sh-script smie executable backup-each-save cus-edit cus-start cus-loadffap dabbrev find-file helm-command helm-elisp helm-eval edebug
backtr= ace lsp-diagnostics lsp-headerline lsp-icons lsp-modeline vc-git
vc-disp= atcher lsp-zig lsp-steep lsp-svelte lsp-sqls lsp-yaml lsp-xml
lsp-vimscr= ipt lsp-vhdl lsp-vetur lsp-html lsp-verilog lsp-vala lsp-v
lsp-terraform= lsp-tex lsp-sorbet lsp-solargraph lsp-rust lsp-rf lsp-r
lsp-purescript = lsp-pylsp lsp-pyls lsp-pwsh lsp-php lsp-perl lsp-ocaml
lsp-nix lsp-nim l= sp-markdown lsp-lua lsp-kotlin lsp-json lsp-javascript
lsp-haxe lsp-groo= vy lsp-hack lsp-go lsp-completion lsp-gdscript
lsp-fsharp lsp-fortran ls= p-eslint lsp-erlang lsp-elixir lsp-elm
lsp-dockerfile lsp-dhall lsp-d ls= p-css lsp-csharp lsp-crystal lsp-cmake
lsp-clojure lsp-clangd dom lsp-be= ancount lsp-bash lsp-angular lsp-ada
lsp-actionscript winner tramp-archi= ve tramp-gvfs dbus helm-x-files
helm-for-files helm-bookmark helm-adapti= ve helm-info helm-external
helm-net xml aggressive-indent company-oddmus= e company-keywords
company-etags company-gtags company-dabbrev-code comp= any-dabbrev
company-files company-clang company-capf company-cmake compa= ny-semantic
company-template company-bbdb company-tng company rainbow-de= limiters
rainbow-mode page-break-lines display-line-numbers linum init b= eacon
centaur-tabs centaur-tabs-interactive centaur-tabs-functions
ce= ntaur-tabs-elements powerline powerline-separators powerline-themes
high= light-parentheses smartparens-config smartparens-javascript
smartparens-= rst smartparens-org smartparens-markdown smartparens-text
smartparens-c = smartparens smooth-scrolling sublimity-scroll sublimity
disp-table white= space cap-words superword subword lsp-treemacs
lsp-treemacs-themes treem= acs treemacs-header-line treemacs-compatibility
treemacs-mode treemacs-b= ookmarks treemacs-interface treemacs-extensions
treemacs-mouse-interface= treemacs-tags treemacs-persistence
treemacs-filewatch-mode treemacs-fol= low-mode treemacs-rendering
treemacs-async treemacs-workspaces treemacs-= dom treemacs-visuals
treemacs-fringe-indicator treemacs-scope pulse tree= macs-faces
treemacs-icons treemacs-themes treemacs-core-utils pfuture hl= -line
treemacs-logging treemacs-customization treemacs-macros lsp-origam= i
lsp-ui lsp-ui-flycheck lsp-ui-doc xwidget image-mode exif magit-bookma= rk
bookmark goto-addr lsp-ui-imenu lsp-ui-peek lsp-ui-sideline face-rema= p
lsp-ui-util lsp-mode lsp-protocol spinner network-stream nsm
markdo= wn-mode inline ewoc origami origami-parsers helm-mode helm-config
helm-s= woop helm-rg pcase helm-projectile helm-files helm-tags
helm-buffers hel= m-occur helm-locate helm-types projectile grep ibuf-ext
ibuffer ibuffer-= loaddefs helm-flycheck flycheck-inline csproj-mode
org-cliplink org-clip= link-transport org-cliplink-string em-glob esh-util
zoom ws-butler volat= ile-highlights visual-fill-column vlf-setup vlf
vlf-base vlf-tune visibl= e-mark undo-tree smart-yank restart-emacs
desktop frameset rainbow-block= s org-super-agenda ts org-habit org-agenda
org-refile org-noter org-elem= ent avl-tree org ob ob-tangle ob-ref ob-lob
ob-table ob-exp org-macro or= g-footnote org-src ob-comint org-pcomplete
org-list org-faces org-entiti= es noutline outline org-version
ob-emacs-lisp ob-core ob-eval org-table = ol org-keys org-compat org-macs
org-loaddefs cal-menu calendar cal-loadd= efs omnisharp
omnisharp-unit-test-actions omnisharp-code-structure
om= nisharp-server-installation gnutls omnisharp-format-actions
omnisharp-so= lution-actions omnisharp-helm-integration helm-grep
helm-regexp helm-uti= ls helm-help helm helm-global-bindings helm-easymenu
helm-source helm-mu= lti-match helm-lib omnisharp-navigation-actions
omnisharp-current-symbol= -actions omnisharp-auto-complete-actions
omnisharp-server-actions omnish= arp-http-utils omnisharp-utils
omnisharp-server-management omnisharp-set= tings f s flycheck find-func
etags fileloop generator xref project popup= ido csharp-mode
csharp-compilation cc-langs json-mode json-reformat jso= n-snatcher js
cc-mode cc-fonts cc-guess cc-menus cc-cmds cc-styles cc-al= ign cc-engine
cc-vars cc-defs multiple-cursors mc-separate-operationsrectangular-region-mode mc-mark-pop mc-edit-lines
mc-hide-unmatched-lin= es-mode mc-mark-more mc-cycle-cursors
multiple-cursors-core advice rect = magit-submodule magit-obsolete
magit-blame magit-stash magit-reflog magi= t-bisect magit-push magit-pull
magit-fetch magit-clone magit-remote magi= t-commit magit-sequence
magit-notes magit-worktree magit-tag magit-merge= magit-branch
magit-reset magit-files magit-refs magit-status magit magi= t-repos
magit-apply magit-wip magit-log which-func imenu magit-diff smer= ge-mode
diff diff-mode git-commit log-edit message rmc puny rfc822 mml m= ml-sec
epa derived epg epg-config gnus-util rmail rmail-loaddefs mm-deco= de
mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045 mm-util
iet= f-drums mail-prsvr mailabbrev mail-utils gmm-utils mailheader
pcvs-util = add-log magit-core magit-autorevert autorevert filenotify
magit-margin m= agit-transient magit-process with-editor server magit-mode
transient mag= it-git magit-section magit-utils crm hydra lv hungry-delete
hl-todo god-= mode free-keys fireplace dashboard dashboard-widgets time
recentf tree-w= idget wid-edit cmake-mode rst compile text-property-search
crux tramp tr= amp-loaddefs trampver tramp-integration files-x
tramp-compat shell pcomp= lete comint ansi-color parse-time iso8601
time-date ls-lisp format-spec = thingatpt edmacro kmacro avy ring
sanityinc-tomorrow-night-theme color-t= heme-sanityinc-tomorrow color
all-the-icons all-the-icons-faces data-mat= erial data-weathericons
data-octicons data-fileicons data-faicons data-a= lltheicons
async-bytecomp async flyspell ispell req-package view req-pac= kage-cycles
req-package-args req-package-hooks ht log4e dash el-get
e= l-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
e= l-get-github-zip el-get-github-tar el-get-http-zip el-get-http-tar
el-ge= t-hg el-get-go el-get-git-svn el-get-fink el-get-emacswiki
el-get-http e= l-get-notify el-get-emacsmirror el-get-github el-get-git
el-get-elpa el-= get-darcs el-get-cvs el-get-bzr el-get-brew
el-get-builtin el-get-apt-ge= t el-get-recipes el-get-byte-compile
el-get-custom el-get-core autoload = radix-tree lisp-mnt dired
dired-loaddefs use-package use-package-ensure = use-package-delight
use-package-diminish use-package-bind-key bind-key e= asy-mmode
use-package-core cl cemacs-utility finder-inf info package bro= wse-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 e= ieio
eieio-core eieio-loaddefs password-cache json map url-vars comp
= comp-cstr warnings subr-x rx cl-seq cl-macs cl-extra help-mode seq
byte-= opt gv cl-loaddefs cl-lib bytecomp byte-compile cconv iso-transl
tooltip= eldoc electric uniquify ediff-hook vc-hooks lisp-float-type
mwheel term= /pgtk-win pgtk-win term/common-win tool-bar dnd fontset image
regexp-opt= fringe tabulated-list replace newcomment text-mode elisp-mode
lisp-mode= prog-mode register page tab-bar menu-bar rfn-eshadow isearch
easymenu t= imer select scroll-bar mouse jit-lock font-lock syntax
font-core term/tt= y-colors frame minibuffer cl-generic cham georgian
utf-8-lang misc-lang = vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 he= brew greek romanian slovak czech european
ethiopic indian cyrillic chine= se composite charscript charprop
case-table epa-hook jka-cmpr-hook help = simple abbrev obarray
cl-preloaded nadvice button loaddefs faces cus-fac= e macroexp files
window text-properties overlay sha1 md5 base64 format e= nv code-pages
mule custom widget hashtable-print-readable backquote thre= ads
xwidget-internal dbusbind inotify dynamic-setting font-render-settin= g
cairo move-toolbar gtk x-toolkit pgtk lcms2 multi-tty
make-network-= process native-compile emacs)

Memory information:
((conses 16 136= 6260 1278287)
=C2=A0(symbols 48 71661 1845)
=C2=A0(strings 32 821605 = 302207)
=C2=A0(string-bytes 1 15366299)
=C2=A0(vectors 16 808670)
= =C2=A0(vector-slots 8 8340068 966354)
=C2=A0(floats 8 3607 3481)
=C2= =A0(intervals 56 38157 23043)
=C2=A0(buffers 992 69))
--000000000000f5644105c5d6f473-- From debbugs-submit-bounces@debbugs.gnu.org Wed Jun 30 09:00:54 2021 Received: (at 49261) by debbugs.gnu.org; 30 Jun 2021 13:00:54 +0000 Received: from localhost ([127.0.0.1]:56746 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lyZpl-0000vs-Mi for submit@debbugs.gnu.org; Wed, 30 Jun 2021 09:00:53 -0400 Received: from quimby.gnus.org ([95.216.78.240]:57484) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lyZpj-0000vc-GN for 49261@debbugs.gnu.org; Wed, 30 Jun 2021 09:00:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=376eGr48CSyF1DKocNQJi2TyXYIShlw+aPsuZeOUL/E=; b=mXufud73Pq2g6wZXMGVHG5c0+X YtJvujT7q/lVIi9Vm4uvayc+ctEa4YfuZbI8vHKpJQLbtYGsj3KnicSlstBTXfZ6clQBUv79MiJ25 pFXNRKUdbE7qCHRAYMXcvPL/06pnGK01qV1WY/jneH4yNXbjzqgAGUjCVQrE2YAlN/Tk=; Received: from cm-84.212.220.105.getinternet.no ([84.212.220.105] helo=elva) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lyZpa-0001pw-5A; Wed, 30 Jun 2021 15:00:44 +0200 From: Lars Ingebrigtsen To: Mallchad Skeghyeph Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: X-Now-Playing: Jim O'Rourke's _To Magnetize Money and Return a Roving Eye (2)_: "To Magnetize Money and Return a Roving Eye pt2" Date: Wed, 30 Jun 2021 15:00:41 +0200 In-Reply-To: (Mallchad Skeghyeph's message of "Mon, 28 Jun 2021 18:38:16 +0100") Message-ID: <87o8bn7bie.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Mallchad Skeghyeph writes: > I've found for a little while now that a few default behaviors of GNU > emacs pollutes directories. Yes, this is a question that comes up from time to time, and I don't think we've documented in a comprehensive way how to make Emacs not write anything in the directories it visits. Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49261 Cc: 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Mallchad Skeghyeph writes: > I've found for a little while now that a few default behaviors of GNU > emacs pollutes directories. Yes, this is a question that comes up from time to time, and I don't think we've documented in a comprehensive way how to make Emacs not write anything in the directories it visits. For auto-save files, that's auto-save-file-name-transforms. For backup files, that's backup-directory-alist. For lock files, they can be switched off with create-lockfiles. Would it make sense to allow the user to control where the lockfiles are written? The lockfiles are symlinks, so it should theoretically be possible to have them elsewhere without being any racier than the code currently is, I think. Any opinions? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Wed Jun 30 09:26:27 2021 Received: (at 49261) by debbugs.gnu.org; 30 Jun 2021 13:26:27 +0000 Received: from localhost ([127.0.0.1]:56893 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lyaEV-0003ud-KK for submit@debbugs.gnu.org; Wed, 30 Jun 2021 09:26:27 -0400 Received: from eggs.gnu.org ([209.51.188.92]:34320) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lyaEU-0003uN-L6 for 49261@debbugs.gnu.org; Wed, 30 Jun 2021 09:26:26 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:38146) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lyaEP-00075S-Df; Wed, 30 Jun 2021 09:26:21 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3381 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lyaEO-0004hM-Hi; Wed, 30 Jun 2021 09:26:21 -0400 Date: Wed, 30 Jun 2021 16:26:22 +0300 Message-Id: <83k0mbmqkh.fsf@gnu.org> From: Eli Zaretskii To: Lars Ingebrigtsen In-Reply-To: <87o8bn7bie.fsf@gnus.org> (message from Lars Ingebrigtsen on Wed, 30 Jun 2021 15:00:41 +0200) Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: <87o8bn7bie.fsf@gnus.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49261 Cc: ncaprisunfan@gmail.com, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Lars Ingebrigtsen > Date: Wed, 30 Jun 2021 15:00:41 +0200 > Cc: 49261@debbugs.gnu.org > > Would it make sense to allow the user to control where the lockfiles are > written? Yes, I think so. But it is not as trivial as it could sound, because... > The lockfiles are symlinks, so it should theoretically be > possible to have them elsewhere without being any racier than the code > currently is, I think. ...even if the lock files are symlinks (which they not necessarily are), we need to handle the case of several files with identical basenames in different directories. (Their being symlinks is unimportant, because the target of the symlink doesn't exist.) From debbugs-submit-bounces@debbugs.gnu.org Wed Jun 30 10:08:17 2021 Received: (at 49261) by debbugs.gnu.org; 30 Jun 2021 14:08:17 +0000 Received: from localhost ([127.0.0.1]:58378 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lyasz-0003UM-5Q for submit@debbugs.gnu.org; Wed, 30 Jun 2021 10:08:17 -0400 Received: from quimby.gnus.org ([95.216.78.240]:58498) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lyasu-0003Tu-3l for 49261@debbugs.gnu.org; Wed, 30 Jun 2021 10:08:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=J8mt1KLrtvGAZxK6kyxOBYtkq4qOdt2s4D3oLdHANPc=; b=BULcxkENCcXTVBogZRkg1PuD6N UIj4krLNJLmbK3yxE3IKEkvtRaae7TCVGUq4x24jMKSTifYMB5RVWyeaqq5lc5F726OfDHE5ByHKc oISlbDMpuhRvb3B0RqRGjiD3WJME40vLjK2ZOJFrcxOwChEQz7OpVL4AsKC0JW+7KcUo=; Received: from cm-84.212.220.105.getinternet.no ([84.212.220.105] helo=elva) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lyasj-0002XM-Jj; Wed, 30 Jun 2021 16:08:05 +0200 From: Lars Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: <87o8bn7bie.fsf@gnus.org> <83k0mbmqkh.fsf@gnu.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAGFBMVEUgEhLHDBHMKSz8 9PPhfoHno6PCJin////jDEKiAAAAAWJLR0QHFmGI6wAAAAd0SU1FB+UGHg4CNzXOHxoAAAGESURB VDjLbZTNbcMwDIVloAtIsH1X3C4QWgMIRgewjfSeBt1/hfJPolQ3ByHQY0h+j1Sc6z+ePwtAd/t5 HiKEc+2CPwAyXXs/7uV24MgN0hNPUvn2zVIkPAAiCwPVyqKMO6mQopckGwdNu6oAdxX8CTsdURRs 4kuFQHeYQgTKQMKMBb5LCm2ChSlZitIESFNrTVFjiBhTKMd8cswpHN7/NCmSHmKocHCKOzexqiCw fsLfRWni0BGgP0RYSjOHzGbCKgFKe8yB/QYMfGcVduNA4WUc0HAMaJJZITFB5mFWBLHrEUVoUwBQ BeZwTQqMuXMTh+6SOj5GH3LlYBCxa+s4nHaalb9yOF4x/7hwEGE/D68LN9h+2MxEsJHqzKIKLQd9 G1PUhW7Hjo29YC2brnbNDEl912ckZbbccgjhyYTtXqkQUmemClP+j8M1+1Fn5gr6n/W9qWApZIe0 q4GtUMcnEpYqNI4vO6lVCPYCnqTaPwg/77Hn0PVNFw4n1t0uHM72o77pX7l2dIu40r9MAAAAJXRF WHRkYXRlOmNyZWF0ZQAyMDIxLTA2LTMwVDE0OjAyOjU1KzAwOjAwlmkouwAAACV0RVh0ZGF0ZTpt b2RpZnkAMjAyMS0wNi0zMFQxNDowMjo1NSswMDowMOc0kAcAAAAASUVORK5CYII= X-Now-Playing: Orchestral Manoeuvres in the Dark's _Souvenir (3): Unreleased Archives Vol 1_: "Cajun Moon" Date: Wed, 30 Jun 2021 16:08:01 +0200 In-Reply-To: <83k0mbmqkh.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 30 Jun 2021 16:26:22 +0300") Message-ID: <87tulf30ou.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Eli Zaretskii writes: >> The lockfiles are symlinks, so it should theoretically be >> possible to have them elsewhere without being any racier than the code >> currently is, I think. > > ...even if the lock files are symli [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49261 Cc: ncaprisunfan@gmail.com, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: >> The lockfiles are symlinks, so it should theoretically be >> possible to have them elsewhere without being any racier than the code >> currently is, I think. > > ...even if the lock files are symlinks (which they not necessarily > are), we need to handle the case of several files with identical > basenames in different directories. We could perhaps reuse the auto-save file name logic? I.e., extend `make-auto-save-file-name' so that we can use it to compute the lock file names, too. Or just use the UNIIFY logic from auto-save-file-name-transforms unconditionally... > (Their being symlinks is unimportant, because the target of the > symlink doesn't exist.) Right; I'd forgotten that we just use the lock symlink to stash some extra data about the locking Emacs process. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Wed Jun 30 12:07:52 2021 Received: (at 49261) by debbugs.gnu.org; 30 Jun 2021 16:07:52 +0000 Received: from localhost ([127.0.0.1]:58571 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lycki-0006VF-2q for submit@debbugs.gnu.org; Wed, 30 Jun 2021 12:07:52 -0400 Received: from mout.gmx.net ([212.227.15.15]:43869) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lyckf-0006Uz-Nx for 49261@debbugs.gnu.org; Wed, 30 Jun 2021 12:07:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1625069263; bh=v5YP+4cWCRKca7hITsDCtQ4UGqlm9w/em6cm/9uhjm4=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=hgzcTYml7Xy0du+5sFOruyLGszjPJmy+9PBvE4AD2mnolTAYw/M6X96E3VNHf1OPN XKGh7jO3sY+Bs0fZfg+lZByH41ADGVuQ9Zn1qwIbOqLe8uxD/cbtey0i9QCSv6Y4g+ XVq/0c2bChwV2+M5gKQX3ciffMMvkBi97Nizzo9k= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from gandalf.gmx.de ([213.220.147.177]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MAOJV-1m65fp3mlX-00BseU; Wed, 30 Jun 2021 18:07:43 +0200 From: Michael Albinus To: Eli Zaretskii Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: <87o8bn7bie.fsf@gnus.org> <83k0mbmqkh.fsf@gnu.org> Date: Wed, 30 Jun 2021 18:07:41 +0200 In-Reply-To: <83k0mbmqkh.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 30 Jun 2021 16:26:22 +0300") Message-ID: <87tulfxrn6.fsf@gmx.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:WUz3e/A3DheI5dyp82sdHBIbihHL94qxT+KH70eudqfFKKKuvM9 g3XT7QRvEGcucyttudmOMVGJKk3z1lzHne6l8Ml3fsI3AMtkADcz+rujFGePpvyzw/P/Odg 0uZYbBRMfYW3xGYsRBudJi3SwlZA8rFCGReyJ2G8yCFe0sJriuoUDV13sHfTYENvIat/ntg BL5AqsLeiPOAKZdWN3+DA== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:MJKOw3+sS+c=:5SUYLNYoTz95r4rFHagvjC 2E5uY+uUhlBxVtROu/+RGSrMomiOFha1TUiU4i9BFpeX9uCDbnRrD9oQcDuAUoQGRInZnpcIO 84rxYsC/AzYPRcq384y3chn04ennshHrLvHC5hjRDJTSCR/iouaYwG+p0sbrwQ89JAFTRoPQ7 X0V1yH31ImP10Q+0TBFM4gyW3Bsr35bHuggXyhC7T65iBKt9maBT3C4VWBH/7r8Q2u9Rvbyhy nRG5Cuj7BwNxKloqFQf9rYRHD1ElJXJ7NUrLgWUC8odzAbxlXtHojuioW7Q2YyvkWkOXkjpe4 qcGPoPeMr5WpeLIwRALeE74ouzEC+R+Shkdo+1w2A+TRpoNHASIS2u08VRmM1P14KhnKxcQ1C CaHKHC2AtY4xJ2gvtvLkSL3dgfu5X9l8KT7y76fEW9z6oHW5NrKlldPZq2pscnPJ8VQuQTCFJ NVFXkasnTRgv72t4RYs6mR90O7J590YiI9dE5Ru6MQMdjWTM0BoHYIHFhMSJqVB2v0ydnDZgp +lMv9woHqXNTeD5gpnxZ4ebkjMTU+5RaM7BPuiTXnfVf/RJmA9idR0lqkMA9tX80/dwb0esia QTWLzrGBLsMRrhz9sEmgsrBL+YkvPn+szXrhGIvkAPO1Mo2m7SZSnUNv7QGuXPoYnR2Qq8jzB Jr9CTKsZOD+KIeUZ2ugh2qvicutrpvpExH7NwDqpoy28lWGJ+mF2ZvmzNukMcDYDYa1qzOCkr IPWJMI+QQ3G7K7jRIUrXJHd4D4wHADasRZCavUXlqeVobgb2LPBQCsU+QQXpsttJk4XoYCcOv KXMLCKIk9JQcIwKKTDwQWgVKWPTrsnNfd3dNG1gWYKj1/fP5pbJjSTyG+z4kvfQ93cXSYsyAg 7jF2tG2ZHCTfHf3IaQJBsjXyeH3ie4S+ZOO96CXlCt5laLy/6kt3Ldyr/7n2dAzckQ6wOw3wo oL4eCf35HupL4+24l3QTvLvAsrBmi4tz8timJdhN5OqCvk8F9mAsXeKKCVZHRPAbHY4HYcOZI 1cM63i40MeiRz+ODbcn4cPzFp1N4UCrYe++i6GSa9E40KNlaJ1o8AcvoKY4d2cIfJMS/UtsaV 7kgTcvgt0NZ/wplZIc7KuHWNIc9JjE2p+ef+6sRT0C9QxXVPPwNQ9dVsw== X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 49261 Cc: Lars Ingebrigtsen , ncaprisunfan@gmail.com, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: Hi Eli, >> Would it make sense to allow the user to control where the lockfiles are >> written? > > Yes, I think so. But it is not as trivial as it could sound, > because... > >> The lockfiles are symlinks, so it should theoretically be >> possible to have them elsewhere without being any racier than the code >> currently is, I think. > > ...even if the lock files are symlinks (which they not necessarily > are), we need to handle the case of several files with identical > basenames in different directories. (Their being symlinks is > unimportant, because the target of the symlink doesn't exist.) And there is the case of remote files. Do we want locking of remote files? Should the respective lock file be local (better for performance) or also remote (better for locking a file being accessed from different Emacsen somewhere)? Best regards, Michael. From debbugs-submit-bounces@debbugs.gnu.org Wed Jun 30 12:17:20 2021 Received: (at 49261) by debbugs.gnu.org; 30 Jun 2021 16:17:20 +0000 Received: from localhost ([127.0.0.1]:58580 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lyctd-0006jp-6M for submit@debbugs.gnu.org; Wed, 30 Jun 2021 12:17:20 -0400 Received: from eggs.gnu.org ([209.51.188.92]:49856) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lyctb-0006jH-V6 for 49261@debbugs.gnu.org; Wed, 30 Jun 2021 12:17:04 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:44266) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lyctW-00071n-2T; Wed, 30 Jun 2021 12:16:58 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2127 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lyctV-0004QQ-Mh; Wed, 30 Jun 2021 12:16:58 -0400 Date: Wed, 30 Jun 2021 19:16:59 +0300 Message-Id: <835yxvmio4.fsf@gnu.org> From: Eli Zaretskii To: Michael Albinus In-Reply-To: <87tulfxrn6.fsf@gmx.de> (message from Michael Albinus on Wed, 30 Jun 2021 18:07:41 +0200) Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: <87o8bn7bie.fsf@gnus.org> <83k0mbmqkh.fsf@gnu.org> <87tulfxrn6.fsf@gmx.de> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49261 Cc: larsi@gnus.org, ncaprisunfan@gmail.com, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > From: Michael Albinus > Cc: Lars Ingebrigtsen , ncaprisunfan@gmail.com, > 49261@debbugs.gnu.org > Date: Wed, 30 Jun 2021 18:07:41 +0200 > > And there is the case of remote files. Do we want locking of remote > files? I think we do. maybe as an opt-in behavior? > Should the respective lock file be local (better for performance) or > also remote (better for locking a file being accessed from different > Emacsen somewhere)? Remote, I think, otherwise the lock can be easily ignored from another machine. From debbugs-submit-bounces@debbugs.gnu.org Wed Jun 30 16:04:26 2021 Received: (at 49261) by debbugs.gnu.org; 30 Jun 2021 20:04:26 +0000 Received: from localhost ([127.0.0.1]:58807 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lygRd-0003nf-SJ for submit@debbugs.gnu.org; Wed, 30 Jun 2021 16:04:26 -0400 Received: from relay4-d.mail.gandi.net ([217.70.183.196]:56217) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lygRc-0003nO-EG for 49261@debbugs.gnu.org; Wed, 30 Jun 2021 16:04:24 -0400 Received: (Authenticated sender: juri@linkov.net) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id C19DCE000A; Wed, 30 Jun 2021 20:04:17 +0000 (UTC) From: Juri Linkov To: Lars Ingebrigtsen Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains Organization: LINKOV.NET References: <87o8bn7bie.fsf@gnus.org> Date: Wed, 30 Jun 2021 22:31:33 +0300 In-Reply-To: <87o8bn7bie.fsf@gnus.org> (Lars Ingebrigtsen's message of "Wed, 30 Jun 2021 15:00:41 +0200") Message-ID: <87czs3b2ia.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 49261 Cc: Mallchad Skeghyeph , 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > For auto-save files, that's auto-save-file-name-transforms. > For backup files, that's backup-directory-alist. > For lock files, they can be switched off with create-lockfiles. > > Would it make sense to allow the user to control where the lockfiles are > written? The lockfiles are symlinks, so it should theoretically be > possible to have them elsewhere without being any racier than the code > currently is, I think. > > Any opinions? This is a real problem. To avoid syncing temporary files, it's easy to add a pair of lines for every such directory: (add-to-list 'auto-save-file-name-transforms '("\\`/dir1/dir2/.*" "/tmp/" t)) (add-to-list 'backup-directory-alist '("\\`/dir1/dir2/.*" . "/tmp/")) Then it creates temporary files whose names contain absolute paths: /tmp/!dir1/dir2!file~ /tmp/#!dir1/dir2!file# But currently no way to do the same for lock files, so need to take care not to forget to add the same pattern in every .stignore in every sync directory to ignore lock files that is extra trouble: .#* From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 01 06:56:07 2021 Received: (at 49261) by debbugs.gnu.org; 1 Jul 2021 10:56:07 +0000 Received: from localhost ([127.0.0.1]:59667 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lyuMZ-0005ab-GD for submit@debbugs.gnu.org; Thu, 01 Jul 2021 06:56:07 -0400 Received: from quimby.gnus.org ([95.216.78.240]:38976) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lyuMW-0005a1-Mx for 49261@debbugs.gnu.org; Thu, 01 Jul 2021 06:56:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=/ePxmfCNZP3NgmmuYphDkdPDAdRVJFyTXgmUdBZeNBI=; b=ZKYuNmFELgsQTsOIBIc2grAaMW EvndJQLH0+5OJgyd+EJ/o5Yx6BI7aZgvw6iji9RGP82m4tC+alrncBIVYM/Gm4gc7S8Nj/ZlTc3oe 0sHwLOpa2O1E5g31I1Q31Bzszl9utsmqKF+yEQ509+W0MCOHF7XPcU/qBqyQI8oY07sI=; Received: from cm-84.212.220.105.getinternet.no ([84.212.220.105] helo=elva) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lyuMN-0003px-Sg; Thu, 01 Jul 2021 12:55:57 +0200 From: Lars Ingebrigtsen To: Mallchad Skeghyeph Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: <87o8bn7bie.fsf@gnus.org> <83k0mbmqkh.fsf@gnu.org> <87tulf30ou.fsf@gnus.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAElBMVEUaCwpdNjCYZVm7 iXbpyrf///+ul/arAAAAAWJLR0QF+G/pxwAAAAd0SU1FB+UHAQo0NvnGeFwAAAGYSURBVDjLddOL lasgEAbgIWmAGW8BwqQAEQu4Efqvaf/BrBF1OTlG+Q7zECQi8uTIeWrDs2P6Dk+8PTLmj0C/j/jH 3YFYdnAk8z4vMbLfVygjtv0ca87hk8QF5RYXV9Gl5DmOVpmtCCK4E4TJtdYcw2MierC3ylCzRtUF UOIsb4RFHVtLmjUbrJL1/amsZUZei1RYiv4/tqa5FkBSLdF3UG2UYX6VQFdYZ7nAVuyCClIHg9bF AOF6eNQGlid0ybnlaBC7nWDrrs6vBscl/K9Vpfa2ehgacC5z6CFsoPkM0WJljnqCwC39HDRKBzG0 LCXgxnUQmV+1lBxH7NIRsMmutdL1vYG3YCudwITQ+HgFbLHTdJqn9Vu9P+yUUN2Os+EcD21TTTvQ d4UASgN3hcUOJeEyjnHAB4Ujm8ZhA+8wP9EUKCVRSjQ9P2Df0MsDdEQ9iYLsK5DlvcEAEKtq8S2U 83GKNKYGT4PsbZZ9CAEf4jMI+tyArsO5P4ABpdwsmGzFDeBtAyrdDQcId/MMyDciGVDyeVcJ5/IH 9yBR8BjwudoAAAAldEVYdGRhdGU6Y3JlYXRlADIwMjEtMDctMDFUMTA6NTI6NTQrMDA6MDCr4K+W AAAAJXRFWHRkYXRlOm1vZGlmeQAyMDIxLTA3LTAxVDEwOjUyOjU0KzAwOjAw2r0XKgAAAABJRU5E rkJggg== X-Now-Playing: Jane Siberry's _Bound By The Beauty_: "Half Angel Half Eagle" Date: Thu, 01 Jul 2021 12:55:55 +0200 In-Reply-To: (Mallchad Skeghyeph's message of "Wed, 30 Jun 2021 19:51:56 +0100") Message-ID: <87bl7m2thg.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: (Please keep the debbugs address in the CCs -- otherwise the message won't reach the bug tracker.) Mallchad Skeghyeph writes: > ...even if the lock files are symlinks (which they not necessarily > are), we need to handle the case of several files with identical > basenames in different directories. (Their being symlinks is > [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49261 Cc: 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) (Please keep the debbugs address in the CCs -- otherwise the message won't reach the bug tracker.) Mallchad Skeghyeph writes: > ...even if the lock files are symlinks (which they not necessarily > are), we need to handle the case of several files with identical > basenames in different directories. (Their being symlinks is > unimportant, because the target of the symlink doesn't exist.) > > Actually, is there even a good reason to keep relying on symlinks in the future? > Considering that.. ahem, some Operating Systems cannot do symlinks for the > user? > If it were treated as a normal file you could load it up with whatever metadata > you want. Using a normal file should also work, I think? But it'd be slightly less efficient on some common popular file systems. > Or just use the UNIIFY logic from auto-save-file-name-transforms > unconditionally... > > It seems most of `make-auto-save-file-name` makes very little assumptions > about how we're modifying the file, actually, > so it shouldn't be too too problematic to make it work for both. > Though, I would like an optional single variable for a directory for both, > as oppose to a slightly opaqueregex. > > Remote, I think, otherwise the lock can be easily ignored from another > machine. > > Yes. I think we need to keep compatibility with the current lock, if its noticed. > Remote or local. > In the case of remote files, we'd have to assume others might be using the > current > lock behaviour. Remote files are a problem, but what to do here would be up to the user (as it is with autosave files). From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 01 07:38:23 2021 Received: (at 49261) by debbugs.gnu.org; 1 Jul 2021 11:38:23 +0000 Received: from localhost ([127.0.0.1]:59687 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lyv1T-0000ST-Bi for submit@debbugs.gnu.org; Thu, 01 Jul 2021 07:38:23 -0400 Received: from quimby.gnus.org ([95.216.78.240]:39396) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lyv1Q-0000SE-6Z for 49261@debbugs.gnu.org; Thu, 01 Jul 2021 07:38:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=FAa4+uIEnQEL/J7nTCpXYECj0mJF3mE8xY+f+DSD35o=; b=rPm+K7rJxlrl50pRveulBFU/8V h0w2pO7mmnCaMNeQ9tdqDI44kx1C6R2jnQ3vdfZ8Av2fxIfM122XLqg+UOVWu3PtAg/3UQN/8/VOk 6obEGC3CXPjgFukajQ8qDJWLuAgeDHprl5SSThWN7j0ybrlR9LFyzSK9vb1RPVS3MTKI=; Received: from cm-84.212.220.105.getinternet.no ([84.212.220.105] helo=elva) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lyv1G-0004Bt-Sm; Thu, 01 Jul 2021 13:38:13 +0200 From: Lars Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: <87o8bn7bie.fsf@gnus.org> <83k0mbmqkh.fsf@gnu.org> <87tulfxrn6.fsf@gmx.de> <835yxvmio4.fsf@gnu.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAElBMVEUgCA9THyGdZ1Zq S0jTvbf///8dkPdbAAAAAWJLR0QF+G/pxwAAAAd0SU1FB+UHAQsMIBtPG8EAAAG2SURBVDjLdZRr FuMgCIXhZAMSN1AxC/DRDYx1/2sawGhq54w/mlO+IHC9BuBrnc4BOCDQ5/c6ggUEUN0J2S8qWTE/ w0C1pLziWGRv+4ucgcY7RORZAFYtgefnTkbytfQrCldAhcMA5C/m3jtncijFSsgwuitX19U4G+AX gFUj7mO1bDU4zUavG3SuWv79L/ggJektOvR5z3DS11EJ8MANtExLlB1EP2WRJz6g8wS1ahpvAJfM WL5ABhTRKBs5x1589aZAkshqAF7WUYlX88nEtgxJPSUuUnbWDAGi99321SOdfLV2io4royZ4S1kX ubdC4NMRLANLENAKNykuolA4E6ks5BVIzDrjUGrOuhXqSa7ZQ3aivFaRc+npAUmPHW0OLM0t8IHh BxuwRFjgpVONFBEkPCANCW1qQJFnljCbLHPCfwA8oNUfMGsoSFsGTzPADo55gBmO/ZIR1QnSXoS8 uTqMAb+KkJ1ufIkP0+HrfWtF+bfuFEWSI3HJZiu14mzKFEw6yugBHw1Xn+MxHffnF3i+L9sPQLmo g9in5PGuxNd53IOoe0is1h8wXjanlucavGwDp+AvqG13L9fgKPcAAAAldEVYdGRhdGU6Y3JlYXRl ADIwMjEtMDctMDFUMTE6MTI6MzIrMDA6MDBjEDksAAAAJXRFWHRkYXRlOm1vZGlmeQAyMDIxLTA3 LTAxVDExOjEyOjMyKzAwOjAwEk2BkAAAAABJRU5ErkJggg== X-Now-Playing: Jane Siberry's _When I Was A Boy_: "Sweet Incarnadine" Date: Thu, 01 Jul 2021 13:38:10 +0200 In-Reply-To: <835yxvmio4.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 30 Jun 2021 19:16:59 +0300") Message-ID: <87tule1cyl.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Eli Zaretskii writes: >> Should the respective lock file be local (better for performance) or >> also remote (better for locking a file being accessed from different >> Emacsen somewhere)? > > Remote, I think, otherwise th [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49261 Cc: Michael Albinus , ncaprisunfan@gmail.com, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: >> Should the respective lock file be local (better for performance) or >> also remote (better for locking a file being accessed from different >> Emacsen somewhere)? > > Remote, I think, otherwise the lock can be easily ignored from another > machine. Auto-save files are local by default, so they have the same problem (being ignored on other systems). However, lock files are tiny, while auto-save files can be arbitrarily big, so from a practical point of view there's less reason to default lock files to being local. So I agree that having lock files being remote would be a good default. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 01 08:58:33 2021 Received: (at 49261) by debbugs.gnu.org; 1 Jul 2021 12:58:33 +0000 Received: from localhost ([127.0.0.1]:59897 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lywH3-0006w9-7m for submit@debbugs.gnu.org; Thu, 01 Jul 2021 08:58:33 -0400 Received: from eggs.gnu.org ([209.51.188.92]:41754) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lywH1-0006vu-SE for 49261@debbugs.gnu.org; Thu, 01 Jul 2021 08:58:32 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:49794) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lywGw-00061S-GJ; Thu, 01 Jul 2021 08:58:26 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3025 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lywGw-0000mh-3a; Thu, 01 Jul 2021 08:58:26 -0400 Date: Thu, 01 Jul 2021 15:58:21 +0300 Message-Id: <83o8bmkx76.fsf@gnu.org> From: Eli Zaretskii To: Lars Ingebrigtsen In-Reply-To: <87bl7m2thg.fsf@gnus.org> (message from Lars Ingebrigtsen on Thu, 01 Jul 2021 12:55:55 +0200) Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: <87o8bn7bie.fsf@gnus.org> <83k0mbmqkh.fsf@gnu.org> <87tulf30ou.fsf@gnus.org> <87bl7m2thg.fsf@gnus.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49261 Cc: ncaprisunfan@gmail.com, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Lars Ingebrigtsen > Date: Thu, 01 Jul 2021 12:55:55 +0200 > Cc: 49261@debbugs.gnu.org > > Mallchad Skeghyeph writes: > > > ...even if the lock files are symlinks (which they not necessarily > > are), we need to handle the case of several files with identical > > basenames in different directories. (Their being symlinks is > > unimportant, because the target of the symlink doesn't exist.) > > > > Actually, is there even a good reason to keep relying on symlinks in the future? > > Considering that.. ahem, some Operating Systems cannot do symlinks for the > > user? > > If it were treated as a normal file you could load it up with whatever metadata > > you want. > > Using a normal file should also work, I think? But it'd be slightly > less efficient on some common popular file systems. We already use regular files on systems on which symlinks are either unsupported or otherwise problematic. From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 01 12:57:23 2021 Received: (at 49261) by debbugs.gnu.org; 1 Jul 2021 16:57:23 +0000 Received: from localhost ([127.0.0.1]:33613 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lz00B-0007r9-Be for submit@debbugs.gnu.org; Thu, 01 Jul 2021 12:57:23 -0400 Received: from mout.gmx.net ([212.227.15.18]:49603) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lz009-0007qt-0v for 49261@debbugs.gnu.org; Thu, 01 Jul 2021 12:57:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1625158634; bh=LGhparNyHYFQt1ciZQgPP9NB9sLHugk6e9XNU4mB2+k=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=HY0ZJqTZUjk+tOkaY9r6CfW7IGvcab0VTDFVrP1/2KzQ7JqjUmcgkvvmJW31vUc4Z ARm5DuOxzSf9zlB0ysfhQK3Ij1t2OV8zleVdwAxvNg7mTTfFzbMJp/xrRxhKkCSxCH apeGXGVryJ88+J8lyrBklSUJVwQx2YOx787MT+7s= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from gandalf.gmx.de ([213.220.159.163]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1N7zBR-1lCcCg3ip1-0152sJ; Thu, 01 Jul 2021 18:57:14 +0200 From: Michael Albinus To: Lars Ingebrigtsen Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: <87o8bn7bie.fsf@gnus.org> Date: Thu, 01 Jul 2021 18:57:12 +0200 In-Reply-To: <87o8bn7bie.fsf@gnus.org> (Lars Ingebrigtsen's message of "Wed, 30 Jun 2021 15:00:41 +0200") Message-ID: <87zgv6vuon.fsf@gmx.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:HrCnJZebIRZecfA5vq3ip3d/qviF1tVgUu0/H828NXkeyLFmnWf mSH5lEfqCu6NMSAD2LrdSOLws7iJZyVY0dGQlVHSB38P9VY0xHJmu+jnSM5ZdL8n11yGPia J0Bp2hGYkB+e6/AYGob7jWWTcu5SHRu1Ct+NG7O/0Rj4x+bWdwk8bfhx72Po0iSav0Iqby0 Y3wQ65/lqHJwIeE8w4gvg== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:umlmLzzTq2A=:7bnV6O3MF0CVG5k+fgRdvn L8hkNMzap6/Fk2DkrSB+P8XgZ2qyvgkM9Yy1/XqwNapaYsZO7CVdH9lroUwSOWHSeT6BPcksc ErrOWRDXHtnEMQOfcB4thgqslL7AvjZ5mgtePubzHgyMHXNGdSqMGGts+bi1wJE8FwGg5Iz85 lH5PGt6XQINV9uBlhyp3SicVAhAM7zHGkyq864zSGug0X1iekFcMThOD4dqsMM/oN43jJUCp2 tLxpN8WmPMTkeBS8Rugap4QKUNogrR6Y3ZjqJzfj8gRFIAAKdwlGTl5odbbcl1acbYWBubpiS qEcvsI/Rf4cTDQK+iQiOYEwrnv+63MJwmnRAW3S2bV2jaXkN30Y/BXKq6lGNqVbrGGsXIGgMH gXRMvWfEEMmz1UrhgHSZzjYm4SrKFWp3XlZQSfHgUh/R9ucKyBTew+HwwOfmAezhRYYPEXPqw w9qnt7BSgCSCl5cWdvHte5+edDw+uBOaomJJ1e+C8hdwIlYqUZ5d8ND8oZOspTGoCcsVi4+ll GKTPeRYzMK4xnX7PemcaNCqnspd48KFsOgmOwZZPM44kuFT2V6X1s/cjqvJzrifNgDExXH64I t7yBsQgEPGJKgpo/mRUQKaKnf4bSHYXApoGhdaL2lCtm9+ktA6Cae8bjD1rS/PbltjvtGSuzq pREaaGdrTX9O4gix5WEeBIECDvwmiKs8ZeLX31q223fkon0f3/Sc0TFJ0RetXLTp/03bxEkox J/vO16Ck6mNhKkH19LNcTirAwq/FoNcPex9oBIFZNvjP2K2LqojIUhIM0VBVAv9j9KjvYjnAW TXClXhqGtc3S7RFUbylDT7lOUhWogLE4wW7vuSJOqbpoPw/lqFh+wdVdVoZJkVkMuafL0+zAa 3uzjVVNGTg4Jk99iRtb0JtVJFWBL6i+T7QL6Qpf8mbhwslVONS916TGettFfvVqFIpusZVWmH qGtYQgylDWR0qok/t23jtaAGTNnada6cwgQh7Tql4iY0zMzkvDTT1+mkVv7KreUyCOEPUmrg3 54E2ytWbE/z2aXBt3/52pYJW4hopkIjuWlsqN6rXlDM0x29Cw9Db6hOExu9aMVc+4k1u8aLAd 8CBRwFdPi1dZzfVWzOR01aJX7a6P9s1qRcR9ztx6YjXqin2OYleGHtwtw== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 49261 Cc: Mallchad Skeghyeph , 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Lars Ingebrigtsen writes: Hi Lars, > Yes, this is a question that comes up from time to time, and I don't > think we've documented in a comprehensive way how to make Emacs not > write anything in the directories it visits. > > For auto-save files, that's auto-save-file-name-transforms. > For backup files, that's backup-directory-alist. > For lock files, they can be switched off with create-lockfiles. > > Would it make sense to allow the user to control where the lockfiles are > written? The lockfiles are symlinks, so it should theoretically be > possible to have them elsewhere without being any racier than the code > currently is, I think. > > Any opinions? Thinking about, it makes much sense to write the lockfile into the same directory as the file it locks. Think about mounted directories. If there is, for example, an NFS server which exports home directories, and you are editing /home/user/.emacs with different Emacs instances on different machines, where /home/user is mounted, you want to protect ~/.emacs for write access from any Emacs instance when needed. A similar case would be for remote files, where a file could also be locked for access with Emacs from different machines, which use Tramp. Note, that file lock does not exist yet for remote files, but as Eli said, we want this feature. So the very recommended default lock file name shall be what we have now. We could give the user a configuration variable to change this behaviour, but with explicit warning about consequences. Best regards, Michael. From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 01 14:32:10 2021 Received: (at 49261) by debbugs.gnu.org; 1 Jul 2021 18:32:11 +0000 Received: from localhost ([127.0.0.1]:33689 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lz1Tu-00027B-OG for submit@debbugs.gnu.org; Thu, 01 Jul 2021 14:32:10 -0400 Received: from eggs.gnu.org ([209.51.188.92]:44014) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lz1Tt-00026y-BH for 49261@debbugs.gnu.org; Thu, 01 Jul 2021 14:32:09 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:57996) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lz1Tm-000323-RB; Thu, 01 Jul 2021 14:32:03 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3690 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lz1Tm-00017e-Eu; Thu, 01 Jul 2021 14:32:02 -0400 Date: Thu, 01 Jul 2021 21:31:57 +0300 Message-Id: <837di9lwbm.fsf@gnu.org> From: Eli Zaretskii To: Michael Albinus In-Reply-To: <87zgv6vuon.fsf@gmx.de> (message from Michael Albinus on Thu, 01 Jul 2021 18:57:12 +0200) Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: <87o8bn7bie.fsf@gnus.org> <87zgv6vuon.fsf@gmx.de> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49261 Cc: larsi@gnus.org, ncaprisunfan@gmail.com, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Michael Albinus > Date: Thu, 01 Jul 2021 18:57:12 +0200 > Cc: Mallchad Skeghyeph , 49261@debbugs.gnu.org > > So the very recommended default lock file name shall be what we have > now. We could give the user a configuration variable to change this > behaviour, but with explicit warning about consequences. I think this was indeed the intent. There's no intent to change the default behavior wrt where the lock file is written, only to introduce a new opt-in behavior. From debbugs-submit-bounces@debbugs.gnu.org Fri Jul 02 07:06:25 2021 Received: (at 49261) by debbugs.gnu.org; 2 Jul 2021 11:06:25 +0000 Received: from localhost ([127.0.0.1]:35045 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lzH05-0006Ks-3L for submit@debbugs.gnu.org; Fri, 02 Jul 2021 07:06:25 -0400 Received: from quimby.gnus.org ([95.216.78.240]:51996) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lzH00-0006Ke-U4 for 49261@debbugs.gnu.org; Fri, 02 Jul 2021 07:06:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=Sau/RYRQ8aDZx9UtJHBQow0Os5nN+Ra1A24KV5zqrmw=; b=f4HjJ7LxxKUAqyvogrp2efAHI4 uiNFo1aF5IRgKpXddKGqV0zXm4lrjzdHbcHXWF8hQjZ1DszIByMKTz73DtaxPHhXUqrFN12Je4fcC 7BZLnUEGAthiENBQeKiCn2tzpP6S5Up3k75fwFnunzXWbDRulVDR+wKuqwj9+FPdQBVI=; Received: from cm-84.212.220.105.getinternet.no ([84.212.220.105] helo=elva) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lzGzr-0007yD-K3; Fri, 02 Jul 2021 13:06:14 +0200 From: Lars Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: <87o8bn7bie.fsf@gnus.org> <87zgv6vuon.fsf@gmx.de> <837di9lwbm.fsf@gnu.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwAgMAAAAqbBEUAAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAADFBMVEWgemXUx7FTSD// //+Tufv2AAAAAWJLR0QDEQxM8gAAAAd0SU1FB+UHAgo6CLSR55cAAAF1SURBVCjPPZE9TgMxEIWf rbUUXAVkU0eIItpTLCgrAdWCPIiSlls4UWhSUUBvRSBZc0pmvAFri/n85ueNF2jHuJuEUYJri3Vx lOBmAd0mxDsNoqaNEQvI5wwGUCS/lVtrNh9TILKSYm0OSzdMAImSzWbAlIDUhozBvSWYJ2gLMzlM cA+q7AHXSVePNWzwMrx2YORTYXm2jNLsaJ1nMOcGbuoFam5iHLiIwg3olrfohQDvqGeHW27HJS5R 3LUW+YK3hNRn/iJaeXYTXqQqBGKu5wNeC2wkKc+jVTuINMr4tMYSXpWrsrz80XleAB3Rl7wBuOwy jN7s4ZsfRwJZWhcjMArgyMe6MbPixWk1nW0gziqb9Ae72ss0zHDgHl5tCGTZJtvFrBza4mfnCjuJ j8WpAWpvUGo0NDeQuMbxD2rvT6Dk7VJqHkms8Q6HcCNCUqFHfb//r7Hf5ay1lrSj/dRF01xzIMic FDQt14DVqIr+BHmDlQ76BcC8mx4Ms7DKAAAAJXRFWHRkYXRlOmNyZWF0ZQAyMDIxLTA3LTAyVDEw OjU4OjA4KzAwOjAwGkrvvQAAACV0RVh0ZGF0ZTptb2RpZnkAMjAyMS0wNy0wMlQxMDo1ODowOCsw MDowMGsXVwEAAAAASUVORK5CYII= X-Now-Playing: Samuel Goff's _The Wire Tapper 52_: "SnakeBite" Date: Fri, 02 Jul 2021 13:06:11 +0200 In-Reply-To: <837di9lwbm.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 01 Jul 2021 21:31:57 +0300") Message-ID: <87a6n5vuu4.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Eli Zaretskii writes: > I think this was indeed the intent. There's no intent to change the > default behavior wrt where the lock file is written, only to introduce > a new opt-in behavior. Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49261 Cc: Michael Albinus , ncaprisunfan@gmail.com, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: > I think this was indeed the intent. There's no intent to change the > default behavior wrt where the lock file is written, only to introduce > a new opt-in behavior. Yup. I was going to take a stab at implementing this today, but I find that I don't have the time (probably for the next couple of days), so if somebody else wants to take a stab at it, please be my guest. :-) If not, I'll get to it early next week. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Fri Jul 02 08:33:03 2021 Received: (at 49261) by debbugs.gnu.org; 2 Jul 2021 12:33:03 +0000 Received: from localhost ([127.0.0.1]:35204 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lzILv-0006hJ-Ie for submit@debbugs.gnu.org; Fri, 02 Jul 2021 08:33:03 -0400 Received: from mout.gmx.net ([212.227.17.22]:47825) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lzILs-0006gn-Qa for 49261@debbugs.gnu.org; Fri, 02 Jul 2021 08:33:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1625229174; bh=AUJdeK+DLA0ifj5VLgomOujDk78gUepRRa2f1CBss+k=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=DFmEU3+wmQC5tAQFPAjersOIjDj6BBQzdXa6LNUbrbINawIryQAimtm4I/ONpTb4o t3sBBi3npLlRqgIBhIAvgkVsDCoczzZZzIksDXchO2Nct8Tucy2QYBg6sL/qv0JsuA WO8Tw3ULN/i6gtU/kmeBtqNShA+29qMvHwBJjXCg= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from gandalf.gmx.de ([79.140.124.21]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1N17UQ-1lEnMa1B7K-012Uap; Fri, 02 Jul 2021 14:32:54 +0200 From: Michael Albinus To: Lars Ingebrigtsen Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: <87o8bn7bie.fsf@gnus.org> <87zgv6vuon.fsf@gmx.de> <837di9lwbm.fsf@gnu.org> <87a6n5vuu4.fsf@gnus.org> Date: Fri, 02 Jul 2021 14:32:53 +0200 In-Reply-To: <87a6n5vuu4.fsf@gnus.org> (Lars Ingebrigtsen's message of "Fri, 02 Jul 2021 13:06:11 +0200") Message-ID: <87czs0x5e2.fsf@gmx.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:ckld4aa7BUM6nsSY30dWISC4ung2+VvSzRw+FSf9sHqFFiUk8Dx kVQauwiTX7k4cTzWv6SBuwI7vazrLs2OZhRzScxR5D41ATt+0O/tlz98deI6p3AqFW0E5hp 6zxiF++b5bB+zJZlfuU7z/9dRWE5gS2A8jUFrY5w06zcAiTjao4Y2Xm4lLNJQ6sA+RdtBDW 45Hy7vDgcEVAZ0fZZ8FAQ== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:BnmYjr0IRQs=:xNPouTU8oNn//91s1pqLr8 r8p8nbARQAtDHRMWyudcDwytSFXZF9W31yrOVI4p//wyTK9KEp4YrheeCAGGaU6X2rk/80Jgd xIu5pZ2iiyiSgOWj43hrnX9+h0opH6tW9V6yUEr1Am1B/tSxwVjJu5b176INaWHo/arUyFU9G ys1zZrGpYqEigkWHAn0Ih/5gYboiK4zxpEa1ue085NOo7zRVmBZA3eNS3qv+CwWU7n7zSWpXO KKT4vMVcfUMAYScqC1zthLSRKUtvhIll3TRAJ1iith0/7IrZKI2wwPd8R6q8AAd3p6Oh6DqSK 8mHdoWDrAprNQZOJP/fCp9aydEvftsGb0TXybDZyBQoUMh8UrOD+IC1N0EIrjv6IoL/s+ZJ+q lOBtS1NYWD46Vd1LXVDXJoUG+tmECXgaQ6eOaE/M/cMBbTvs8raR6QyeB9om9NsHftDWwFjBa IXlPIlnuG9YI57R4fu4wKTxq5z9/dF898iskxYqSPhFvuJbsQXQEFtK7XS8f9WTt5iZd5Z5sa cYsnLNPjbkCg/2DwbQkzSNeIAklxdwKdT7pxmMrRMKv2RGa7bFLGPioqgoTrUjngmFvt4t4/7 5OA/dDqB3O1emnSXOkN01yzn/hyAD43nLAdmglSZXq6yTHdEoNMjoWujfJ1kfPLKs2jcZ1qm3 6wLY1f56OptbRneBGXiitNwZZR7vlfAlpLLKkc+xXgb3Fqr594AJx5SpJQyq5trmTDatN0IiB Ggz0XzIg46uehl+T7DIog+WGc39UpYknYjEtHDMZVIZZzhpbvyahmUTvzZOo1ug+1ys+J55ma nOkxWsqHCfcC73oXg3a/oDkRGrkvC+k8U6JlaUcXmT7AUm6Kue4CFggUxMJuP8TTTtaYG4LtG 69NUtzOU6T/uurgchIvG8kzUAbPUJgei4yEuA4M4WG0+m/8fNV0xUHkC29HfkrS846MCQH48c Cxx+y75Jep1hOYkd4vA0j58ZANN0Kwr51ARXVrKsATi2spmHVGWH+63e5KnR/1elWfKc/9X1b qHpPkXHhqVZEUQ4GBBUwkZmPoW4COf/UbaJUYbpXriat8+wrYZp2LORjINz7dXo3g2POKDB5q Xh50CElxVafV8MDHN+9FGPWpkR2jHcSquZ1dio7LsqX+a3ngrHLxcupeg== X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 49261 Cc: Eli Zaretskii , ncaprisunfan@gmail.com, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Lars Ingebrigtsen writes: Hi Lars, >> I think this was indeed the intent. There's no intent to change the >> default behavior wrt where the lock file is written, only to introduce >> a new opt-in behavior. > > I was going to take a stab at implementing this today, but I find that I > don't have the time (probably for the next couple of days), so if > somebody else wants to take a stab at it, please be my guest. :-) I've pushed on my TODO to implement file locking for remote files first, which does not exist yet. If nothing breaks my priorities, it should be ready next days. After that, we could see what does it need for configuration. Best regards, Michael. From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 07 12:01:42 2021 Received: (at 49261) by debbugs.gnu.org; 7 Jul 2021 16:01:42 +0000 Received: from localhost ([127.0.0.1]:53304 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m19zZ-0002rd-DD for submit@debbugs.gnu.org; Wed, 07 Jul 2021 12:01:42 -0400 Received: from quimby.gnus.org ([95.216.78.240]:53232) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m19zV-0002rM-Sq for 49261@debbugs.gnu.org; Wed, 07 Jul 2021 12:01:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=xSp6+PT+637dCCD9WPwAWPuh1PwxK94pvmgGo0ezmfo=; b=dAFdaMZ61puNI5aKR4rCww11dh PhzQ92vYWtRw/i1zGcqEtrgI8cfJTh9qa4tnT/p3fcFK3ILu2UR6+TRIj8709wRZ4LLnM8XVcD6s+ lKkG5CoVPL8gi9gHZmUMvfG2A0eC2Kai7mvUooJjLWVykg4IIeElqERcdNVIUcwBbkUk=; Received: from cm-84.212.220.105.getinternet.no ([84.212.220.105] helo=elva) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m19zM-0007at-2E; Wed, 07 Jul 2021 18:01:30 +0200 From: Lars Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: <87o8bn7bie.fsf@gnus.org> <87zgv6vuon.fsf@gmx.de> <837di9lwbm.fsf@gnu.org> <87a6n5vuu4.fsf@gnus.org> X-Now-Playing: Yoko Ono's _Feeling the Space_: "Coffin Car" Date: Wed, 07 Jul 2021 18:01:25 +0200 In-Reply-To: <87a6n5vuu4.fsf@gnus.org> (Lars Ingebrigtsen's message of "Fri, 02 Jul 2021 13:06:11 +0200") Message-ID: <8735sqnmei.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Lars Ingebrigtsen writes: > If not, I'll get to it early next week. Is Wednesday still "early"? Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49261 Cc: Michael Albinus , ncaprisunfan@gmail.com, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Lars Ingebrigtsen writes: > If not, I'll get to it early next week. Is Wednesday still "early"? Anyway, I've now implemented this. The biggest part of this is refactoring out the `auto-save-file-name-transforms' handling so that it can be used by the lock handling code, too. I'd like to have more eyes on this before I commit. It seems to work fine after some light testing, but I'm not completely confident about the ENCODE_FILE/ALLOCA bits in the C code. So if somebody could give that a look-over while I'm writing up the documentation, that'd be great. :-) diff --git a/lisp/files.el b/lisp/files.el index 859c193db9..ba588842a2 100644 --- a/lisp/files.el +++ b/lisp/files.el @@ -412,6 +412,21 @@ auto-save-file-name-transforms :initialize 'custom-initialize-delay :version "21.1") +(defcustom lock-file-name-transforms nil + "Transforms to apply to buffer file name before making a lock file name. +This has the same syntax as +`auto-save-file-name-transforms' (which see), but instead of +applying to auto-save file names, it's applied to lock file names. + +By default, a lock file is put into the same directory as the +file it's locking, and it has the same name, but with \".#\" prepended." + :group 'files + :type '(repeat (list (regexp :tag "Regexp") + (string :tag "Replacement") + (boolean :tag "Uniquify"))) + :initialize 'custom-initialize-delay + :version "28.1") + (defvar auto-save--timer nil "Timer for `auto-save-visited-mode'.") (defcustom auto-save-visited-interval 5 @@ -6668,63 +6683,11 @@ make-auto-save-file-name 'make-auto-save-file-name))) (if handler (funcall handler 'make-auto-save-file-name) - (let ((list auto-save-file-name-transforms) - (filename buffer-file-name) - result uniq) - ;; Apply user-specified translations - ;; to the file name. - (while (and list (not result)) - (if (string-match (car (car list)) filename) - (setq result (replace-match (cadr (car list)) t nil - filename) - uniq (car (cddr (car list))))) - (setq list (cdr list))) - (if result - (setq filename - (cond - ((memq uniq (secure-hash-algorithms)) - (concat - (file-name-directory result) - (secure-hash uniq filename))) - (uniq - (concat - (file-name-directory result) - (subst-char-in-string - ?/ ?! - (replace-regexp-in-string - "!" "!!" filename)))) - (t result)))) - (setq result - (if (and (eq system-type 'ms-dos) - (not (msdos-long-file-names))) - ;; We truncate the file name to DOS 8+3 limits - ;; before doing anything else, because the regexp - ;; passed to string-match below cannot handle - ;; extensions longer than 3 characters, multiple - ;; dots, and other atrocities. - (let ((fn (dos-8+3-filename - (file-name-nondirectory buffer-file-name)))) - (string-match - "\\`\\([^.]+\\)\\(\\.\\(..?\\)?.?\\|\\)\\'" - fn) - (concat (file-name-directory buffer-file-name) - "#" (match-string 1 fn) - "." (match-string 3 fn) "#")) - (concat (file-name-directory filename) - "#" - (file-name-nondirectory filename) - "#"))) - ;; Make sure auto-save file names don't contain characters - ;; invalid for the underlying filesystem. - (if (and (memq system-type '(ms-dos windows-nt cygwin)) - ;; Don't modify remote filenames - (not (file-remote-p result))) - (convert-standard-filename result) - result)))) - + (auto-save--transform-file-name buffer-file-name + auto-save-file-name-transforms + "#" "#"))) ;; Deal with buffers that don't have any associated files. (Mail ;; mode tends to create a good number of these.) - (let ((buffer-name (buffer-name)) (limit 0) file-name) @@ -6772,6 +6735,71 @@ make-auto-save-file-name (file-error nil)) file-name))) +(defun auto-save--transform-file-name (filename transforms + prefix suffix) + "Transform FILENAME according to TRANSFORMS. +See `auto-save-file-name-transforms' for the format of +TRANSFORMS. PREFIX is prepended to the non-directory portion of +the resulting file name, and SUFFIX is appended." + (let (result uniq) + ;; Apply user-specified translations + ;; to the file name. + (while (and transforms (not result)) + (if (string-match (car (car transforms)) filename) + (setq result (replace-match (cadr (car transforms)) t nil + filename) + uniq (car (cddr (car transforms))))) + (setq transforms (cdr transforms))) + (when result + (setq filename + (cond + ((memq uniq (secure-hash-algorithms)) + (concat + (file-name-directory result) + (secure-hash uniq filename))) + (uniq + (concat + (file-name-directory result) + (subst-char-in-string + ?/ ?! + (replace-regexp-in-string + "!" "!!" filename)))) + (t result)))) + (setq result + (if (and (eq system-type 'ms-dos) + (not (msdos-long-file-names))) + ;; We truncate the file name to DOS 8+3 limits + ;; before doing anything else, because the regexp + ;; passed to string-match below cannot handle + ;; extensions longer than 3 characters, multiple + ;; dots, and other atrocities. + (let ((fn (dos-8+3-filename + (file-name-nondirectory buffer-file-name)))) + (string-match + "\\`\\([^.]+\\)\\(\\.\\(..?\\)?.?\\|\\)\\'" + fn) + (concat (file-name-directory buffer-file-name) + prefix (match-string 1 fn) + "." (match-string 3 fn) suffix)) + (concat (file-name-directory filename) + prefix + (file-name-nondirectory filename) + suffix))) + ;; Make sure auto-save file names don't contain characters + ;; invalid for the underlying filesystem. + (if (and (memq system-type '(ms-dos windows-nt cygwin)) + ;; Don't modify remote filenames + (not (file-remote-p result))) + (convert-standard-filename result) + result))) + +(defun make-lock-file-name (filename) + "Make a lock file name for FILENAME. +By default, this just prepends \".*\" to the non-directory part +of FILENAME, but the transforms in `lock-file-name-transforms' +are done first." + (auto-save--transform-file-name filename lock-file-name-transforms ".#" "")) + (defun auto-save-file-name-p (filename) "Return non-nil if FILENAME can be yielded by `make-auto-save-file-name'. FILENAME should lack slashes. diff --git a/src/filelock.c b/src/filelock.c index 446a262a1c..3c6e6b4942 100644 --- a/src/filelock.c +++ b/src/filelock.c @@ -294,25 +294,6 @@ get_boot_time_1 (const char *filename, bool newest) char user[MAX_LFINFO + 1 + sizeof " (pid )" - sizeof "."]; } lock_info_type; -/* Write the name of the lock file for FNAME into LOCKNAME. Length - will be that of FNAME plus two more for the leading ".#", plus one - for the null. */ -#define MAKE_LOCK_NAME(lockname, fname) \ - (lockname = SAFE_ALLOCA (SBYTES (fname) + 2 + 1), \ - fill_in_lock_file_name (lockname, fname)) - -static void -fill_in_lock_file_name (char *lockfile, Lisp_Object fn) -{ - char *last_slash = memrchr (SSDATA (fn), '/', SBYTES (fn)); - char *base = last_slash + 1; - ptrdiff_t dirlen = base - SSDATA (fn); - memcpy (lockfile, SSDATA (fn), dirlen); - lockfile[dirlen] = '.'; - lockfile[dirlen + 1] = '#'; - strcpy (lockfile + dirlen + 2, base); -} - /* For some reason Linux kernels return EPERM on file systems that do not support hard or symbolic links. This symbol documents the quirk. There is no way to tell whether a symlink call fails due to @@ -639,6 +620,12 @@ lock_if_free (lock_info_type *clasher, char *lfname) return err; } +static Lisp_Object +make_lock_file_name (Lisp_Object fn) +{ + return ENCODE_FILE (call1 (intern ("make-lock-file-name"), fn)); +} + /* lock_file locks file FN, meaning it serves notice on the world that you intend to edit that file. This should be done only when about to modify a file-visiting @@ -660,10 +647,9 @@ lock_if_free (lock_info_type *clasher, char *lfname) void lock_file (Lisp_Object fn) { - Lisp_Object orig_fn, encoded_fn; + Lisp_Object orig_fn; char *lfname = NULL; lock_info_type lock_info; - USE_SAFE_ALLOCA; /* Don't do locking while dumping Emacs. Uncompressing wtmp files uses call-process, which does not work @@ -672,29 +658,25 @@ lock_file (Lisp_Object fn) return; orig_fn = fn; - fn = Fexpand_file_name (fn, Qnil); + fn = make_lock_file_name (Fexpand_file_name (fn, Qnil)); #ifdef WINDOWSNT /* Ensure we have only '/' separators, to avoid problems with looking (inside fill_in_lock_file_name) for backslashes in file names encoded by some DBCS codepage. */ dostounix_filename (SSDATA (fn)); #endif - encoded_fn = ENCODE_FILE (fn); - if (create_lockfiles) - /* Create the name of the lock-file for file fn */ - MAKE_LOCK_NAME (lfname, encoded_fn); - + lfname = SSDATA (fn); /* See if this file is visited and has changed on disk since it was visited. */ Lisp_Object subject_buf = get_truename_buffer (orig_fn); if (!NILP (subject_buf) && NILP (Fverify_visited_file_modtime (subject_buf)) && !NILP (Ffile_exists_p (fn)) - && !(lfname && current_lock_owner (NULL, lfname) == -2)) + && !(create_lockfiles && current_lock_owner (NULL, lfname) == -2)) call1 (intern ("userlock--ask-user-about-supersession-threat"), fn); /* Don't do locking if the user has opted out. */ - if (lfname) + if (create_lockfiles) { /* Try to lock the lock. FIXME: This ignores errors when lock_if_free returns a positive errno value. */ @@ -715,7 +697,6 @@ lock_file (Lisp_Object fn) if (!NILP (attack)) lock_file_1 (lfname, 1); } - SAFE_FREE (); } } @@ -723,12 +704,9 @@ lock_file (Lisp_Object fn) unlock_file_body (Lisp_Object fn) { char *lfname; - USE_SAFE_ALLOCA; - - Lisp_Object filename = Fexpand_file_name (fn, Qnil); - fn = ENCODE_FILE (filename); - MAKE_LOCK_NAME (lfname, fn); + Lisp_Object filename = make_lock_file_name (Fexpand_file_name (fn, Qnil)); + lfname = SSDATA (filename); int err = current_lock_owner (0, lfname); if (err == -2 && unlink (lfname) != 0 && errno != ENOENT) @@ -736,7 +714,6 @@ unlock_file_body (Lisp_Object fn) if (0 < err) report_file_errno ("Unlocking file", filename, err); - SAFE_FREE (); return Qnil; } @@ -842,11 +819,10 @@ DEFUN ("file-locked-p", Ffile_locked_p, Sfile_locked_p, 1, 1, 0, char *lfname; int owner; lock_info_type locker; - USE_SAFE_ALLOCA; filename = Fexpand_file_name (filename, Qnil); - Lisp_Object encoded_filename = ENCODE_FILE (filename); - MAKE_LOCK_NAME (lfname, encoded_filename); + Lisp_Object lockname = make_lock_file_name (filename); + lfname = SSDATA (lockname); owner = current_lock_owner (&locker, lfname); switch (owner) @@ -857,7 +833,6 @@ DEFUN ("file-locked-p", Ffile_locked_p, Sfile_locked_p, 1, 1, 0, default: report_file_errno ("Testing file lock", filename, owner); } - SAFE_FREE (); return ret; #endif } diff --git a/test/lisp/files-tests.el b/test/lisp/files-tests.el index 257cbc2d32..b97e0256fb 100644 --- a/test/lisp/files-tests.el +++ b/test/lisp/files-tests.el @@ -949,6 +949,44 @@ files-tests-file-name-non-special-make-auto-save-file-name (make-auto-save-file-name) (kill-buffer))))))) +(ert-deftest files-test-auto-save-name-default () + (with-temp-buffer + (let ((auto-save-file-name-transforms nil)) + (setq buffer-file-name "/tmp/foo.txt") + (should (equal (make-auto-save-file-name) "/tmp/#foo.txt#"))))) + +(ert-deftest files-test-auto-save-name-transform () + (with-temp-buffer + (setq buffer-file-name "/tmp/foo.txt") + (let ((auto-save-file-name-transforms + '(("\\`/.*/\\([^/]+\\)\\'" "/var/tmp/\\1" nil)))) + (should (equal (make-auto-save-file-name) "/var/tmp/#foo.txt#"))))) + +(ert-deftest files-test-auto-save-name-unique () + (with-temp-buffer + (setq buffer-file-name "/tmp/foo.txt") + (let ((auto-save-file-name-transforms + '(("\\`/.*/\\([^/]+\\)\\'" "/var/tmp/\\1" t)))) + (should (equal (make-auto-save-file-name) "/var/tmp/#!tmp!foo.txt#"))) + (let ((auto-save-file-name-transforms + '(("\\`/.*/\\([^/]+\\)\\'" "/var/tmp/\\1" sha1)))) + (should (equal (make-auto-save-file-name) + "/var/tmp/#b57c5a04f429a83305859d3350ecdab8315a9037#"))))) + +(ert-deftest files-test-lock-name-default () + (let ((lock-file-name-transforms nil)) + (should (equal (make-lock-file-name "/tmp/foo.txt") "/tmp/.#foo.txt")))) + +(ert-deftest files-test-lock-name-unique () + (let ((lock-file-name-transforms + '(("\\`/.*/\\([^/]+\\)\\'" "/var/tmp/\\1" t)))) + (should (equal (make-lock-file-name "/tmp/foo.txt") + "/var/tmp/.#!tmp!foo.txt"))) + (let ((lock-file-name-transforms + '(("\\`/.*/\\([^/]+\\)\\'" "/var/tmp/\\1" sha1)))) + (should (equal (make-lock-file-name "/tmp/foo.txt") + "/var/tmp/.#b57c5a04f429a83305859d3350ecdab8315a9037")))) + (ert-deftest files-tests-file-name-non-special-make-directory () (files-tests--with-temp-non-special (tmpdir nospecial-dir t) (let ((default-directory nospecial-dir)) -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 07 12:07:19 2021 Received: (at 49261) by debbugs.gnu.org; 7 Jul 2021 16:07:19 +0000 Received: from localhost ([127.0.0.1]:53308 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1A51-00030q-Hb for submit@debbugs.gnu.org; Wed, 07 Jul 2021 12:07:19 -0400 Received: from mout.gmx.net ([212.227.15.18]:53423) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1A4x-00030Y-Ga for 49261@debbugs.gnu.org; Wed, 07 Jul 2021 12:07:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1625674028; bh=UNC22CIVROykrBMMoobpEg3PxlkjPWVzLqU4Kfssfbw=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=RZBbHTB32otyUZ1tP8cfNQMUDoXS6WVSEauph3BH/lWjK0PzdbGc/v7FliXXkAxIz BoCP7u6idy7Ohdij8DZJXSkfINQ7wqwLuZTniJM3f9yxgAFbU1RhuRTrlTexoRp3+2 9gPrRiFAA7zOh+67/WkSafCy8XaiTRuDz4hTdqiw= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from gandalf.gmx.de ([212.91.249.146]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1Mxm3Q-1lGCtW26aU-00zFg4; Wed, 07 Jul 2021 18:07:08 +0200 From: Michael Albinus To: Lars Ingebrigtsen Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: <87o8bn7bie.fsf@gnus.org> <87zgv6vuon.fsf@gmx.de> <837di9lwbm.fsf@gnu.org> <87a6n5vuu4.fsf@gnus.org> <8735sqnmei.fsf@gnus.org> Date: Wed, 07 Jul 2021 18:07:07 +0200 In-Reply-To: <8735sqnmei.fsf@gnus.org> (Lars Ingebrigtsen's message of "Wed, 07 Jul 2021 18:01:25 +0200") Message-ID: <87a6myglas.fsf@gmx.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:3Ux8z+Zot2iur9Sm6MEckbzd08pAtc6AOBPMgt1ZuK1ifllnUye s9WiL7dYHkxeeOdHe72+J+Ktw/Chmz0jKepZgWU67bZEgI/dYlpaApSD5wXtYHeUIP1U4gn Jk8X07Ibp5G/DZjSKxSr5e/NaTb9kbgcEITy017cxVUxPzAQQHTOO35//RYMA+KMdI/2JEc d6RvJC7iAGM12LEF1WT6g== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:M6akq1Vqjpo=:ftGA4hsLdY+tXtDzP5zzar WwlwYC5DyHTOYqIeXsTQHsIitdQG8FWJC8QUJmJgH2Qa8Mho0KrstGgTsR29za6yUDfF1ik1y kAY70ORkf6WZbWNEQMIxnJR6YLpwmTAIL1nlLtNCaVht0AnY2v/YZEAKyIhEvGlAEizRymYTe LtnODm/miphJB6zsTdQqZC8C70fbjb+juRrnS+PAsOrpKEJi7hgpDUP2AQcmWPypVDaiFROiX gApb22xGuj/C264mzGzNvmyaqaFw/npVF5+KZ+kDyNTEXZJPobMZ6Rqpbedn1N/PgEGEIRT2w pLU5wM7r8MPj/l4CaPLFRzkFTc5oMnnpkPEZPUEkKEAeyowqnZ3HKhbY1FS/IrVYoFkVIN05v MLHrsfn1t12ZnoRxX3rio1OtEMgBw/XswWH2vNdbzvyPLcOKfqeXQuXYp8PfD1T053hMnbaCR i0SrJGprDBCY6+48OAz6paVN7ivVXmqrXIo+mKt1fGJzuLNL7Hw0CpDrNFxWnT/YNVMQHcljN ZVl9zVimFuZ43WUUVT1iiGAOrPlU65EOMnAcE0JmbMkeMtiwzkS98utBGpFBYzS3m/OA5tVoK FKhYiCfi1bzuOV158UIrGkFfqsE4jh9S5cjEPEZBN8jIT/6YEgrElDn42AmhfxpF60quyXTti fWGt0JUXnwj7F/5T/g371ExlLNp4ho2aZXnQJI+2fB1uCIQ5uYofOer38avTPkv1Aab/38Lfr lmOIgKny/sHYbf/9vP5HzPJNJEqhobg4z/s62aVBZaaEZBBZ04gtxUcjIF0MlvcNdoSS25Jvu hH+1rEQYZiOZHlzDtrkSZ3jsF+Qi4RxJd9Kxzt8BO1C0VT9JUit+yjKPMRYuBu/vx0FRsfqiP 1uXAJZnSS5kaAI5eS/xdZuSzjgmInTaHBjlzJG3oRzUtEH9yHIKhAWKGuDobM+Ls2odGUnrh2 vN14EriJ/m9rN74rt4e5NN3YyrsIFJIaGcR8KCIr3KH57n1uQFwl9GGtlDEnZRkHK8MzMuOQC SVAjaJYBC8eI0/0oielgUtRlhDhtjZuk5AVW4rVTn/ob76NoilOP0ny/QfxXDUcx6NhInwCp+ NJNtO42CgQo6ohCuG1kaYjnGFW1FrisY/fIG5rA0BGsY9bRxItGm/Kqvw== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 49261 Cc: Eli Zaretskii , ncaprisunfan@gmail.com, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Lars Ingebrigtsen writes: > Lars Ingebrigtsen writes: > >> If not, I'll get to it early next week. > > Is Wednesday still "early"? Uuhh, I'm almost finished. I'm running some final tests, my plan is to commit tonight. Would it be OK for you? I promise, I will check your patch immediately after this. Best regards, Michael. From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 07 12:13:46 2021 Received: (at 49261) by debbugs.gnu.org; 7 Jul 2021 16:13:46 +0000 Received: from localhost ([127.0.0.1]:53312 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1ABG-0003C9-78 for submit@debbugs.gnu.org; Wed, 07 Jul 2021 12:13:46 -0400 Received: from quimby.gnus.org ([95.216.78.240]:53372) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1ABD-0003Bt-My for 49261@debbugs.gnu.org; Wed, 07 Jul 2021 12:13:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=ii/Moc8vl+9nSP1kD9waLgm/yruwgU6l0t8s5dGlyGM=; b=uq3zxdMxDpVwDvEsvNlpL8RS8V oREk1UGe8kNmZgFi3UBHSGe1krgd2EwsSmCEcXQbtu6Gj9vHwsPtExfDU7YQiDmcJxgRROEPhuGwx ykQj9spzKlQQWFBFsfVIrPjhNUhf8tictuqJAtZjy+gKWZaU6mVw/dV49gRrqlukDuMI=; Received: from cm-84.212.220.105.getinternet.no ([84.212.220.105] helo=elva) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m1AB4-0007io-4r; Wed, 07 Jul 2021 18:13:36 +0200 From: Lars Ingebrigtsen To: Michael Albinus Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: <87o8bn7bie.fsf@gnus.org> <87zgv6vuon.fsf@gmx.de> <837di9lwbm.fsf@gnu.org> <87a6n5vuu4.fsf@gnus.org> <8735sqnmei.fsf@gnus.org> <87a6myglas.fsf@gmx.de> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAD1BMVEWaalCyiG220+FL NDD////T+lTcAAAAAWJLR0QEj2jZUQAAAAd0SU1FB+UHBxANA5UrSL8AAAG4SURBVDjLrZLbsaQw DESlcQIWTgAuCch0/rlttwxTy97fVQ0wpWO59TIz237edqbJsB3b9mZN/na9fPuHr0Mh+b7GoPcg +LwDDHKcBC//QckKyX9Apybmb3AoGWD7BfoCWQm/lJ2A5KO01h13QCyAGxyoag6Cbi2Z2HUWGJiN n+guAEPD0qAcG7NTOaK30ofAAXQC86ApQkRg1yfl1GP5jTh1FXh+hdCJLDB44AtsGWoiPIBu2b2p QO8PYDIDfSCi3Tq+MvDuHdGgCN1FBKzzMwY7kR2z9yWBKmpkVIodCLjlSpd9aIicTTnDMZVOiTtv BKaSBtblLddVUL5lmlKJaLNU61/AnjocjxVNV+8Fos7RJJL7JLgrX25M9fI64ntVOfVwbLh2lP8B l55drx/4iJVV3kVcRw6CPXGxL09WZx3miW33Aa8I1yKFIlTHNRg9C0AqH7nQ0reTHVNPzaouLsBs eV7VSPa/QGtP5XtUq7Rb2i6CWr9kCexIaAx2r1390aqzbusar0CuRnMu2l3Xn5qHWsAN5zfuzYpe 4lp8FsC1UlTTr+TXvPBMrpQ0u9XEt6XVyv8/+wMntWucKKEq+wAAACV0RVh0ZGF0ZTpjcmVhdGUA MjAyMS0wNy0wN1QxNjoxMzowMyswMDowMIrIMfkAAAAldEVYdGRhdGU6bW9kaWZ5ADIwMjEtMDct MDdUMTY6MTM6MDMrMDA6MDD7lYlFAAAAAElFTkSuQmCC X-Now-Playing: Yoko Ono's _Feeling the Space_: "A Thousand Times Yes" Date: Wed, 07 Jul 2021 18:13:33 +0200 In-Reply-To: <87a6myglas.fsf@gmx.de> (Michael Albinus's message of "Wed, 07 Jul 2021 18:07:07 +0200") Message-ID: <87y2aim79u.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Michael Albinus writes: > Uuhh, I'm almost finished. I'm running some final tests, my plan is to > commit tonight. > > Would it be OK for you? I promise, I will check your patch immediately > after this. Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49261 Cc: Eli Zaretskii , ncaprisunfan@gmail.com, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Michael Albinus writes: > Uuhh, I'm almost finished. I'm running some final tests, my plan is to > commit tonight. > > Would it be OK for you? I promise, I will check your patch immediately > after this. Sure. :-) -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 07 12:41:10 2021 Received: (at 49261) by debbugs.gnu.org; 7 Jul 2021 16:41:10 +0000 Received: from localhost ([127.0.0.1]:53333 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1Abm-00041E-4F for submit@debbugs.gnu.org; Wed, 07 Jul 2021 12:41:10 -0400 Received: from mout.gmx.net ([212.227.17.21]:42589) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1Abg-00040X-OM for 49261@debbugs.gnu.org; Wed, 07 Jul 2021 12:41:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1625676057; bh=VyulbsLUvU7rbc5mEt4gK41zxAgY43BmcqoTjWYKQ0w=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=SDyoXH9gy3RJC/is+lBiV24xTxEF1XAA9hva+GcaIGOYqWbXkdIf5ug98Hr8RBt6h 8Rw8X5+HCdivrQjfZpXVJP/vseD4PdtophMn9X8jdbEYze7xtqdzwT5zpoLcbWcb76 TuPQVYUqNS5GPsCp9QhPyMLmHkGw855rTc1wwits= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from gandalf.gmx.de ([212.91.249.146]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1M3lcJ-1m1Rik2cxn-000vbJ; Wed, 07 Jul 2021 18:40:57 +0200 From: Michael Albinus To: Lars Ingebrigtsen Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: <87o8bn7bie.fsf@gnus.org> <87zgv6vuon.fsf@gmx.de> <837di9lwbm.fsf@gnu.org> <87a6n5vuu4.fsf@gnus.org> <8735sqnmei.fsf@gnus.org> <87a6myglas.fsf@gmx.de> <87y2aim79u.fsf@gnus.org> Date: Wed, 07 Jul 2021 18:40:56 +0200 In-Reply-To: <87y2aim79u.fsf@gnus.org> (Lars Ingebrigtsen's message of "Wed, 07 Jul 2021 18:13:33 +0200") Message-ID: <875yxmgjqf.fsf@gmx.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:jXKuApQ/E22FXBEGxJ2GpIJJ8nX4Ey4/CHirt3/izl2mGSxTNOL smuYyGqVGLow3YIVIldmd44CcgzWnN64DIYyRpWQvkmiPh2yPUq1ttFr3FGyC0a1wdVKY8s OmdpfVeBiJ7Wixk/r5z7f5XDv2tz/nhLNdEnoKN8YttiKnh8qucef/OGYKV0Ht1k27JUSkO YlgdGSZYK9OBTly1jFkKg== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:p8kRng9+pRE=:PbUT2GYdrfQlVi6ioNi+ON Kr6NH1ESmzqTQMS5WLDQExpq8CLSpByk1TpfcEMuL7HSr9EeMFRoOQP7ksAo7+lj8/f+vJP9A 1gWZEgdcU9xq3LFTczX1M8Itn2gNabcZe6H6+b9CZYKs+Z5js64MaUcVIyMfQmCpKYba5PRl6 WSLCgzRN5LSp0DmbVIIY1n6Zh0bR7RahG8wWgzE1XWIUreU1npX1/koxFRZWRcoNq6g6EjyVC tzs2Ed26GaaNY8MSbf7FiAETvj1Plm7/uZ+H9j7wkS7KMfXHTwVFVIfNCLqhmJay+OFLZ2BtC IjitUTqQ0h7Q8pp+XcB7Jrw+9nkezhvZPGc9yclUcHP3mfhF0SXrBM81dDn+L8Q6bCpO6BrCo qhrYVlI0szT1owO3F+9h1pdc3XUdr7eTWssewEykhBNwQYwLZoHEAUDWSd+7dZQiRH8OeGyqa yYUE32M98CU8hKg+4B0U3A/XM/xAv0P7W61vx1YRewFfAkLIlTX4hccKGev8rhlHwdUx8NwSp LjI8NjWaIBUN5+Zo36aB/HMBIDDszPrg+8+5dk0z88sOCgvE9kicO2OzAf7zMmt5sTP3MFekm Re6l0rZ4yPiEKBzQmdautomcbQjseE9tVqqZEtKHSwdP/9a3cGaqx2niyPo02aFDxth6pm4wH 6ZCh3C8a+2kcpOJBM32Q+cL/GCntnTQ/mCIDoDzdUXd80FKFZoQ0KERv5KGeLo2OyNzzlu4h+ CC8hI1jdSPRkloXXRV2F1F1uC2aZw2hKhJOph3tXXyOCacyEUf3iwPuOXr6LqnyBRvXtvgb/u OzyP47BxerC24qVLp0rl48WZ/O7+5hHWT3AJNCBnXG5y/mJtLH0ZzFY09h2g64M86JJY8lH3g uZ+mTSKRsi4jOL0zAEz+fpT8FMZ/EZYImdQhkEb4ZLm8vK9zKrjxpomAn+Aw9oQs97JfutSLa PZ78DmCjblfvIYL4iS0aZZox+qC90Islid6iUaxJKigrjjG9kDCLSR9jEM9poilFNEoE+HE0G YjFYGaAd+zym6fDjflkgPNn/rnmt1LCHM8ofiAnlH/O5XWo+IYT6NhCAGU0rAjn31tz4xmn7S /czPS+ZR+EyeNQFVmYU6lMFm00nkURIwEaC23ZcE9ciiyZIYcWLWVzaPA== X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 49261 Cc: Eli Zaretskii , ncaprisunfan@gmail.com, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Lars Ingebrigtsen writes: >> Uuhh, I'm almost finished. I'm running some final tests, my plan is to >> commit tonight. >> >> Would it be OK for you? I promise, I will check your patch immediately >> after this. > > Sure. :-) There are still two failed test cases. But I guess it will be better to hunt them together with your applied patch. I've committed my work as d35868bec9. Go on and push your changes, and let's puzzle the final bits afterwards. (Ohh, Glenn will beat me) Best regards, Michael. From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 07 12:55:37 2021 Received: (at 49261) by debbugs.gnu.org; 7 Jul 2021 16:55:38 +0000 Received: from localhost ([127.0.0.1]:53341 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1Apl-0004MV-Ns for submit@debbugs.gnu.org; Wed, 07 Jul 2021 12:55:37 -0400 Received: from mout.gmx.net ([212.227.15.19]:55867) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1Apj-0004MG-De for 49261@debbugs.gnu.org; Wed, 07 Jul 2021 12:55:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1625676928; bh=ByvfXP68Vmmqjdz/wolI/avWKoaSEi4hLWl51EiRa8g=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=RclKKvf/ssjURoJYBj2RVNEk75XsozOHuFJ/JuhWcaOK418NByz04RsD9OrHc4gc7 W5zEvjCq5SS3deK0HbSeIP/57F0N9HhH1zlYI/NK8Zchxt09uAkPVygIfH+NDPTuc6 F8lZwwzu8u5/Cwi5/xQd2T5/FovnN8Wq0QzFz26o= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from gandalf.gmx.de ([212.91.249.146]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1N6bk4-1l7QZ41Phu-0184yT; Wed, 07 Jul 2021 18:55:28 +0200 From: Michael Albinus To: Lars Ingebrigtsen Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: <87o8bn7bie.fsf@gnus.org> <87zgv6vuon.fsf@gmx.de> <837di9lwbm.fsf@gnu.org> <87a6n5vuu4.fsf@gnus.org> <8735sqnmei.fsf@gnus.org> Date: Wed, 07 Jul 2021 18:55:26 +0200 In-Reply-To: <8735sqnmei.fsf@gnus.org> (Lars Ingebrigtsen's message of "Wed, 07 Jul 2021 18:01:25 +0200") Message-ID: <87zguyf4ht.fsf@gmx.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:W/CTy5oUpQjOxzQC8jyRDTFTDG+U4BGBBGOM1ck4K7LQnkTx3BO GJEFGMOMudHfJs2hTSza/+eHgwB4j9YC3ChOYQIcHzIdroOrq/1qwadvFgbRaQbjpImIPjQ ysjpFZ4BVGHZK16/RD0upi4y3iHOB5YUDvch7e8JpeQz5DmYYuwRkFxgUVEEnL+mgOrsGFf GLM6baZ6iRPTsiIbP32Zg== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:HIXBRw/DVRw=:oyXU8yUvZzwHZ2NdUOXbm0 mIlOBHRZ3uPaggGY+zb//nKLtZVjJxzyD5Vu16dJj7DH6pMq3yz6GaqEvZPxZZYAKeSYlfYXK /xMAS5rZRtSDacVxNu17V0N4o3v55W21asvHKV3XebRAgz+QoD1djeZUCueavkgoEP76If8AJ RjImuIvNbFoQqneZs1/T4+IxxKJcL7i6Jno5ErjaSgeT5qP1jUzeIXbAUGe/GKfqPaLPm8G/K Pa6xSRfyYmaYGXHs9ZgKkRK31TFnBGDN2rF54NivS31+vqqZgOZ7WxxkG7DIWa38uEOKt8lum yOqQBZRhB3PJJK8FyJBwHVtL4kDq0kXQOsRYDWHitNpPk6vLISnckn0em52g5ev7U14DkL+sC XUpqiVxrmixEQI02tYQ6s6M1UKecIf4kCr84EirhAdyE4QekGv5Bq8mE75kuIcFXBVe29QC4t j9CZIcleuwGoBLIwMiaTzXVzgi1kMeh3dcxhBkJG0v9iuRrg3uVEJr6QUImlG8YdtPqH+l8vG la39StMFVP3oJwdkZsFsYr7HPYACCtMFVV3+a7rkdzwd1lNh0ClM2RAonGjAaH3kVxVd/Gp2i w5pPb1cTg3PJbD/XVkSkCZJj92UgwRnLdyMdkTAYtJCsjPi+PYMWjFfvYLm6fBLT5rVBjjqay xxmI8M8YQvueeyKttDSB4wSUMCVq/LEIZApIXHgnKO6onqidMn7W3D4gg0DggMLdDYrdTch47 oESuwXr0/lIekGEkQYFYUmXoxdSsv2ILQfkoMr4SJdeN15/SoMQ2vIJTgMAcsKNU+1vR9wWml KkNVaiFwZtEFJWeeoDu3rYejWkap3FXFzqEdkoGkPXyu5B8SX+MRDYj653AQ5606Es5jot7nK STm9frftIZ4S9HaKGgL6BAlAFjl/iTO2URzEpVkyC8QVUwpDaMaNpeS4rjrnOgS4dBjZtLv+h HDObglYl/rQ6JHlQ5su0mKokCuPt/4W+B0tiraZ4zkK9UlJOXPXgT9oRO5TcLTBHO8iF3CGld f+f8RC+9E0hBkUY69eHXcrp9+372AWKgjxqjYUw5RpQtQrVq9MHNlrAPCu+5n858udwuo1b3N fI3npEKZFQOmn/OMf3bIB1g4ndF90nGeJsKVrJZjfBOZtZ0DBqRIIUu1w== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 49261 Cc: Eli Zaretskii , ncaprisunfan@gmail.com, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Lars Ingebrigtsen writes: Hi Lars, > So if somebody could give that a look-over while I'm writing up the > documentation, that'd be great. :-) Just some first thoughts, by dry reading. > (if handler > (funcall handler 'make-auto-save-file-name) We have a file name handler for make-auto-save-file-name. Shall we use also a handler for make-lock-file-name? > +(defun make-lock-file-name (filename) > + "Make a lock file name for FILENAME. > +By default, this just prepends \".*\" to the non-directory part > +of FILENAME, but the transforms in `lock-file-name-transforms' > +are done first." > + (auto-save--transform-file-name filename lock-file-name-transforms ".#" "")) Hmm, maybe not, because the lock file name must be the *same* over different Emacs sessions. Furthermore, there is auto-save-mode, which toggles auto-saving. Shall we use something similar for file locks? Perhaps, people might not want to lock all files, for example they might want to disable this feature for remote files (possible performance degradation). Best regards, Michael. From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 07 12:58:04 2021 Received: (at 49261) by debbugs.gnu.org; 7 Jul 2021 16:58:04 +0000 Received: from localhost ([127.0.0.1]:53345 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1As8-0004QW-4D for submit@debbugs.gnu.org; Wed, 07 Jul 2021 12:58:04 -0400 Received: from quimby.gnus.org ([95.216.78.240]:53680) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1As5-0004Py-0s for 49261@debbugs.gnu.org; Wed, 07 Jul 2021 12:58:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=XfntSnV+KiFfsWLDUEz04V9BCoTjr4qml85m4rdIfNE=; b=kzIVzpgKTUA+YePVlu3QC1/vXY kKO2AqQfJKtEfuUBuOpIaSGLJAE1J5osY9Z9BXkFjTcaLRw0MflsRR2FwhaUeFal50xw4R8y5TcnI iI5OUpt1WBbHKBPTLVr7gHUFgWsObULYQfhdRHFzhHhjO/k0rF7zqkm1KRxtLL8t693A=; Received: from cm-84.212.220.105.getinternet.no ([84.212.220.105] helo=elva) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m1Arv-00089W-K9; Wed, 07 Jul 2021 18:57:54 +0200 From: Lars Ingebrigtsen To: Michael Albinus Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: <87o8bn7bie.fsf@gnus.org> <87zgv6vuon.fsf@gmx.de> <837di9lwbm.fsf@gnu.org> <87a6n5vuu4.fsf@gnus.org> <8735sqnmei.fsf@gnus.org> <87a6myglas.fsf@gmx.de> <87y2aim79u.fsf@gnus.org> <875yxmgjqf.fsf@gmx.de> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAD1BMVEWaalCyiG220+FL NDD////T+lTcAAAAAWJLR0QEj2jZUQAAAAd0SU1FB+UHBxANA5UrSL8AAAG4SURBVDjLrZLbsaQw DESlcQIWTgAuCch0/rlttwxTy97fVQ0wpWO59TIz237edqbJsB3b9mZN/na9fPuHr0Mh+b7GoPcg +LwDDHKcBC//QckKyX9Apybmb3AoGWD7BfoCWQm/lJ2A5KO01h13QCyAGxyoag6Cbi2Z2HUWGJiN n+guAEPD0qAcG7NTOaK30ofAAXQC86ApQkRg1yfl1GP5jTh1FXh+hdCJLDB44AtsGWoiPIBu2b2p QO8PYDIDfSCi3Tq+MvDuHdGgCN1FBKzzMwY7kR2z9yWBKmpkVIodCLjlSpd9aIicTTnDMZVOiTtv BKaSBtblLddVUL5lmlKJaLNU61/AnjocjxVNV+8Fos7RJJL7JLgrX25M9fI64ntVOfVwbLh2lP8B l55drx/4iJVV3kVcRw6CPXGxL09WZx3miW33Aa8I1yKFIlTHNRg9C0AqH7nQ0reTHVNPzaouLsBs eV7VSPa/QGtP5XtUq7Rb2i6CWr9kCexIaAx2r1390aqzbusar0CuRnMu2l3Xn5qHWsAN5zfuzYpe 4lp8FsC1UlTTr+TXvPBMrpQ0u9XEt6XVyv8/+wMntWucKKEq+wAAACV0RVh0ZGF0ZTpjcmVhdGUA MjAyMS0wNy0wN1QxNjoxMzowMyswMDowMIrIMfkAAAAldEVYdGRhdGU6bW9kaWZ5ADIwMjEtMDct MDdUMTY6MTM6MDMrMDA6MDD7lYlFAAAAAElFTkSuQmCC X-Now-Playing: Yoko Ono's _Feeling the Space_: "Mildred, Mildred (Demo)" Date: Wed, 07 Jul 2021 18:57:51 +0200 In-Reply-To: <875yxmgjqf.fsf@gmx.de> (Michael Albinus's message of "Wed, 07 Jul 2021 18:40:56 +0200") Message-ID: <87tul6m580.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Michael Albinus writes: > There are still two failed test cases. But I guess it will be better to > hunt them together with your applied patch. > > I've committed my work as d35868bec9. Go on and push your changes, and > let [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49261 Cc: Eli Zaretskii , ncaprisunfan@gmail.com, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Michael Albinus writes: > There are still two failed test cases. But I guess it will be better to > hunt them together with your applied patch. > > I've committed my work as d35868bec9. Go on and push your changes, and > let's puzzle the final bits afterwards. I have some errands to run, so I'm not pushing right away -- but I'll do so later tonight, unless I discover major problems... -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 07 13:00:02 2021 Received: (at 49261) by debbugs.gnu.org; 7 Jul 2021 17:00:02 +0000 Received: from localhost ([127.0.0.1]:53349 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1Au1-0004Tj-GU for submit@debbugs.gnu.org; Wed, 07 Jul 2021 13:00:02 -0400 Received: from quimby.gnus.org ([95.216.78.240]:53724) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1Au0-0004TA-18 for 49261@debbugs.gnu.org; Wed, 07 Jul 2021 13:00:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=2OMwl+MzOtQeFcVdrGYw0ZbKA8teZ42cyUcd7BqtAbU=; b=f8oYoiy1MTWA3trIxNYHHxGz3K Y3ep9fV8NAfeFFWa4D7llEZ3b3zJOgBGyRmR59Mt/G1k61npBywZ8jmgLw5h9IvwJVaElIAwWhVtP sy31IW8q32dVmu1+fEDDmrasYFwjjzBSzbrkrVw8HrmpprSZC8KGeizyK+7zusTBHXpM=; Received: from cm-84.212.220.105.getinternet.no ([84.212.220.105] helo=elva) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m1Atr-0008Ck-1B; Wed, 07 Jul 2021 18:59:53 +0200 From: Lars Ingebrigtsen To: Michael Albinus Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: <87o8bn7bie.fsf@gnus.org> <87zgv6vuon.fsf@gmx.de> <837di9lwbm.fsf@gnu.org> <87a6n5vuu4.fsf@gnus.org> <8735sqnmei.fsf@gnus.org> <87zguyf4ht.fsf@gmx.de> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAD1BMVEWaalCyiG220+FL NDD////T+lTcAAAAAWJLR0QEj2jZUQAAAAd0SU1FB+UHBxANA5UrSL8AAAG4SURBVDjLrZLbsaQw DESlcQIWTgAuCch0/rlttwxTy97fVQ0wpWO59TIz237edqbJsB3b9mZN/na9fPuHr0Mh+b7GoPcg +LwDDHKcBC//QckKyX9Apybmb3AoGWD7BfoCWQm/lJ2A5KO01h13QCyAGxyoag6Cbi2Z2HUWGJiN n+guAEPD0qAcG7NTOaK30ofAAXQC86ApQkRg1yfl1GP5jTh1FXh+hdCJLDB44AtsGWoiPIBu2b2p QO8PYDIDfSCi3Tq+MvDuHdGgCN1FBKzzMwY7kR2z9yWBKmpkVIodCLjlSpd9aIicTTnDMZVOiTtv BKaSBtblLddVUL5lmlKJaLNU61/AnjocjxVNV+8Fos7RJJL7JLgrX25M9fI64ntVOfVwbLh2lP8B l55drx/4iJVV3kVcRw6CPXGxL09WZx3miW33Aa8I1yKFIlTHNRg9C0AqH7nQ0reTHVNPzaouLsBs eV7VSPa/QGtP5XtUq7Rb2i6CWr9kCexIaAx2r1390aqzbusar0CuRnMu2l3Xn5qHWsAN5zfuzYpe 4lp8FsC1UlTTr+TXvPBMrpQ0u9XEt6XVyv8/+wMntWucKKEq+wAAACV0RVh0ZGF0ZTpjcmVhdGUA MjAyMS0wNy0wN1QxNjoxMzowMyswMDowMIrIMfkAAAAldEVYdGRhdGU6bW9kaWZ5ADIwMjEtMDct MDdUMTY6MTM6MDMrMDA6MDD7lYlFAAAAAElFTkSuQmCC X-Now-Playing: Yoko Ono's _Feeling the Space_: "Mildred, Mildred (Demo)" Date: Wed, 07 Jul 2021 18:59:50 +0200 In-Reply-To: <87zguyf4ht.fsf@gmx.de> (Michael Albinus's message of "Wed, 07 Jul 2021 18:55:26 +0200") Message-ID: <87pmvum54p.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Michael Albinus writes: > Just some first thoughts, by dry reading. > >> (if handler >> (funcall handler 'make-auto-save-file-name) > > We have a file name handler for make-auto-save-file-name. Shall we use > also a handler [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49261 Cc: Eli Zaretskii , ncaprisunfan@gmail.com, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Michael Albinus writes: > Just some first thoughts, by dry reading. > >> (if handler >> (funcall handler 'make-auto-save-file-name) > > We have a file name handler for make-auto-save-file-name. Shall we use > also a handler for make-lock-file-name? Yeah, I wondered about that, too. I'm not quite sure what the use case would be, but for symmetry's sake, it might make sense anyway. >> +(defun make-lock-file-name (filename) >> + "Make a lock file name for FILENAME. >> +By default, this just prepends \".*\" to the non-directory part >> +of FILENAME, but the transforms in `lock-file-name-transforms' >> +are done first." >> + (auto-save--transform-file-name filename lock-file-name-transforms >> ".#" "")) > > Hmm, maybe not, because the lock file name must be the *same* over > different Emacs sessions. That would be up to the person that writes the handler to take care of, I think? > Furthermore, there is auto-save-mode, which toggles auto-saving. Shall > we use something similar for file locks? Perhaps, people might not want > to lock all files, for example they might want to disable this feature > for remote files (possible performance degradation). Sure; makes sense. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 07 13:36:35 2021 Received: (at 49261) by debbugs.gnu.org; 7 Jul 2021 17:36:35 +0000 Received: from localhost ([127.0.0.1]:53372 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1BTP-0005PS-K5 for submit@debbugs.gnu.org; Wed, 07 Jul 2021 13:36:35 -0400 Received: from mout.gmx.net ([212.227.17.22]:58845) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1BTN-0005PE-MI for 49261@debbugs.gnu.org; Wed, 07 Jul 2021 13:36:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1625679386; bh=WhppsIBy0Jh502K1oFcDOSUGF0v09JlV7XvrvplDFyY=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=go81cgIYnz+ieEvpwTr7sot/Be4LwYRuUfHqNybbBBiwLhQ4IvyzLCNVLrOHA9mWD vqQ+1YifzWpHD0OG7HQaWvs0gwtvthaJ6bcLneGtwZPIO6AbrgiqOmjFid7UZbx2SH tedSk2F4r9L/U+V2udM9wZOrU9D3GPXSc0fKM1NM= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from gandalf.gmx.de ([212.91.249.146]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1M1HZi-1m3wMF3rgY-002q7q; Wed, 07 Jul 2021 19:36:26 +0200 From: Michael Albinus To: Lars Ingebrigtsen Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: <87o8bn7bie.fsf@gnus.org> <87zgv6vuon.fsf@gmx.de> <837di9lwbm.fsf@gnu.org> <87a6n5vuu4.fsf@gnus.org> <8735sqnmei.fsf@gnus.org> <87zguyf4ht.fsf@gmx.de> <87pmvum54p.fsf@gnus.org> Date: Wed, 07 Jul 2021 19:36:24 +0200 In-Reply-To: <87pmvum54p.fsf@gnus.org> (Lars Ingebrigtsen's message of "Wed, 07 Jul 2021 18:59:50 +0200") Message-ID: <87v95mf2lj.fsf@gmx.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:rFivpU3RKk3JdmartMyN7yIkScRo85NxmV3i8koi8ysSqDInWMj GwYMN3iPRGzEUCvbUYVQo8zBDRD4PzXjC9s4hMeUKHuF1vxecGqhL7PXj/a5HE/vvQgXwut sVRo4aIfeSYZgXpcYtRzYrFMRTG5rNqx/AwsaNdM0MwPU5zMOetlR6gEBuIcjMeLFeDA2ml 0QMoZV6yg7LadnVaeg9eQ== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:KmAmVBNwlX0=:btwEIlrEbxOdduBPJj+YDD GK6aYYYMpbSGGXlUEJkSPDNSKDOnzi5vLVhOIQitvX7aIz3th1uQDa7k4hSRSsl6E0qAJ2wzr k75sEs/kqAhhL2jVE6WbXfeWyW0I1WjR5SD48QVY8hMTiZVkJFUwOfJNOsqTpSlmiu65kSGVP n784ptTqGUfMA6lPmcXFrzLdMNzYw21TdSXSuF/Z62gFQTQ/uC2TGTf9MOOrCkEN3Bq7M3L3L kHMATHDDOTkz+HJ0RI6jRIgk5Q3liINt2fuitIWeoauPf6iWjQZ957Af+Ky8hbfsD2LM9WXIX 6OSHw5hxcen9znwrsomThXZ8FmsoI26jH9uM739gGnn9m+cC/rLN3tbOCjVssEfpTe4zz9Bc0 IngABzsIvqXnSVAv30EOIScIKOXGjRLFwYCSJrW2GHl320kfb7Qw5F2E42y5y97aOY2enDDPm q2le91cjnoxXZ/NZV95ANrlUfTQFilHuKEvqeX44TLC0HXFVaHEPgeoKewW0tNIAAsz2LsjUX fY2rGHEz2ODbXMrS5uuCO0Kr5w+mPm0/yjvMo0EBqPbNYgvsmCj29zDxlHlSnsllR69XfMFms 7XlU3UoiXgIw1pIXm9O1FpKFlpq++fLStN2jPNwUSjVvYhdRxZiWvj6KSPqtgfObvy+Ixq4Ft fxNNoz52y/R8lJrtWQtLwdTUoiSSMpcRwhQoUHZP/AqTkiPGFRucfw2DSqvoA4TV4jV7PwkZH fnI6MWeDKn8ZrYKRMjEyENApEnF/htIwWl0IkTWVMcSxWxUGV1fd2AD7fQUNbBBNCixnzqcpP /Juh+u2w8n63Pqtnrr1Ay+7y1o5st3zhq5S9a8NejrmhrUtokBX6KiaOd2eqqEBLoNmYAOpKE Myxe5iBUL7kkNx9tE0CkCFfHwM0gfzRey/JK2XF93RPKtBWPyvckqfdEHTD8wSS5C1Ylw3g0N tsOMgfZHlXVYEPYGILj4thsb8Rw4t9zq3Cqd0SpY3SBp9KcRu1JDVlnubJnj4+AqtOzrV6tts QKY30rMQMHX9nBp/GQurdMYR4ED48orZWL3LiKrWrpCBv4L2pCxd/ERZNuULkyMsmq+q1U48e lOsgqqzGYPq621E2HVdgekdKvr6mu+MpQsuzOGotoHtc5pG2cCrK+WKxA== X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 49261 Cc: Eli Zaretskii , ncaprisunfan@gmail.com, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Lars Ingebrigtsen writes: >>> (if handler >>> (funcall handler 'make-auto-save-file-name) >> >> We have a file name handler for make-auto-save-file-name. Shall we use >> also a handler for make-lock-file-name? > > Yeah, I wondered about that, too. I'm not quite sure what the use case > would be, but for symmetry's sake, it might make sense anyway. OK, I'll care. One use case could be a file lock for a file archive (something like foo.tar), when you change a file inside the archive. >> Hmm, maybe not, because the lock file name must be the *same* over >> different Emacs sessions. > > That would be up to the person that writes the handler to take care of, > I think? :-) Best regards, Michael. From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 07 14:02:33 2021 Received: (at 49261) by debbugs.gnu.org; 7 Jul 2021 18:02:33 +0000 Received: from localhost ([127.0.0.1]:53405 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1BsX-000651-FT for submit@debbugs.gnu.org; Wed, 07 Jul 2021 14:02:33 -0400 Received: from eggs.gnu.org ([209.51.188.92]:56718) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1BsU-00064o-QC for 49261@debbugs.gnu.org; Wed, 07 Jul 2021 14:02:32 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:40556) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m1BsP-00036T-A3; Wed, 07 Jul 2021 14:02:25 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:4888 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m1BsO-00056H-Tw; Wed, 07 Jul 2021 14:02:25 -0400 Date: Wed, 07 Jul 2021 21:02:35 +0300 Message-Id: <834kd6f1dw.fsf@gnu.org> From: Eli Zaretskii To: Lars Ingebrigtsen In-Reply-To: <8735sqnmei.fsf@gnus.org> (message from Lars Ingebrigtsen on Wed, 07 Jul 2021 18:01:25 +0200) Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: <87o8bn7bie.fsf@gnus.org> <87zgv6vuon.fsf@gmx.de> <837di9lwbm.fsf@gnu.org> <87a6n5vuu4.fsf@gnus.org> <8735sqnmei.fsf@gnus.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49261 Cc: michael.albinus@gmx.de, ncaprisunfan@gmail.com, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Lars Ingebrigtsen > Cc: Michael Albinus , ncaprisunfan@gmail.com, > 49261@debbugs.gnu.org > Date: Wed, 07 Jul 2021 18:01:25 +0200 > > +(defun auto-save--transform-file-name (filename transforms > + prefix suffix) > + "Transform FILENAME according to TRANSFORMS. > +See `auto-save-file-name-transforms' for the format of > +TRANSFORMS. PREFIX is prepended to the non-directory portion of > +the resulting file name, and SUFFIX is appended." > + (let (result uniq) > + ;; Apply user-specified translations > + ;; to the file name. > + (while (and transforms (not result)) > + (if (string-match (car (car transforms)) filename) > + (setq result (replace-match (cadr (car transforms)) t nil > + filename) > + uniq (car (cddr (car transforms))))) If this is going to be called from C, it should probably use save-match-data, because no one will expect that just modifying a file from some Lisp program could clobber the match data. Also, do we ever need this during loadup? Because before files.el is loaded by loadup, this function will not be available, so unconditionally calling it from C without protection, not even safe_call or somesuch, is not safe. > +static Lisp_Object > +make_lock_file_name (Lisp_Object fn) > +{ > + return ENCODE_FILE (call1 (intern ("make-lock-file-name"), fn)); > +} I'd prefer not to have a function return an encoded file name, it's unusual and unexpected. It is better to leave that to the caller. (And if you do that, the rationale for having a separate function for this will all but disappear, I think.) > - fn = Fexpand_file_name (fn, Qnil); > + fn = make_lock_file_name (Fexpand_file_name (fn, Qnil)); In the original code, 'fn' was an un-encoded file name, but your changes made it encoded. Why not keep the code more similar by having a separate variable with the encoded file name? E.g., this would avoid potential trouble here: > if (!NILP (subject_buf) > && NILP (Fverify_visited_file_modtime (subject_buf)) > && !NILP (Ffile_exists_p (fn)) <<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Ffile_exists_p was passed an un-encoded file name in the original code. It calls file handlers, and encodes local file names by itself, so it is better to pass it un-encoded file names. > - && !(lfname && current_lock_owner (NULL, lfname) == -2)) > + && !(create_lockfiles && current_lock_owner (NULL, lfname) == -2)) > call1 (intern ("userlock--ask-user-about-supersession-threat"), fn); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Likewise here: Lisp function should generally be called with un-encoded file names. > unlock_file_body (Lisp_Object fn) > { > char *lfname; > - USE_SAFE_ALLOCA; > - > - Lisp_Object filename = Fexpand_file_name (fn, Qnil); > - fn = ENCODE_FILE (filename); > > - MAKE_LOCK_NAME (lfname, fn); > + Lisp_Object filename = make_lock_file_name (Fexpand_file_name (fn, Qnil)); > + lfname = SSDATA (filename); > > int err = current_lock_owner (0, lfname); > if (err == -2 && unlink (lfname) != 0 && errno != ENOENT) > @@ -736,7 +714,6 @@ unlock_file_body (Lisp_Object fn) > if (0 < err) > report_file_errno ("Unlocking file", filename, err); Same problem here: 'filename' is now an encoded file name, so you call report_file_errno with an encoded file name, which is a no-no. Last, but not least: do we care that now locking a file will cons strings, even with the default value of lock-file-name-transforms? That sounds like we are punishing the vast majority of users for the benefit of the few who need the opt-in behavior. Should we perhaps avoid consing strings, or maybe even calling Lisp altogether, under the default value of that option? Thanks. From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 07 14:09:05 2021 Received: (at 49261) by debbugs.gnu.org; 7 Jul 2021 18:09:05 +0000 Received: from localhost ([127.0.0.1]:53409 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1Byq-0006ES-DZ for submit@debbugs.gnu.org; Wed, 07 Jul 2021 14:09:05 -0400 Received: from quimby.gnus.org ([95.216.78.240]:54246) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1Byk-0006Du-Sl for 49261@debbugs.gnu.org; Wed, 07 Jul 2021 14:09:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=+8LpsFVLOSE7fGnFQa1rsLybXs80DxIFUO2yVDe5pbE=; b=ZdzWJCg6MYszPxQMCIG5cQSyab IdPiPgR0NCMigSk7DfDPW53yuZGFcRBks5vZbPhfa3pz43jYI2bBpuLL+9UVxwYRX30m+pSy+3y7G eqcShpmmKS736qcOImHYiWKDvAHBIXfvRnAAwMNrCtGqzT+PrG4RMNrIAsh31ss1pfqk=; Received: from cm-84.212.220.105.getinternet.no ([84.212.220.105] helo=elva) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m1Byb-0000Jx-2Q; Wed, 07 Jul 2021 20:08:51 +0200 From: Lars Ingebrigtsen To: Michael Albinus Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: <87o8bn7bie.fsf@gnus.org> <87zgv6vuon.fsf@gmx.de> <837di9lwbm.fsf@gnu.org> <87a6n5vuu4.fsf@gnus.org> <8735sqnmei.fsf@gnus.org> <87zguyf4ht.fsf@gmx.de> <87pmvum54p.fsf@gnus.org> <87v95mf2lj.fsf@gmx.de> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAElBMVEUHBwcoLixKVlRR dISqraj////Hgq6aAAAAAWJLR0QF+G/pxwAAAAd0SU1FB+UHBxIDNl6fdXwAAAGkSURBVDjLrZNh koMgDIWJ7gFI5AASPUAVDlAl9z/TBkTFzu6/OtOOzTckeY9XY777wJf71a72jxoC0YA0ftbD0OFr sJ4+EXVgFzLjMFJbnkzf8zRNvIYHgGg7YPSIRMvymGBNRx5HYw3ZDwBoDcJzgjEh00lWRP+o4yyJ Z1lUCyLWNbVnL+UpAtBWUzlKEtGv9XTldBtmrUfZrrbNVqDgXd9tJQeOSV61PoPF+4h2q8A7MA2g +WxFC+B4kyHKfk80/iIuSWrv7FrMbSIN6Oy54SxDA0x3bxX2FjTrpvgfcBfomBuw9xfomW+33A7p /PWI8ryZeGYAi4oqUatureKwEFfBS/NQvJk2rWfgbLmPt4E8ciWbw6Wln3krQE1nvfIAoOHNoJul 3K4WGXUieCU5QV25IZhsdQit6isgxZ0UH/nQnQytuacB+ZE4GoJDmIZKc81ZUvQSvSYWkbMC1Bdf LInbxPTqd40oHygnQj9hhyji/J4zujeJ9hbJSSLWOK55n9PLfHKQmDgPDSEwD5frLiJUX1UD+3CG zVtVcPwr9JQtzX4BceY4qJAP7wIAAAAQZVhJZklJKgAIAAAAAAAAAAAAAACcPLkoAAAAJXRFWHRk YXRlOmNyZWF0ZQAyMDIxLTA3LTA3VDE4OjAzOjU0KzAwOjAwPOfSYwAAACV0RVh0ZGF0ZTptb2Rp ZnkAMjAyMS0wNy0wN1QxODowMzo1NCswMDowME26at8AAAAASUVORK5CYII= X-Now-Playing: Tuxedomoon's _Live At The Palms (1978)_: "Cybernetic Cowboy" Date: Wed, 07 Jul 2021 20:08:48 +0200 In-Reply-To: <87v95mf2lj.fsf@gmx.de> (Michael Albinus's message of "Wed, 07 Jul 2021 19:36:24 +0200") Message-ID: <87lf6im1xr.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: While looking at this code, I'm puzzled by: - orig_fn = fn; - fn = Fexpand_file_name (fn, Qnil); -#ifdef WINDOWSNT - /* Ensure we have only '/' separators, to avoid problems with - looking (inside fill_in_lock_file_name) for backslashes in file [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49261 Cc: Eli Zaretskii , ncaprisunfan@gmail.com, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) --=-=-= Content-Type: text/plain While looking at this code, I'm puzzled by: - orig_fn = fn; - fn = Fexpand_file_name (fn, Qnil); -#ifdef WINDOWSNT - /* Ensure we have only '/' separators, to avoid problems with - looking (inside fill_in_lock_file_name) for backslashes in file - names encoded by some DBCS codepage. */ - dostounix_filename (SSDATA (fn)); -#endif - encoded_fn = ENCODE_FILE (fn); - if (create_lockfiles) - /* Create the name of the lock-file for file fn */ - MAKE_LOCK_NAME (lfname, encoded_fn); - So here we (possibly destructively) alter the data in the fn string on WINDOWSNT, because we want to avoid problems in fill_in_lock_file_name. OK, but we call MAKE_LOCK_NAME (which calls fill_in_lock_file_name) in two other places, and in those places the call isn't guarded by a call to dostounix_filename. This is moot after my patch, since MAKE_LOCK_NAME is gone, but I'm still worried that there's something I don't understand here... The dostounix_filename call was added by Eli in 2013. So I think I'll wait to push this patch until Eli has given it a once-over. I've included the current state of the patch below as an attachment. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no --=-=-= Content-Type: text/x-diff Content-Disposition: attachment; filename=lock.patch diff --git a/doc/emacs/files.texi b/doc/emacs/files.texi index 912980b688..98b6b194d2 100644 --- a/doc/emacs/files.texi +++ b/doc/emacs/files.texi @@ -789,7 +789,9 @@ Interlocking @vindex create-lockfiles You can prevent the creation of lock files by setting the variable @code{create-lockfiles} to @code{nil}. @strong{Caution:} by -doing so you will lose the benefits that this feature provides. +doing so you will lose the benefits that this feature provides. You +can also control where lock files are written by using the +@code{lock-file-name-transforms} variable. @cindex collision If you begin to modify the buffer while the visited file is locked by diff --git a/doc/lispref/files.texi b/doc/lispref/files.texi index 5238597a46..d73c502924 100644 --- a/doc/lispref/files.texi +++ b/doc/lispref/files.texi @@ -772,6 +772,20 @@ File Locks If this variable is @code{nil}, Emacs does not lock files. @end defopt +@defopt lock-file-name-transforms +By default, Emacs creates the lock files in the same directory as the +files that are being locked. This can be changed by customizing this +variable. Is has the same syntax as +@code{auto-save-file-name-transforms} (@pxref{Auto-Saving}). For +instance, to make Emacs write all the lock files to @file{/var/tmp/}, +you could say something like: + +@lisp +(setq lock-file-name-transforms + '(("\\`/.*/\\([^/]+\\)\\'" "/var/tmp/\\1" t))) +@end lisp +@end defopt + @defun ask-user-about-lock file other-user This function is called when the user tries to modify @var{file}, but it is locked by another user named @var{other-user}. The default diff --git a/doc/misc/efaq.texi b/doc/misc/efaq.texi index 53a3af4b78..caf5438edb 100644 --- a/doc/misc/efaq.texi +++ b/doc/misc/efaq.texi @@ -407,9 +407,9 @@ Mailing list archives @cindex Old mailing list posts for GNU lists @cindex Mailing list archives for GNU lists -The FSF has maintained archives of all of the GNU mailing lists for many -years, although there may be some unintentional gaps in coverage. The -archive can be browsed over the web at +The FSF has maintained archives of all of the GNU mailing lists for +many years, although there may be some unintentional gaps in coverage. +The archive can be browsed over the web at @uref{https://lists.gnu.org/r/, the GNU mail archive}. Some web-based Usenet search services also archive the @code{gnu.*} @@ -1519,6 +1519,7 @@ Common requests * Documentation for etags:: * Disabling backups:: * Disabling auto-save-mode:: +* Not writing files to the current directory:: * Going to a line by number:: * Modifying pull-down menus:: * Deleting menus and menu options:: @@ -2620,6 +2621,39 @@ Disabling auto-save-mode To disable or change how @code{auto-save-mode} works, @pxref{Auto Save,,, emacs, The GNU Emacs Manual}. +@node Not writing files to the current directory +@section Making Emacs write all auxiliary files somewhere else +@cindex Writing all auxiliary files to the same directory + +By default, Emacs may create many new files in the directory where +you're editing a file. If you're editing the file +@file{/home/user/foo.txt}, Emacs will create the lock file +@file{/home/user/.#foo.txt}, the auto-save file +@file{/home/user/#foo.txt#}, and when you save the file, Emacs will +create the backup file @file{/home/user/foo.txt~}. (The first two +files are deleted when you save the file.) + +This may be inconvenient in some setups, so Emacs has mechanisms for +changing the locations of all these files. + +@table @code +@item auto-save-file-name-transforms (@pxref{Auto-Saving,,,elisp, GNU Emacs Lisp Reference Manual}). +@item lock-file-name-transforms (@pxref{File Locks,,,elisp, GNU Emacs Lisp Reference Manual}). +@item backup-directory-alist (@pxref{Making Backups,,,elisp, GNU Emacs Lisp Reference Manual}). +@end table + +For instance, to write all these things to +@file{~/.emacs.d/aux/}: + +@lisp +(setq lock-file-name-transforms + '(("\\`/.*/\\([^/]+\\)\\'" "~/.emacs.d/aux/\\1" t))) +(setq auto-save-file-name-transforms + '(("\\`/.*/\\([^/]+\\)\\'" "~/.emacs.d/aux/\\1" t))) +(setq backup-directory-alist + '((".*" . "~/.emacs.d/aux/"))) +@end lisp + @node Going to a line by number @section How can I go to a certain line given its number? @cindex Going to a line by number diff --git a/etc/NEWS b/etc/NEWS index 7bf8c1d8f5..e398e3c789 100644 --- a/etc/NEWS +++ b/etc/NEWS @@ -2165,6 +2165,11 @@ summaries will include the failing condition. ** Miscellaneous ++++ +*** New user option 'lock-file-name-transforms'. +This option allows controlling where lock files are written. It uses +the same syntax as 'auto-save-file-name-transforms'. + +++ *** New user option 'kill-transform-function'. This can be used to transform (and suppress) strings from entering the diff --git a/lisp/files.el b/lisp/files.el index 859c193db9..205b429f9d 100644 --- a/lisp/files.el +++ b/lisp/files.el @@ -412,6 +412,21 @@ auto-save-file-name-transforms :initialize 'custom-initialize-delay :version "21.1") +(defcustom lock-file-name-transforms nil + "Transforms to apply to buffer file name before making a lock file name. +This has the same syntax as +`auto-save-file-name-transforms' (which see), but instead of +applying to auto-save file names, it's applied to lock file names. + +By default, a lock file is put into the same directory as the +file it's locking, and it has the same name, but with \".#\" prepended." + :group 'files + :type '(repeat (list (regexp :tag "Regexp") + (string :tag "Replacement") + (boolean :tag "Uniquify"))) + :initialize 'custom-initialize-delay + :version "28.1") + (defvar auto-save--timer nil "Timer for `auto-save-visited-mode'.") (defcustom auto-save-visited-interval 5 @@ -6668,63 +6683,11 @@ make-auto-save-file-name 'make-auto-save-file-name))) (if handler (funcall handler 'make-auto-save-file-name) - (let ((list auto-save-file-name-transforms) - (filename buffer-file-name) - result uniq) - ;; Apply user-specified translations - ;; to the file name. - (while (and list (not result)) - (if (string-match (car (car list)) filename) - (setq result (replace-match (cadr (car list)) t nil - filename) - uniq (car (cddr (car list))))) - (setq list (cdr list))) - (if result - (setq filename - (cond - ((memq uniq (secure-hash-algorithms)) - (concat - (file-name-directory result) - (secure-hash uniq filename))) - (uniq - (concat - (file-name-directory result) - (subst-char-in-string - ?/ ?! - (replace-regexp-in-string - "!" "!!" filename)))) - (t result)))) - (setq result - (if (and (eq system-type 'ms-dos) - (not (msdos-long-file-names))) - ;; We truncate the file name to DOS 8+3 limits - ;; before doing anything else, because the regexp - ;; passed to string-match below cannot handle - ;; extensions longer than 3 characters, multiple - ;; dots, and other atrocities. - (let ((fn (dos-8+3-filename - (file-name-nondirectory buffer-file-name)))) - (string-match - "\\`\\([^.]+\\)\\(\\.\\(..?\\)?.?\\|\\)\\'" - fn) - (concat (file-name-directory buffer-file-name) - "#" (match-string 1 fn) - "." (match-string 3 fn) "#")) - (concat (file-name-directory filename) - "#" - (file-name-nondirectory filename) - "#"))) - ;; Make sure auto-save file names don't contain characters - ;; invalid for the underlying filesystem. - (if (and (memq system-type '(ms-dos windows-nt cygwin)) - ;; Don't modify remote filenames - (not (file-remote-p result))) - (convert-standard-filename result) - result)))) - + (auto-save--transform-file-name buffer-file-name + auto-save-file-name-transforms + "#" "#"))) ;; Deal with buffers that don't have any associated files. (Mail ;; mode tends to create a good number of these.) - (let ((buffer-name (buffer-name)) (limit 0) file-name) @@ -6772,6 +6735,72 @@ make-auto-save-file-name (file-error nil)) file-name))) +(defun auto-save--transform-file-name (filename transforms + prefix suffix) + "Transform FILENAME according to TRANSFORMS. +See `auto-save-file-name-transforms' for the format of +TRANSFORMS. PREFIX is prepended to the non-directory portion of +the resulting file name, and SUFFIX is appended." + (let (result uniq) + ;; Apply user-specified translations + ;; to the file name. + (while (and transforms (not result)) + (if (string-match (car (car transforms)) filename) + (setq result (replace-match (cadr (car transforms)) t nil + filename) + uniq (car (cddr (car transforms))))) + (setq transforms (cdr transforms))) + (when result + (setq filename + (cond + ((memq uniq (secure-hash-algorithms)) + (concat + (file-name-directory result) + (secure-hash uniq filename))) + (uniq + (concat + (file-name-directory result) + (subst-char-in-string + ?/ ?! + (replace-regexp-in-string + "!" "!!" filename)))) + (t result)))) + (setq result + (if (and (eq system-type 'ms-dos) + (not (msdos-long-file-names))) + ;; We truncate the file name to DOS 8+3 limits + ;; before doing anything else, because the regexp + ;; passed to string-match below cannot handle + ;; extensions longer than 3 characters, multiple + ;; dots, and other atrocities. + (let ((fn (dos-8+3-filename + (file-name-nondirectory buffer-file-name)))) + (string-match + "\\`\\([^.]+\\)\\(\\.\\(..?\\)?.?\\|\\)\\'" + fn) + (concat (file-name-directory buffer-file-name) + prefix (match-string 1 fn) + "." (match-string 3 fn) suffix)) + (concat (file-name-directory filename) + prefix + (file-name-nondirectory filename) + suffix))) + ;; Make sure auto-save file names don't contain characters + ;; invalid for the underlying filesystem. + (expand-file-name + (if (and (memq system-type '(ms-dos windows-nt cygwin)) + ;; Don't modify remote filenames + (not (file-remote-p result))) + (convert-standard-filename result) + result)))) + +(defun make-lock-file-name (filename) + "Make a lock file name for FILENAME. +By default, this just prepends \".*\" to the non-directory part +of FILENAME, but the transforms in `lock-file-name-transforms' +are done first." + (auto-save--transform-file-name filename lock-file-name-transforms ".#" "")) + (defun auto-save-file-name-p (filename) "Return non-nil if FILENAME can be yielded by `make-auto-save-file-name'. FILENAME should lack slashes. diff --git a/src/filelock.c b/src/filelock.c index 446a262a1c..cda7e2f8f6 100644 --- a/src/filelock.c +++ b/src/filelock.c @@ -51,7 +51,6 @@ Copyright (C) 1985-1987, 1993-1994, 1996, 1998-2021 Free Software #ifdef WINDOWSNT #include #include /* for fcntl */ -#include "w32.h" /* for dostounix_filename */ #endif #ifndef MSDOS @@ -294,25 +293,6 @@ get_boot_time_1 (const char *filename, bool newest) char user[MAX_LFINFO + 1 + sizeof " (pid )" - sizeof "."]; } lock_info_type; -/* Write the name of the lock file for FNAME into LOCKNAME. Length - will be that of FNAME plus two more for the leading ".#", plus one - for the null. */ -#define MAKE_LOCK_NAME(lockname, fname) \ - (lockname = SAFE_ALLOCA (SBYTES (fname) + 2 + 1), \ - fill_in_lock_file_name (lockname, fname)) - -static void -fill_in_lock_file_name (char *lockfile, Lisp_Object fn) -{ - char *last_slash = memrchr (SSDATA (fn), '/', SBYTES (fn)); - char *base = last_slash + 1; - ptrdiff_t dirlen = base - SSDATA (fn); - memcpy (lockfile, SSDATA (fn), dirlen); - lockfile[dirlen] = '.'; - lockfile[dirlen + 1] = '#'; - strcpy (lockfile + dirlen + 2, base); -} - /* For some reason Linux kernels return EPERM on file systems that do not support hard or symbolic links. This symbol documents the quirk. There is no way to tell whether a symlink call fails due to @@ -639,6 +619,13 @@ lock_if_free (lock_info_type *clasher, char *lfname) return err; } +static Lisp_Object +make_lock_file_name (Lisp_Object fn) +{ + return ENCODE_FILE (call1 (intern ("make-lock-file-name"), + Fexpand_file_name (fn, Qnil))); +} + /* lock_file locks file FN, meaning it serves notice on the world that you intend to edit that file. This should be done only when about to modify a file-visiting @@ -660,10 +647,9 @@ lock_if_free (lock_info_type *clasher, char *lfname) void lock_file (Lisp_Object fn) { - Lisp_Object orig_fn, encoded_fn; + Lisp_Object lock_filename; char *lfname = NULL; lock_info_type lock_info; - USE_SAFE_ALLOCA; /* Don't do locking while dumping Emacs. Uncompressing wtmp files uses call-process, which does not work @@ -671,30 +657,19 @@ lock_file (Lisp_Object fn) if (will_dump_p ()) return; - orig_fn = fn; - fn = Fexpand_file_name (fn, Qnil); -#ifdef WINDOWSNT - /* Ensure we have only '/' separators, to avoid problems with - looking (inside fill_in_lock_file_name) for backslashes in file - names encoded by some DBCS codepage. */ - dostounix_filename (SSDATA (fn)); -#endif - encoded_fn = ENCODE_FILE (fn); - if (create_lockfiles) - /* Create the name of the lock-file for file fn */ - MAKE_LOCK_NAME (lfname, encoded_fn); - + lock_filename = make_lock_file_name (fn); + lfname = SSDATA (lock_filename); /* See if this file is visited and has changed on disk since it was visited. */ - Lisp_Object subject_buf = get_truename_buffer (orig_fn); + Lisp_Object subject_buf = get_truename_buffer (fn); if (!NILP (subject_buf) && NILP (Fverify_visited_file_modtime (subject_buf)) - && !NILP (Ffile_exists_p (fn)) - && !(lfname && current_lock_owner (NULL, lfname) == -2)) + && !NILP (Ffile_exists_p (lock_filename)) + && !(create_lockfiles && current_lock_owner (NULL, lfname) == -2)) call1 (intern ("userlock--ask-user-about-supersession-threat"), fn); /* Don't do locking if the user has opted out. */ - if (lfname) + if (create_lockfiles) { /* Try to lock the lock. FIXME: This ignores errors when lock_if_free returns a positive errno value. */ @@ -715,7 +690,6 @@ lock_file (Lisp_Object fn) if (!NILP (attack)) lock_file_1 (lfname, 1); } - SAFE_FREE (); } } @@ -723,12 +697,9 @@ lock_file (Lisp_Object fn) unlock_file_body (Lisp_Object fn) { char *lfname; - USE_SAFE_ALLOCA; - - Lisp_Object filename = Fexpand_file_name (fn, Qnil); - fn = ENCODE_FILE (filename); - MAKE_LOCK_NAME (lfname, fn); + Lisp_Object filename = make_lock_file_name (fn); + lfname = SSDATA (filename); int err = current_lock_owner (0, lfname); if (err == -2 && unlink (lfname) != 0 && errno != ENOENT) @@ -736,7 +707,6 @@ unlock_file_body (Lisp_Object fn) if (0 < err) report_file_errno ("Unlocking file", filename, err); - SAFE_FREE (); return Qnil; } @@ -842,11 +812,9 @@ DEFUN ("file-locked-p", Ffile_locked_p, Sfile_locked_p, 1, 1, 0, char *lfname; int owner; lock_info_type locker; - USE_SAFE_ALLOCA; - filename = Fexpand_file_name (filename, Qnil); - Lisp_Object encoded_filename = ENCODE_FILE (filename); - MAKE_LOCK_NAME (lfname, encoded_filename); + Lisp_Object lockname = make_lock_file_name (filename); + lfname = SSDATA (lockname); owner = current_lock_owner (&locker, lfname); switch (owner) @@ -857,7 +825,6 @@ DEFUN ("file-locked-p", Ffile_locked_p, Sfile_locked_p, 1, 1, 0, default: report_file_errno ("Testing file lock", filename, owner); } - SAFE_FREE (); return ret; #endif } diff --git a/test/lisp/files-tests.el b/test/lisp/files-tests.el index 257cbc2d32..a6b0c900be 100644 --- a/test/lisp/files-tests.el +++ b/test/lisp/files-tests.el @@ -949,6 +949,44 @@ files-tests-file-name-non-special-make-auto-save-file-name (make-auto-save-file-name) (kill-buffer))))))) +(ert-deftest files-test-auto-save-name-default () + (with-temp-buffer + (let ((auto-save-file-name-transforms nil)) + (setq buffer-file-name "/tmp/foo.txt") + (should (equal (make-auto-save-file-name) "/tmp/#foo.txt#"))))) + +(ert-deftest files-test-auto-save-name-transform () + (with-temp-buffer + (setq buffer-file-name "/tmp/foo.txt") + (let ((auto-save-file-name-transforms + '(("\\`/.*/\\([^/]+\\)\\'" "/var/tmp/\\1" nil)))) + (should (equal (make-auto-save-file-name) "/var/tmp/#foo.txt#"))))) + +(ert-deftest files-test-auto-save-name-unique () + (with-temp-buffer + (setq buffer-file-name "/tmp/foo.txt") + (let ((auto-save-file-name-transforms + '(("\\`/.*/\\([^/]+\\)\\'" "/var/tmp/\\1" t)))) + (should (equal (make-auto-save-file-name) "/var/tmp/#!tmp!foo.txt#"))) + (let ((auto-save-file-name-transforms + '(("\\`/.*/\\([^/]+\\)\\'" "/var/tmp/\\1" sha1)))) + (should (equal (make-auto-save-file-name) + "/var/tmp/#b57c5a04f429a83305859d3350ecdab8315a9037#"))))) + +(ert-deftest files-test-lock-name-default () + (let ((lock-file-name-transforms nil)) + (should (equal (make-lock-file-name "/tmp/foo.txt") "/tmp/.#foo.txt")))) + +(ert-deftest files-test-lock-name-unique () + (let ((lock-file-name-transforms + '(("\\`/.*/\\([^/]+\\)\\'" "/var/tmp/\\1" t)))) + (should (equal (make-lock-file-name "/tmp/foo.txt") + "/var/tmp/.#!tmp!foo.txt"))) + (let ((lock-file-name-transforms + '(("\\`/.*/\\([^/]+\\)\\'" "/var/tmp/\\1" sha1)))) + (should (equal (make-lock-file-name "/tmp/foo.txt") + "/var/tmp/.#b57c5a04f429a83305859d3350ecdab8315a9037")))) + (ert-deftest files-tests-file-name-non-special-make-directory () (files-tests--with-temp-non-special (tmpdir nospecial-dir t) (let ((default-directory nospecial-dir)) --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 07 14:17:35 2021 Received: (at 49261) by debbugs.gnu.org; 7 Jul 2021 18:17:35 +0000 Received: from localhost ([127.0.0.1]:53425 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1C75-0006Rv-HQ for submit@debbugs.gnu.org; Wed, 07 Jul 2021 14:17:35 -0400 Received: from quimby.gnus.org ([95.216.78.240]:54304) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1C73-0006Ri-Cl for 49261@debbugs.gnu.org; Wed, 07 Jul 2021 14:17:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=52B7Sn6Q/ZIdvYClXhwS4LHosDkMzwRXjDTbfDgNOR0=; b=L2BDssLozLQYwch5LlGsMiCuox CRZh3C+XpjsJihasTq2QzlCQlrV302pQcQY4W/PMmhrCPP6WSuS0hRBHcVgVvPOEFo0DlsT0qn3xh TLVeupu/LrqeRfUzr8wbJ8kHLar2ACVB2u6RQnvZq2jZJT2UVrbtF50Sz9ebtPHoOjAI=; Received: from cm-84.212.220.105.getinternet.no ([84.212.220.105] helo=elva) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m1C6t-0000QD-MZ; Wed, 07 Jul 2021 20:17:26 +0200 From: Lars Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: <87o8bn7bie.fsf@gnus.org> <87zgv6vuon.fsf@gmx.de> <837di9lwbm.fsf@gnu.org> <87a6n5vuu4.fsf@gnus.org> <8735sqnmei.fsf@gnus.org> <834kd6f1dw.fsf@gnu.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAElBMVEUHBwcoLixKVlRR dISqraj////Hgq6aAAAAAWJLR0QF+G/pxwAAAAd0SU1FB+UHBxIDNl6fdXwAAAGkSURBVDjLrZNh koMgDIWJ7gFI5AASPUAVDlAl9z/TBkTFzu6/OtOOzTckeY9XY777wJf71a72jxoC0YA0ftbD0OFr sJ4+EXVgFzLjMFJbnkzf8zRNvIYHgGg7YPSIRMvymGBNRx5HYw3ZDwBoDcJzgjEh00lWRP+o4yyJ Z1lUCyLWNbVnL+UpAtBWUzlKEtGv9XTldBtmrUfZrrbNVqDgXd9tJQeOSV61PoPF+4h2q8A7MA2g +WxFC+B4kyHKfk80/iIuSWrv7FrMbSIN6Oy54SxDA0x3bxX2FjTrpvgfcBfomBuw9xfomW+33A7p /PWI8ryZeGYAi4oqUatureKwEFfBS/NQvJk2rWfgbLmPt4E8ciWbw6Wln3krQE1nvfIAoOHNoJul 3K4WGXUieCU5QV25IZhsdQit6isgxZ0UH/nQnQytuacB+ZE4GoJDmIZKc81ZUvQSvSYWkbMC1Bdf LInbxPTqd40oHygnQj9hhyji/J4zujeJ9hbJSSLWOK55n9PLfHKQmDgPDSEwD5frLiJUX1UD+3CG zVtVcPwr9JQtzX4BceY4qJAP7wIAAAAQZVhJZklJKgAIAAAAAAAAAAAAAACcPLkoAAAAJXRFWHRk YXRlOmNyZWF0ZQAyMDIxLTA3LTA3VDE4OjAzOjU0KzAwOjAwPOfSYwAAACV0RVh0ZGF0ZTptb2Rp ZnkAMjAyMS0wNy0wN1QxODowMzo1NCswMDowME26at8AAAAASUVORK5CYII= X-Now-Playing: Tuxedomoon's _Live At The Palms (1978)_: "Ballad of the Coalminer" Date: Wed, 07 Jul 2021 20:17:22 +0200 In-Reply-To: <834kd6f1dw.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 07 Jul 2021 21:02:35 +0300") Message-ID: <87h7h6m1jh.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Eli Zaretskii writes: > If this is going to be called from C, it should probably use > save-match-data, because no one will expect that just modifying a file > from some Lisp program could clobber the match data. Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49261 Cc: michael.albinus@gmx.de, ncaprisunfan@gmail.com, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: > If this is going to be called from C, it should probably use > save-match-data, because no one will expect that just modifying a file > from some Lisp program could clobber the match data. Right; now added. > Also, do we ever need this during loadup? Because before files.el is > loaded by loadup, this function will not be available, so > unconditionally calling it from C without protection, not even > safe_call or somesuch, is not safe. I'll try doing a "make bootstrap"... >> +static Lisp_Object >> +make_lock_file_name (Lisp_Object fn) >> +{ >> + return ENCODE_FILE (call1 (intern ("make-lock-file-name"), fn)); >> +} > > I'd prefer not to have a function return an encoded file name, it's > unusual and unexpected. It is better to leave that to the caller. > (And if you do that, the rationale for having a separate function for > this will all but disappear, I think.) Right. But it seemed like all the callers wanted an encoded file name here, so it was marginally cleaner. >> - fn = Fexpand_file_name (fn, Qnil); >> + fn = make_lock_file_name (Fexpand_file_name (fn, Qnil)); > > In the original code, 'fn' was an un-encoded file name, but your > changes made it encoded. Why not keep the code more similar by having > a separate variable with the encoded file name? E.g., this would > avoid potential trouble here: Yup; I've now rewritten this to not reuse variables in this way, because it was pretty confusing. (See the version of the patch I posted some minutes ago.) >> if (!NILP (subject_buf) >> && NILP (Fverify_visited_file_modtime (subject_buf)) >> && !NILP (Ffile_exists_p (fn)) <<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > Ffile_exists_p was passed an un-encoded file name in the original > code. It calls file handlers, and encodes local file names by itself, > so it is better to pass it un-encoded file names. [...] > Same problem here: 'filename' is now an encoded file name, so you call > report_file_errno with an encoded file name, which is a no-no. Right; I'll fix up the un-encoded/encoded file name confusion here. > Last, but not least: do we care that now locking a file will cons > strings, even with the default value of lock-file-name-transforms? > That sounds like we are punishing the vast majority of users for the > benefit of the few who need the opt-in behavior. Should we perhaps > avoid consing strings, or maybe even calling Lisp altogether, under > the default value of that option? Hm... I think for simplicity's sake, it makes sense to always call the Lisp code. Having two places where we insert ".#" into a file name just seems error prone, long term. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 07 14:20:26 2021 Received: (at 49261) by debbugs.gnu.org; 7 Jul 2021 18:20:26 +0000 Received: from localhost ([127.0.0.1]:53429 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1C9q-0006WM-29 for submit@debbugs.gnu.org; Wed, 07 Jul 2021 14:20:26 -0400 Received: from quimby.gnus.org ([95.216.78.240]:54328) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1C9o-0006W9-0d for 49261@debbugs.gnu.org; Wed, 07 Jul 2021 14:20:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=9vcuJz4Kb0RYAuqhhQnlT4WFwajjshcEqhy+6fbccHU=; b=J9+loe3FVXpSSqdy40L1g6YKXp Of4iY8iL5j0inZHNLS8Vqv9dAcz+/W6MZQFrL01rdoM3ur+LHnx3oKqunCaY9e4vZg860HvgoOkLS qmrYjxYPn4EyJQh98/Gyx9hmpXEeJTq8e4pJbHdeKBIH3DEJMKwrjYbLvgyo9BOXqHIo=; Received: from cm-84.212.220.105.getinternet.no ([84.212.220.105] helo=elva) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m1C9f-0000TC-KA; Wed, 07 Jul 2021 20:20:18 +0200 From: Lars Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: <87o8bn7bie.fsf@gnus.org> <87zgv6vuon.fsf@gmx.de> <837di9lwbm.fsf@gnu.org> <87a6n5vuu4.fsf@gnus.org> <8735sqnmei.fsf@gnus.org> <834kd6f1dw.fsf@gnu.org> <87h7h6m1jh.fsf@gnus.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAElBMVEUHBwcoLixKVlRR dISqraj////Hgq6aAAAAAWJLR0QF+G/pxwAAAAd0SU1FB+UHBxIDNl6fdXwAAAGkSURBVDjLrZNh koMgDIWJ7gFI5AASPUAVDlAl9z/TBkTFzu6/OtOOzTckeY9XY777wJf71a72jxoC0YA0ftbD0OFr sJ4+EXVgFzLjMFJbnkzf8zRNvIYHgGg7YPSIRMvymGBNRx5HYw3ZDwBoDcJzgjEh00lWRP+o4yyJ Z1lUCyLWNbVnL+UpAtBWUzlKEtGv9XTldBtmrUfZrrbNVqDgXd9tJQeOSV61PoPF+4h2q8A7MA2g +WxFC+B4kyHKfk80/iIuSWrv7FrMbSIN6Oy54SxDA0x3bxX2FjTrpvgfcBfomBuw9xfomW+33A7p /PWI8ryZeGYAi4oqUatureKwEFfBS/NQvJk2rWfgbLmPt4E8ciWbw6Wln3krQE1nvfIAoOHNoJul 3K4WGXUieCU5QV25IZhsdQit6isgxZ0UH/nQnQytuacB+ZE4GoJDmIZKc81ZUvQSvSYWkbMC1Bdf LInbxPTqd40oHygnQj9hhyji/J4zujeJ9hbJSSLWOK55n9PLfHKQmDgPDSEwD5frLiJUX1UD+3CG zVtVcPwr9JQtzX4BceY4qJAP7wIAAAAQZVhJZklJKgAIAAAAAAAAAAAAAACcPLkoAAAAJXRFWHRk YXRlOmNyZWF0ZQAyMDIxLTA3LTA3VDE4OjAzOjU0KzAwOjAwPOfSYwAAACV0RVh0ZGF0ZTptb2Rp ZnkAMjAyMS0wNy0wN1QxODowMzo1NCswMDowME26at8AAAAASUVORK5CYII= X-Now-Playing: Tuxedomoon's _Live At The Palms (1978)_: "Rhumba (edit)" Date: Wed, 07 Jul 2021 20:20:15 +0200 In-Reply-To: <87h7h6m1jh.fsf@gnus.org> (Lars Ingebrigtsen's message of "Wed, 07 Jul 2021 20:17:22 +0200") Message-ID: <87czrum1eo.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Lars Ingebrigtsen writes: >> Also, do we ever need this during loadup? Because before files.el is >> loaded by loadup, this function will not be available, so >> unconditionally calling it from C without protection, not even > [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49261 Cc: michael.albinus@gmx.de, ncaprisunfan@gmail.com, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Lars Ingebrigtsen writes: >> Also, do we ever need this during loadup? Because before files.el is >> loaded by loadup, this function will not be available, so >> unconditionally calling it from C without protection, not even >> safe_call or somesuch, is not safe. > > I'll try doing a "make bootstrap"... And that's finished now, and went without a hitch with the new patch. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 07 14:33:55 2021 Received: (at 49261) by debbugs.gnu.org; 7 Jul 2021 18:33:55 +0000 Received: from localhost ([127.0.0.1]:53442 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1CMt-0006sn-FI for submit@debbugs.gnu.org; Wed, 07 Jul 2021 14:33:55 -0400 Received: from eggs.gnu.org ([209.51.188.92]:34922) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1CMo-0006sX-IY for 49261@debbugs.gnu.org; Wed, 07 Jul 2021 14:33:53 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:41566) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m1CMf-0007Lv-S7; Wed, 07 Jul 2021 14:33:43 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2814 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m1CMf-0007Vg-4m; Wed, 07 Jul 2021 14:33:41 -0400 Date: Wed, 07 Jul 2021 21:33:48 +0300 Message-Id: <8335sqezxv.fsf@gnu.org> From: Eli Zaretskii To: Lars Ingebrigtsen In-Reply-To: <87lf6im1xr.fsf@gnus.org> (message from Lars Ingebrigtsen on Wed, 07 Jul 2021 20:08:48 +0200) Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: <87o8bn7bie.fsf@gnus.org> <87zgv6vuon.fsf@gmx.de> <837di9lwbm.fsf@gnu.org> <87a6n5vuu4.fsf@gnus.org> <8735sqnmei.fsf@gnus.org> <87zguyf4ht.fsf@gmx.de> <87pmvum54p.fsf@gnus.org> <87v95mf2lj.fsf@gmx.de> <87lf6im1xr.fsf@gnus.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49261 Cc: michael.albinus@gmx.de, ncaprisunfan@gmail.com, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Lars Ingebrigtsen > Cc: Eli Zaretskii , ncaprisunfan@gmail.com, > 49261@debbugs.gnu.org > Date: Wed, 07 Jul 2021 20:08:48 +0200 > > While looking at this code, I'm puzzled by: > > - orig_fn = fn; > - fn = Fexpand_file_name (fn, Qnil); > -#ifdef WINDOWSNT > - /* Ensure we have only '/' separators, to avoid problems with > - looking (inside fill_in_lock_file_name) for backslashes in file > - names encoded by some DBCS codepage. */ > - dostounix_filename (SSDATA (fn)); > -#endif > - encoded_fn = ENCODE_FILE (fn); > - if (create_lockfiles) > - /* Create the name of the lock-file for file fn */ > - MAKE_LOCK_NAME (lfname, encoded_fn); > - > > So here we (possibly destructively) alter the data in the fn string on > WINDOWSNT, because we want to avoid problems in fill_in_lock_file_name. > OK, but we call MAKE_LOCK_NAME (which calls fill_in_lock_file_name) in > two other places, and in those places the call isn't guarded by a call > to dostounix_filename. > > This is moot after my patch, since MAKE_LOCK_NAME is gone, but I'm still > worried that there's something I don't understand here... The > dostounix_filename call was added by Eli in 2013. It's a bug. Or maybe it was a bug, back then, because I think nowadays expand-file-name always converts backslashes to forward slashes. And actually the fact that MAKE_LOCK_NAME looks for slashes in encoded file names is also a subtle bug (or at least unsafe code): some coding-systems don't guarantee that a '/' byte can never be part of a multibyte sequence. From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 07 14:42:29 2021 Received: (at 49261) by debbugs.gnu.org; 7 Jul 2021 18:42:29 +0000 Received: from localhost ([127.0.0.1]:53457 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1CVA-00078V-UP for submit@debbugs.gnu.org; Wed, 07 Jul 2021 14:42:29 -0400 Received: from eggs.gnu.org ([209.51.188.92]:36666) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1CV9-00078F-7C for 49261@debbugs.gnu.org; Wed, 07 Jul 2021 14:42:27 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:41780) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m1CV1-0000BZ-Is; Wed, 07 Jul 2021 14:42:21 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3344 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m1CV1-00018Y-6a; Wed, 07 Jul 2021 14:42:19 -0400 Date: Wed, 07 Jul 2021 21:42:28 +0300 Message-Id: <83zguydkyz.fsf@gnu.org> From: Eli Zaretskii To: Lars Ingebrigtsen In-Reply-To: <87h7h6m1jh.fsf@gnus.org> (message from Lars Ingebrigtsen on Wed, 07 Jul 2021 20:17:22 +0200) Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: <87o8bn7bie.fsf@gnus.org> <87zgv6vuon.fsf@gmx.de> <837di9lwbm.fsf@gnu.org> <87a6n5vuu4.fsf@gnus.org> <8735sqnmei.fsf@gnus.org> <834kd6f1dw.fsf@gnu.org> <87h7h6m1jh.fsf@gnus.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49261 Cc: michael.albinus@gmx.de, ncaprisunfan@gmail.com, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Lars Ingebrigtsen > Cc: michael.albinus@gmx.de, ncaprisunfan@gmail.com, 49261@debbugs.gnu.org > Date: Wed, 07 Jul 2021 20:17:22 +0200 > > > Also, do we ever need this during loadup? Because before files.el is > > loaded by loadup, this function will not be available, so > > unconditionally calling it from C without protection, not even > > safe_call or somesuch, is not safe. > > I'll try doing a "make bootstrap"... Even if it currently works, it's unsafe, IMO, to not have any protection there. No one will remember that we rely on this not being called early enough. > > Last, but not least: do we care that now locking a file will cons > > strings, even with the default value of lock-file-name-transforms? > > That sounds like we are punishing the vast majority of users for the > > benefit of the few who need the opt-in behavior. Should we perhaps > > avoid consing strings, or maybe even calling Lisp altogether, under > > the default value of that option? > > Hm... I think for simplicity's sake, it makes sense to always call the > Lisp code. Having two places where we insert ".#" into a file name just > seems error prone, long term. My point is that this simplicity comes at a price. We've been consistently moving code from C primitives to Lisp, and by doing that significantly increase the consing during even the simplest editing operations. All this consing adds up, with the result that Emacs nowadays produces much more garbage, which then triggers frequent GC cycles, which slow down Emacs. It's a small wonder we see so many people out there raising the GC threshold to dangerous levels. So I'm asking whether the simplicity justifies the costs, here and elsewhere. From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 07 14:50:30 2021 Received: (at 49261) by debbugs.gnu.org; 7 Jul 2021 18:50:30 +0000 Received: from localhost ([127.0.0.1]:53461 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1Ccv-0007NH-Rc for submit@debbugs.gnu.org; Wed, 07 Jul 2021 14:50:30 -0400 Received: from quimby.gnus.org ([95.216.78.240]:54544) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1Ccr-0007Mw-Pk for 49261@debbugs.gnu.org; Wed, 07 Jul 2021 14:50:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=lcp3Ry/pxJ0jkgpMxm3U9hDNkCk67c1+1HV//mH/nqc=; b=BPEj0JTP6vNQWulB4HxDWLDu1W nIqyOX0fh0oAiNqCASjKwg76Oxm9kl/N9Tm0qozkQlonVlRgDdyWYvoxENa+dnRmuEZhNxc0tsq2e nwDLNtzgQ/Wqo8xJeLbxsqzyRJnaIE1W4xng3VE6aByo8PlwOsBana7yzgQ3BatrRJdc=; Received: from cm-84.212.220.105.getinternet.no ([84.212.220.105] helo=elva) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m1Cch-0000kM-WA; Wed, 07 Jul 2021 20:50:18 +0200 From: Lars Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: <87o8bn7bie.fsf@gnus.org> <87zgv6vuon.fsf@gmx.de> <837di9lwbm.fsf@gnu.org> <87a6n5vuu4.fsf@gnus.org> <8735sqnmei.fsf@gnus.org> <87zguyf4ht.fsf@gmx.de> <87pmvum54p.fsf@gnus.org> <87v95mf2lj.fsf@gmx.de> <87lf6im1xr.fsf@gnus.org> <8335sqezxv.fsf@gnu.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAElBMVEUHBwcoLixKVlRR dISqraj////Hgq6aAAAAAWJLR0QF+G/pxwAAAAd0SU1FB+UHBxIxKEngHG4AAAGkSURBVDjLrZNh koMgDIWJ7gFI5AASPUAVDlAl9z/TBkTFzu6/OtOOzTckeY9XY777wJf71a72jxoC0YA0ftbD0OFr sJ4+EXVgFzLjMFJbnkzf8zRNvIYHgGg7YPSIRMvymGBNRx5HYw3ZDwBoDcJzgjEh00lWRP+o4yyJ Z1lUCyLWNbVnL+UpAtBWUzlKEtGv9XTldBtmrUfZrrbNVqDgXd9tJQeOSV61PoPF+4h2q8A7MA2g +WxFC+B4kyHKfk80/iIuSWrv7FrMbSIN6Oy54SxDA0x3bxX2FjTrpvgfcBfomBuw9xfomW+33A7p /PWI8ryZeGYAi4oqUatureKwEFfBS/NQvJk2rWfgbLmPt4E8ciWbw6Wln3krQE1nvfIAoOHNoJul 3K4WGXUieCU5QV25IZhsdQit6isgxZ0UH/nQnQytuacB+ZE4GoJDmIZKc81ZUvQSvSYWkbMC1Bdf LInbxPTqd40oHygnQj9hhyji/J4zujeJ9hbJSSLWOK55n9PLfHKQmDgPDSEwD5frLiJUX1UD+3CG zVtVcPwr9JQtzX4BceY4qJAP7wIAAAAQZVhJZklJKgAIAAAAAAAAAAAAAACcPLkoAAAAJXRFWHRk YXRlOmNyZWF0ZQAyMDIxLTA3LTA3VDE4OjQ5OjM5KzAwOjAwPKRZbwAAACV0RVh0ZGF0ZTptb2Rp ZnkAMjAyMS0wNy0wN1QxODo0OTozOSswMDowME354dMAAAAASUVORK5CYII= X-Now-Playing: Tuxedomoon's _Live At The Palms (1978)_: "Cell Life" Date: Wed, 07 Jul 2021 20:50:15 +0200 In-Reply-To: <8335sqezxv.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 07 Jul 2021 21:33:48 +0300") Message-ID: <87czru3qmw.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Eli Zaretskii writes: > It's a bug. Or maybe it was a bug, back then, because I think > nowadays expand-file-name always converts backslashes to forward > slashes. And actually the fact that MAKE_LOCK_NAME looks for slashe [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49261 Cc: michael.albinus@gmx.de, ncaprisunfan@gmail.com, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: > It's a bug. Or maybe it was a bug, back then, because I think > nowadays expand-file-name always converts backslashes to forward > slashes. And actually the fact that MAKE_LOCK_NAME looks for slashes > in encoded file names is also a subtle bug (or at least unsafe code): > some coding-systems don't guarantee that a '/' byte can never be part > of a multibyte sequence. Ah, cool, then I wasn't totally misreading the code. :-) -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 07 14:50:39 2021 Received: (at 49261) by debbugs.gnu.org; 7 Jul 2021 18:50:39 +0000 Received: from localhost ([127.0.0.1]:53464 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1Cd5-0007Nd-2V for submit@debbugs.gnu.org; Wed, 07 Jul 2021 14:50:39 -0400 Received: from eggs.gnu.org ([209.51.188.92]:38176) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1Cd0-0007NG-Jv for 49261@debbugs.gnu.org; Wed, 07 Jul 2021 14:50:37 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:41922) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m1Ccu-0001HH-Vn; Wed, 07 Jul 2021 14:50:28 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3844 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m1Ccu-0001ng-JF; Wed, 07 Jul 2021 14:50:28 -0400 Date: Wed, 07 Jul 2021 21:50:38 +0300 Message-Id: <83wnq2dkld.fsf@gnu.org> From: Eli Zaretskii To: Lars Ingebrigtsen In-Reply-To: <87h7h6m1jh.fsf@gnus.org> (message from Lars Ingebrigtsen on Wed, 07 Jul 2021 20:17:22 +0200) Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: <87o8bn7bie.fsf@gnus.org> <87zgv6vuon.fsf@gmx.de> <837di9lwbm.fsf@gnu.org> <87a6n5vuu4.fsf@gnus.org> <8735sqnmei.fsf@gnus.org> <834kd6f1dw.fsf@gnu.org> <87h7h6m1jh.fsf@gnus.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49261 Cc: michael.albinus@gmx.de, ncaprisunfan@gmail.com, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Lars Ingebrigtsen > Cc: michael.albinus@gmx.de, ncaprisunfan@gmail.com, 49261@debbugs.gnu.org > Date: Wed, 07 Jul 2021 20:17:22 +0200 > > Hm... I think for simplicity's sake, it makes sense to always call the > Lisp code. Having two places where we insert ".#" into a file name just > seems error prone, long term. Btw, we could avoid having 2 places that produces the default ".#"+FILENAME lock file name by exposing to Lisp a C primitive which does that. So that problem can easily be solved. From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 07 14:58:41 2021 Received: (at 49261) by debbugs.gnu.org; 7 Jul 2021 18:58:41 +0000 Received: from localhost ([127.0.0.1]:53498 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1Ckq-0007dK-Pn for submit@debbugs.gnu.org; Wed, 07 Jul 2021 14:58:41 -0400 Received: from quimby.gnus.org ([95.216.78.240]:54598) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1Ckp-0007d2-Iu for 49261@debbugs.gnu.org; Wed, 07 Jul 2021 14:58:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=MZFNT05YYat8ZvefE/nBRI7NLKtq3cXR2DTAloZ6idY=; b=OkBPSpWfrBKAcyNvlPfNH0i7h0 GEvvIDThKORoUPybVFg6XMhCzXnCiooX+kGYfmE1GRmtytGFc4NTyPs+UgQdDbQD83pFK0yOa0HNp 9P2WkL/RZ+JibScWyFi02yZ/mOo1VrSbSANzuj9VtmErVQ52dnKseVHflPPL/9e2OXAk=; Received: from cm-84.212.220.105.getinternet.no ([84.212.220.105] helo=elva) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m1Ckf-0000nF-QI; Wed, 07 Jul 2021 20:58:32 +0200 From: Lars Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: <87o8bn7bie.fsf@gnus.org> <87zgv6vuon.fsf@gmx.de> <837di9lwbm.fsf@gnu.org> <87a6n5vuu4.fsf@gnus.org> <8735sqnmei.fsf@gnus.org> <834kd6f1dw.fsf@gnu.org> <87h7h6m1jh.fsf@gnus.org> <83zguydkyz.fsf@gnu.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAElBMVEUHBwcoLixKVlRR dISqraj////Hgq6aAAAAAWJLR0QF+G/pxwAAAAd0SU1FB+UHBxIxKEngHG4AAAGkSURBVDjLrZNh koMgDIWJ7gFI5AASPUAVDlAl9z/TBkTFzu6/OtOOzTckeY9XY777wJf71a72jxoC0YA0ftbD0OFr sJ4+EXVgFzLjMFJbnkzf8zRNvIYHgGg7YPSIRMvymGBNRx5HYw3ZDwBoDcJzgjEh00lWRP+o4yyJ Z1lUCyLWNbVnL+UpAtBWUzlKEtGv9XTldBtmrUfZrrbNVqDgXd9tJQeOSV61PoPF+4h2q8A7MA2g +WxFC+B4kyHKfk80/iIuSWrv7FrMbSIN6Oy54SxDA0x3bxX2FjTrpvgfcBfomBuw9xfomW+33A7p /PWI8ryZeGYAi4oqUatureKwEFfBS/NQvJk2rWfgbLmPt4E8ciWbw6Wln3krQE1nvfIAoOHNoJul 3K4WGXUieCU5QV25IZhsdQit6isgxZ0UH/nQnQytuacB+ZE4GoJDmIZKc81ZUvQSvSYWkbMC1Bdf LInbxPTqd40oHygnQj9hhyji/J4zujeJ9hbJSSLWOK55n9PLfHKQmDgPDSEwD5frLiJUX1UD+3CG zVtVcPwr9JQtzX4BceY4qJAP7wIAAAAQZVhJZklJKgAIAAAAAAAAAAAAAACcPLkoAAAAJXRFWHRk YXRlOmNyZWF0ZQAyMDIxLTA3LTA3VDE4OjQ5OjM5KzAwOjAwPKRZbwAAACV0RVh0ZGF0ZTptb2Rp ZnkAMjAyMS0wNy0wN1QxODo0OTozOSswMDowME354dMAAAAASUVORK5CYII= X-Now-Playing: Tuxedomoon's _Live At The Palms (1978)_: "Cell Life" Date: Wed, 07 Jul 2021 20:58:29 +0200 In-Reply-To: <83zguydkyz.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 07 Jul 2021 21:42:28 +0300") Message-ID: <878s2i3q96.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Eli Zaretskii writes: > Even if it currently works, it's unsafe, IMO, to not have any > protection there. No one will remember that we rely on this not being > called early enough. Right. My reasoning was that it seemed unlikely to be a problem here, since the same function also (possibly) calls the Lisp functions userlock--ask-user-about-supersession-threat and ask-user-about-l [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49261 Cc: michael.albinus@gmx.de, ncaprisunfan@gmail.com, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: > Even if it currently works, it's unsafe, IMO, to not have any > protection there. No one will remember that we rely on this not being > called early enough. Right. My reasoning was that it seemed unlikely to be a problem here, since the same function also (possibly) calls the Lisp functions userlock--ask-user-about-supersession-threat and ask-user-about-lock. But those are only called in some cases, so we're calling out to Lisp more now than before, and that may indeed be a problem. I can add a check to whether the Lisp function is defined before calling (and then not do locking if it isn't) to be more defensive here? > My point is that this simplicity comes at a price. We've been > consistently moving code from C primitives to Lisp, and by doing that > significantly increase the consing during even the simplest editing > operations. All this consing adds up, with the result that Emacs > nowadays produces much more garbage, which then triggers frequent GC > cycles, which slow down Emacs. It's a small wonder we see so many > people out there raising the GC threshold to dangerous levels. > > So I'm asking whether the simplicity justifies the costs, here and > elsewhere. I agree with you 100% that it's important to take this into consideration when moving things from C to Lisp. In this particular case, I think the cost is justified, because this isn't a function that's called in a loop, and the other things it does (calling Fverify_visited_file_modtime and Ffile_exists_p, and actually creating the lock file) totally swamps any extra string consing, I think. (That is, it won't take measurably longer.) -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 07 15:03:22 2021 Received: (at 49261) by debbugs.gnu.org; 7 Jul 2021 19:03:22 +0000 Received: from localhost ([127.0.0.1]:53514 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1CpO-0007oI-Ao for submit@debbugs.gnu.org; Wed, 07 Jul 2021 15:03:22 -0400 Received: from quimby.gnus.org ([95.216.78.240]:54640) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1CpM-0007o5-QZ for 49261@debbugs.gnu.org; Wed, 07 Jul 2021 15:03:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=1+hiaiJ31/zlHNAsfRrnId31qcjz9aAEF00LJ1MMBWQ=; b=arV8krxcAh+SAcb8EGFuxX1ogX GJsVJppRt7jMzUJkEYSZBiG2mO/Zrpo+sfIHDItBYcZOZavqUVezNiGPDLMsmO9mRZ6vqgC4Elcjv K1TyyrzfDCLCGqaUxwia0fz6Z9S13Lov/03mvaLrp0RsL8JCRhUMg9rB9YIkKLaDkzd4=; Received: from cm-84.212.220.105.getinternet.no ([84.212.220.105] helo=elva) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m1CpE-0000rZ-GF; Wed, 07 Jul 2021 21:03:14 +0200 From: Lars Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: <87o8bn7bie.fsf@gnus.org> <87zgv6vuon.fsf@gmx.de> <837di9lwbm.fsf@gnu.org> <87a6n5vuu4.fsf@gnus.org> <8735sqnmei.fsf@gnus.org> <834kd6f1dw.fsf@gnu.org> <87h7h6m1jh.fsf@gnus.org> <83zguydkyz.fsf@gnu.org> <878s2i3q96.fsf@gnus.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAALVBMVEUOCgoxKx2jm5Cr opdgXFWlnVQqFRNbIyChJy+1ST5lWyu3rFnj4ZV/gUn///+MD1spAAAAAWJLR0QOb70wTwAAAAd0 SU1FB+UHBxMCIlyc+ncAAAFwSURBVDjLrdMxTsMwFABQG1W/UqcGQQdLLIgLgHoAEOEGMJAWKVkc lCkMkJaJiTonwN7aIQWl6sDQgURsdGNhRHAY3LSI2nE2/uLIL9//204QMsZmG6Et27aPdKgdSLT3 TvZN4FkeRSbAlgdGUINWAa4CMAFQF4GrAchX6ywswyL8+A5wCeQqfhxSbMiAngiRCkUr1GfcRaUM 2qINzorGVPCjqM+5AUgkBOchXJXgVgIbwWNpg9fZk+CRm2oApJt9voj4Xgc8eU/yc7makDt118D7 nif5uBdzuUclg3TnU0ceFhMDBYDk83SMoM84cxWY5G8jOV4+cBauA/7Ks8VY5wMVGp38uXjoR5EC Qb7MQMENVWpszzpLqOvwmlwUE2CBAmSWnA6XbbigtLtz5ox+7149xMRJV1epHXvgpM2/+18DPF0B 0j8fkg7NgKcVgIKPCqDEDNDEFTWaqz9AB6uFzBlq1Hb/D6pqbLTN83B8+AMKhnGeVlNLGAAAACV0 RVh0ZGF0ZTpjcmVhdGUAMjAyMS0wNy0wN1QxOTowMjozNCswMDowMMjcaV8AAAAldEVYdGRhdGU6 bW9kaWZ5ADIwMjEtMDctMDdUMTk6MDI6MzQrMDA6MDC5gdHjAAAAAElFTkSuQmCC X-Now-Playing: Hieroglyphics Being, Sarathy Korwar & Shabaka Hutchings's _Fabriclive 96 Mixed by Skream_: "Ashrams" Date: Wed, 07 Jul 2021 21:03:11 +0200 In-Reply-To: <878s2i3q96.fsf@gnus.org> (Lars Ingebrigtsen's message of "Wed, 07 Jul 2021 20:58:29 +0200") Message-ID: <874kd63q1c.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Lars Ingebrigtsen writes: > I can add a check to whether the Lisp function is defined before calling > (and then not do locking if it isn't) to be more defensive here? Ah, I didn't notice that lock_file starts like this: Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49261 Cc: michael.albinus@gmx.de, ncaprisunfan@gmail.com, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Lars Ingebrigtsen writes: > I can add a check to whether the Lisp function is defined before calling > (and then not do locking if it isn't) to be more defensive here? Ah, I didn't notice that lock_file starts like this: /* Don't do locking while dumping Emacs. Uncompressing wtmp files uses call-process, which does not work in an uninitialized Emacs. */ if (will_dump_p ()) return; So I think we're basically safe... -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 07 15:20:49 2021 Received: (at 49261) by debbugs.gnu.org; 7 Jul 2021 19:20:49 +0000 Received: from localhost ([127.0.0.1]:53533 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1D6H-00020d-Dg for submit@debbugs.gnu.org; Wed, 07 Jul 2021 15:20:49 -0400 Received: from eggs.gnu.org ([209.51.188.92]:44688) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1D6E-00020N-Ha for 49261@debbugs.gnu.org; Wed, 07 Jul 2021 15:20:48 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:42836) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m1D68-0005cY-Q9; Wed, 07 Jul 2021 15:20:41 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:1709 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m1D68-0001q2-C2; Wed, 07 Jul 2021 15:20:40 -0400 Date: Wed, 07 Jul 2021 22:20:50 +0300 Message-Id: <83v95mdj71.fsf@gnu.org> From: Eli Zaretskii To: Lars Ingebrigtsen In-Reply-To: <878s2i3q96.fsf@gnus.org> (message from Lars Ingebrigtsen on Wed, 07 Jul 2021 20:58:29 +0200) Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: <87o8bn7bie.fsf@gnus.org> <87zgv6vuon.fsf@gmx.de> <837di9lwbm.fsf@gnu.org> <87a6n5vuu4.fsf@gnus.org> <8735sqnmei.fsf@gnus.org> <834kd6f1dw.fsf@gnu.org> <87h7h6m1jh.fsf@gnus.org> <83zguydkyz.fsf@gnu.org> <878s2i3q96.fsf@gnus.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49261 Cc: michael.albinus@gmx.de, ncaprisunfan@gmail.com, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Lars Ingebrigtsen > Cc: michael.albinus@gmx.de, ncaprisunfan@gmail.com, 49261@debbugs.gnu.org > Date: Wed, 07 Jul 2021 20:58:29 +0200 > > Eli Zaretskii writes: > > > Even if it currently works, it's unsafe, IMO, to not have any > > protection there. No one will remember that we rely on this not being > > called early enough. > > Right. My reasoning was that it seemed unlikely to be a problem here, > since the same function also (possibly) calls the Lisp functions > userlock--ask-user-about-supersession-threat and ask-user-about-lock. > But those are only called in some cases, so we're calling out to Lisp > more now than before, and that may indeed be a problem. Right, the call to userlock--ask-user-about-supersession-threat is under some conditions that are rarely satisfied. > I can add a check to whether the Lisp function is defined before calling > (and then not do locking if it isn't) to be more defensive here? I guess so. > > So I'm asking whether the simplicity justifies the costs, here and > > elsewhere. > > I agree with you 100% that it's important to take this into > consideration when moving things from C to Lisp. In this particular > case, I think the cost is justified, because this isn't a function > that's called in a loop, and the other things it does (calling > Fverify_visited_file_modtime and Ffile_exists_p, and actually creating > the lock file) totally swamps any extra string consing, I think. (That > is, it won't take measurably longer.) If it triggers GC, it _will_ take significantly longer. But I won't argue more about this, it's a lost battle anyway with current Emacs development trends. From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 07 15:22:44 2021 Received: (at 49261) by debbugs.gnu.org; 7 Jul 2021 19:22:44 +0000 Received: from localhost ([127.0.0.1]:53537 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1D87-00023n-RS for submit@debbugs.gnu.org; Wed, 07 Jul 2021 15:22:44 -0400 Received: from quimby.gnus.org ([95.216.78.240]:54866) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1D85-00023W-Vn for 49261@debbugs.gnu.org; Wed, 07 Jul 2021 15:22:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=GheLZLGa6WJgTbb9kaIhczTjg27ZdGMMMu0RWzQtPEs=; b=sZFwZBPJ6WjY9tL2Qs2GnPokiK 3zBwqZ1hwlHioQsxHqgr+xoQCMN9SpzMRDUvAjUxF+XwSzlTvORUYZZoU7lPNj6VcU1N4g/2I43rh Pd7UapOgw0hI8JHGpR0JWYNKU/MpDndQZCwBIbZxR4Qes88414PFtowqQNEi6ekLzXPc=; Received: from cm-84.212.220.105.getinternet.no ([84.212.220.105] helo=elva) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m1D7w-00016y-Op; Wed, 07 Jul 2021 21:22:35 +0200 From: Lars Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: <87o8bn7bie.fsf@gnus.org> <87zgv6vuon.fsf@gmx.de> <837di9lwbm.fsf@gnu.org> <87a6n5vuu4.fsf@gnus.org> <8735sqnmei.fsf@gnus.org> <834kd6f1dw.fsf@gnu.org> <87h7h6m1jh.fsf@gnus.org> <83wnq2dkld.fsf@gnu.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAElBMVEUfHCMsKS5XTkvh yrOphmj////ge5JrAAAAAWJLR0QF+G/pxwAAAAd0SU1FB+UHBxMHCY1X93IAAAG1SURBVDjLbZOL kcMgDESR5woAnQswMg0kUEAM9F/Trfg49iXMJHF4rD5rYchhmb6WiJWdIWdJ/8/9Dl7B0PvsBRz1 E1CJMeWnmdHtqahIUV/GfYRKpda6kXzN8UIK/z/HDuAReSpGEnIrkkt/1C+rhLRIRvLDzN6IbGtU aympbvbSNDyw1EHGL+T6mY0qWPPowRnXTmJZN5ftoch9LNuB+QbE3CQsIr4BHknH+lXbZ6j/oPvE 90gDWENyEzhW1zXVDYiUKiEEjzbJX0BJJSYY/4DQyiV5wW5Clodd68Y3RYhxL6h3Tdu1qpJag+jw J72uXsXEeFFPPC31uIbC3gTlgMJeQUhwxFEDZ3PtsE6Os+Ggd7kc82l7A0SngidYD3pXpaEmWW+K kh37/vwDwN7TCeZaADAdy9Y7f96B2nCCEWrJZNQdycOrU1GdgSBI9Q34N7CqyKGKFy5xABRdvWmC LFn2OAAjcM2qCFlYWEfK65uvGZ5IUwg6W/usrbifwKtvVenA7B14qVDg4PCWWSfEqyeIrLPUriFB EeJTgSbRueZx0yRnjNWIOm4C3hRpyaHu0xzd/wOUnGSlZndpMwAAACV0RVh0ZGF0ZTpjcmVhdGUA MjAyMS0wNy0wN1QxOTowNzowOSswMDowMMGtxDgAAAAldEVYdGRhdGU6bW9kaWZ5ADIwMjEtMDct MDdUMTk6MDc6MDkrMDA6MDCw8HyEAAAAAElFTkSuQmCC X-Now-Playing: Bogdan Raczynski's _Rave 'Till You Cry_: "329 15h" Date: Wed, 07 Jul 2021 21:22:32 +0200 In-Reply-To: <83wnq2dkld.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 07 Jul 2021 21:50:38 +0300") Message-ID: <87tul62akn.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Eli Zaretskii writes: > Btw, we could avoid having 2 places that produces the default > ".#"+FILENAME lock file name by exposing to Lisp a C primitive which > does that. So that problem can easily be solved. Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49261 Cc: michael.albinus@gmx.de, ncaprisunfan@gmail.com, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: > Btw, we could avoid having 2 places that produces the default > ".#"+FILENAME lock file name by exposing to Lisp a C primitive which > does that. So that problem can easily be solved. Yes, that's definitely true. We could even make it more general and then use it, for instance, in the auto-save code path, too. That is, with a signature of, say... (file-name-surround file-name prefix &optional suffix) (file-name-surround "/tmp/foo.txt" "#" "#") => "/tmp/#foo.txt#" It'd be less consing than the current (concat (file-name-directory filename) "#" (file-name-nondirectory filename) "#") code we have. A better name would be nice, though. :-) -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 07 15:40:48 2021 Received: (at 49261) by debbugs.gnu.org; 7 Jul 2021 19:40:48 +0000 Received: from localhost ([127.0.0.1]:53564 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1DPb-0002Y7-V8 for submit@debbugs.gnu.org; Wed, 07 Jul 2021 15:40:48 -0400 Received: from quimby.gnus.org ([95.216.78.240]:54972) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1DPZ-0002Xu-Ga for 49261@debbugs.gnu.org; Wed, 07 Jul 2021 15:40:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=KzZhWJkIbbU7QIwIBDvi3vOda+ZD/E132Ed8CzBLfJU=; b=vWUDX0dkk98yNaaGoSo5vspz4f jQLWRlinqJ6CkiO1vVKupRjcbLmbyxJaCcuM/RzZSVxSNHfYHGt34mJQDj1sDthS/xWbEUrhSjkrW BlD+nCSoTaXBN9vf2C15gEY02gJrFfjhx6M1kwGNTmZdt9+vGW6pYJfm9MTks1r4BwzM=; Received: from cm-84.212.220.105.getinternet.no ([84.212.220.105] helo=elva) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m1DPQ-0001Hm-2A; Wed, 07 Jul 2021 21:40:38 +0200 From: Lars Ingebrigtsen To: Michael Albinus Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: <87o8bn7bie.fsf@gnus.org> <87zgv6vuon.fsf@gmx.de> <837di9lwbm.fsf@gnu.org> <87a6n5vuu4.fsf@gnus.org> <8735sqnmei.fsf@gnus.org> <87zguyf4ht.fsf@gmx.de> <87pmvum54p.fsf@gnus.org> <87v95mf2lj.fsf@gmx.de> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAElBMVEUfHCMsKS5XTkvh yrOphmj////ge5JrAAAAAWJLR0QF+G/pxwAAAAd0SU1FB+UHBxMHCY1X93IAAAG1SURBVDjLbZOL kcMgDESR5woAnQswMg0kUEAM9F/Trfg49iXMJHF4rD5rYchhmb6WiJWdIWdJ/8/9Dl7B0PvsBRz1 E1CJMeWnmdHtqahIUV/GfYRKpda6kXzN8UIK/z/HDuAReSpGEnIrkkt/1C+rhLRIRvLDzN6IbGtU aympbvbSNDyw1EHGL+T6mY0qWPPowRnXTmJZN5ftoch9LNuB+QbE3CQsIr4BHknH+lXbZ6j/oPvE 90gDWENyEzhW1zXVDYiUKiEEjzbJX0BJJSYY/4DQyiV5wW5Clodd68Y3RYhxL6h3Tdu1qpJag+jw J72uXsXEeFFPPC31uIbC3gTlgMJeQUhwxFEDZ3PtsE6Os+Ggd7kc82l7A0SngidYD3pXpaEmWW+K kh37/vwDwN7TCeZaADAdy9Y7f96B2nCCEWrJZNQdycOrU1GdgSBI9Q34N7CqyKGKFy5xABRdvWmC LFn2OAAjcM2qCFlYWEfK65uvGZ5IUwg6W/usrbifwKtvVenA7B14qVDg4PCWWSfEqyeIrLPUriFB EeJTgSbRueZx0yRnjNWIOm4C3hRpyaHu0xzd/wOUnGSlZndpMwAAACV0RVh0ZGF0ZTpjcmVhdGUA MjAyMS0wNy0wN1QxOTowNzowOSswMDowMMGtxDgAAAAldEVYdGRhdGU6bW9kaWZ5ADIwMjEtMDct MDdUMTk6MDc6MDkrMDA6MDCw8HyEAAAAAElFTkSuQmCC X-Now-Playing: Bogdan Raczynski's _Rave 'Till You Cry_: "356 34h12" Date: Wed, 07 Jul 2021 21:40:34 +0200 In-Reply-To: <87v95mf2lj.fsf@gmx.de> (Michael Albinus's message of "Wed, 07 Jul 2021 19:36:24 +0200") Message-ID: <87pmvt3ob1.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: I've now pushed this change. Michael, there were some conflicts in filelock.c with your changes from earlier this evening -- can you check whether I resolved them correctly? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49261 Cc: Eli Zaretskii , ncaprisunfan@gmail.com, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) I've now pushed this change. Michael, there were some conflicts in filelock.c with your changes from earlier this evening -- can you check whether I resolved them correctly? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 07 16:03:41 2021 Received: (at 49261) by debbugs.gnu.org; 7 Jul 2021 20:03:41 +0000 Received: from localhost ([127.0.0.1]:53580 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1Dll-00036x-02 for submit@debbugs.gnu.org; Wed, 07 Jul 2021 16:03:41 -0400 Received: from mout.gmx.net ([212.227.15.18]:36975) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1Dlh-00036i-Jg for 49261@debbugs.gnu.org; Wed, 07 Jul 2021 16:03:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1625688210; bh=jY4GdjCb5r7+krkiyMMT5QUQqnElR8J591Uw3vTMwKU=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=afDkWD2FBMSV+YpFABOZb2Uf90QtaiEhJqg6JKOYZsRzwB5wap59yYr7erTwsFIDr YLM/BHJLQ0UV0f1dQnhqDNqiqbdBNzxmqjLhCReqFXEYoBOGhyeinkWK29+nZmKi1w 1QEs0CkV3KzJdLKhWGLYMcFoRc+BlkNej6pTerHo= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from gandalf.gmx.de ([212.91.249.146]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MMobO-1liazG1gRQ-00IioY; Wed, 07 Jul 2021 22:03:30 +0200 From: Michael Albinus To: Lars Ingebrigtsen Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: <87o8bn7bie.fsf@gnus.org> <87zgv6vuon.fsf@gmx.de> <837di9lwbm.fsf@gnu.org> <87a6n5vuu4.fsf@gnus.org> <8735sqnmei.fsf@gnus.org> <87zguyf4ht.fsf@gmx.de> <87pmvum54p.fsf@gnus.org> <87v95mf2lj.fsf@gmx.de> <87pmvt3ob1.fsf@gnus.org> Date: Wed, 07 Jul 2021 22:03:28 +0200 In-Reply-To: <87pmvt3ob1.fsf@gnus.org> (Lars Ingebrigtsen's message of "Wed, 07 Jul 2021 21:40:34 +0200") Message-ID: <87fswpgacv.fsf@gmx.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:KlzuxJAijb+QCokRyPFKiWRSmm6gNsdp+k6sz+biGuVWX4vd0B3 ZgkNFxG6BcwV+UFj/1I6660brVrp1aaegrtsx1jVnkP1OuyKmGyBVfSMv0hNa+BD9VoQp85 wqzAsQjvA4tFWrz2MmtJJehcg5ZnGbXf+6hMANZvcJrtfeIJ0q2bulCBE8DWBtWUYrhjByz EyjIyDLg7JsWlmFQ/jh3Q== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:iqmLWRhHhuU=:yaL0GXHZC8NPGtp/xCkDoQ z60jt6UMlsJLLS/CRunfUsNu5knZ92nSbNGstvcgTOl2bjPbd8xsOxmfGuKcCJWYeWckDBr3L Qi5DDDZmEIRx00f5UEz4OoaFyZ+3s9xlxkUJPlU808kiN0Xk5Id6Nh/CH80fSpSQNRA8GigxA KOl49cK5nvsZvBUixFAbV0yb7SgGt/X049121EW20Gs/vNHXu95cwd3OR/xk1e7Dxpbgwgr4Y PtebJLNgr023SopHUnW5Ep+yb9ockakYBXqKvQzwvnmniZxvNXyakb3BHhUMnygK5V9CvlQsW OiPC0cwSb1I2b6O+RjdXbVT0PxICJLPaMxVufIagg0n1/wtmC6fWXubjy9vl0HdRlJr/T1L+5 XWKwkZU2AFsOGnBYtPRCyasIfry48MLcKZI7RA4rNwY+mT1nH+4LYF7FqXlGvKDbhUrk8FGNf BTm9zCnMqy47WampFPS0zNiBVomz03VIVQbAx6NVm5Grv871RPRKECKXDzOpFKcG3DGN8us4l SNzD8BT4nvU2k0u8lpOvRjz6VPUEuPCNyPixc+ixgvgKbBsdoBCAKuEhch/OHlqdyhL8N0Fzz y5uBoJn8quf3UkzLy9Gs00TjK9bOYJyFbQO7dUyG7sIH7YR7yRL6r8JeUU+559kNCwNCBXd2f SfL3H0BfGqC3b17X8FWjmznQVh4E/DkvaQYg0peIOaUiVVBAJfcYKawaGYzh25pWfoyKfT2FX BMiZ2x+cuKZSvDfzJpP+CvetqicMm5CYlW36edB6mohgyojCOyWpt9g5ckk6+6oTkzCf/QdWq fIea225viRx2CyJmxs4z2YEK9DTSDL6hNrcGHkiUgv/KnuNSxH4EqBZUpiR28xgQeykK2DWXy IhmODviL+s8TnAHAxra3/W5A9ErJq3YCuMMUiObw6BrvvMDrm3+d4lDu64+22ChSth7cW3dUS z+0oW2Aieo2sOI4JTKTQqq9iD8jAniAUQN5vFL0k2GpufxmuRsUvrQ0hoYEiRAzFHK6cMhNSs sBdHd87BqKcIIqGKLSyr6DKmmRc0d01CuPL6omYn8bbfnW+/3D6kpsmSmKptSMP7NCGTk4tC0 Drd14olEf9ZIo3VIE+NMjl4xT/PhaUvt6+7benwL2eohyHQnTwp4GRNBQ== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 49261 Cc: Eli Zaretskii , ncaprisunfan@gmail.com, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Lars Ingebrigtsen writes: Hi Lars, > I've now pushed this change. Michael, there were some conflicts in > filelock.c with your changes from earlier this evening -- can you check > whether I resolved them correctly? I see no regressions. Three test cases still fail (file-notify-test03-events-remote, shadow-test08-shadow-todo, shadow-test09-shadow-copy-files), but the most important one, tramp-test39-lock-file, still succeeds. I will check tomorrow why these test cases fail, and how to integrate the new lock-file-name-transforms into Tramp. Best regards, Michael. From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 07 16:05:30 2021 Received: (at 49261) by debbugs.gnu.org; 7 Jul 2021 20:05:30 +0000 Received: from localhost ([127.0.0.1]:53602 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1DnW-0003Ae-Gu for submit@debbugs.gnu.org; Wed, 07 Jul 2021 16:05:30 -0400 Received: from eggs.gnu.org ([209.51.188.92]:54262) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1DnU-0003AQ-TV for 49261@debbugs.gnu.org; Wed, 07 Jul 2021 16:05:29 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:44432) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m1DnP-0003p3-FY; Wed, 07 Jul 2021 16:05:23 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:4455 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m1DnP-0008SL-0x; Wed, 07 Jul 2021 16:05:23 -0400 Date: Wed, 07 Jul 2021 23:05:33 +0300 Message-Id: <83r1g9evoy.fsf@gnu.org> From: Eli Zaretskii To: Lars Ingebrigtsen In-Reply-To: <87pmvt3ob1.fsf@gnus.org> (message from Lars Ingebrigtsen on Wed, 07 Jul 2021 21:40:34 +0200) Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: <87o8bn7bie.fsf@gnus.org> <87zgv6vuon.fsf@gmx.de> <837di9lwbm.fsf@gnu.org> <87a6n5vuu4.fsf@gnus.org> <8735sqnmei.fsf@gnus.org> <87zguyf4ht.fsf@gmx.de> <87pmvum54p.fsf@gnus.org> <87v95mf2lj.fsf@gmx.de> <87pmvt3ob1.fsf@gnus.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49261 Cc: michael.albinus@gmx.de, ncaprisunfan@gmail.com, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Lars Ingebrigtsen > Cc: Eli Zaretskii , ncaprisunfan@gmail.com, > 49261@debbugs.gnu.org > Date: Wed, 07 Jul 2021 21:40:34 +0200 > > I've now pushed this change. The build seems to be broken: Finding pointers to doc strings...done SCRAPE ./calendar Debugger entered--Lisp error: (void-function make-lock-file-name) make-lock-file-name("/srv/data/home/e/eliz/git/emacs/trunk/lisp/calenda...") insert-file-contents("/srv/data/home/e/eliz/git/emacs/trunk/lisp/calenda..." t) find-file-noselect-1(# "/srv/data/home/e/eliz/git/emacs/trunk/lisp/calenda..." nil nil "/srv/data/home/e/eliz/git/emacs/trunk/lisp/calenda..." (51128996 64768)) find-file-noselect("/srv/data/home/e/eliz/git/emacs/trunk/lisp/calenda...") autoload-find-generated-file("/srv/data/home/e/eliz/git/emacs/trunk/lisp/calenda...") make-directory-autoloads(("./calendar") "/srv/data/home/e/eliz/git/emacs/trunk/lisp/calenda...") batch-update-autoloads() command-line-1(("-l" "autoload" "--eval" "(setq generate-autoload-cookie \";;;###cal-autoload..." "--eval" "(setq generated-autoload-file (expand-file-name (u..." "-f" "batch-update-autoloads" "./calendar")) command-line() normal-top-level() eval((normal-top-level) t) load("loadup.el") make[2]: *** [calendar/cal-loaddefs.el] Error 255 From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 07 16:10:06 2021 Received: (at 49261) by debbugs.gnu.org; 7 Jul 2021 20:10:06 +0000 Received: from localhost ([127.0.0.1]:53608 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1Dry-0003Hh-4S for submit@debbugs.gnu.org; Wed, 07 Jul 2021 16:10:06 -0400 Received: from quimby.gnus.org ([95.216.78.240]:55178) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1Dru-0003H7-Vg for 49261@debbugs.gnu.org; Wed, 07 Jul 2021 16:10:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=8sxq96HyMig4mboLDIvyMWp1TsvdJlkj1U9PReY5gfU=; b=bxAo8lIjbhySc9uNy5iuE1Ebhs owxNDh+o4+zuZk/JeXPWVwZub6iZoO/xTnp7VdFrke8XzemMvqRswAWXb+E28qnoHyBYWf8/YM1or 7I9hC/UPsVLgnAYw3Ox/YKJ4VZ6AUmVzzS+UgPOQJmJkAtUSkjHjXiU4J8YROvdVo8Rw=; Received: from cm-84.212.220.105.getinternet.no ([84.212.220.105] helo=elva) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m1Drl-0001Yx-Nq; Wed, 07 Jul 2021 22:09:56 +0200 From: Lars Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: <87o8bn7bie.fsf@gnus.org> <87zgv6vuon.fsf@gmx.de> <837di9lwbm.fsf@gnu.org> <87a6n5vuu4.fsf@gnus.org> <8735sqnmei.fsf@gnus.org> <87zguyf4ht.fsf@gmx.de> <87pmvum54p.fsf@gnus.org> <87v95mf2lj.fsf@gmx.de> <87pmvt3ob1.fsf@gnus.org> <83r1g9evoy.fsf@gnu.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAGFBMVEVDOjszKyxgVlSh loyIf3js4sciGx7///9364cjAAAAAWJLR0QHFmGI6wAAAAd0SU1FB+UHBxQJDGbxOPYAAAGzSURB VDjLlZTBcpwwDIZlspOzxWR8BkFzTjHknF3oAyTE95KD3/8RKllmYTe0M9VhWfTxS7KQAAAkNoPY eLUOxcAYtIdAfooEHjL4uQFM4CmDWoFVCQM7Td73U292wArAdhJ7w5xcY8mlbFN9Jj0LSgq+tUb8 VFRUJJAUJTuACiVE16rSUXbGUYCUtJdp9P5CNErFFQAELVuO3Rknj6zgPYOxcyo+MWASPhcF/SNm a7ypCgiz3ozn1Y9f3lgGgyafcLPGIME8pG62LztQGmRFSHW1Nd5YKeCVD9iYW4ACpOWE38G8/AV8 yKU6UsilPgDhH8D+l4JqFhyA9yjVHlT1ym2xQN/P8UI6Ond+jgFrQ++auP65y05XcJvE7sAuFr+n HdgKtrWlCq7aTSLVZwC27c0Wi4c0zzRQ489X/5dUCDFlszxwq9+dEvDyaqnk2T0vWXCpte08o2Ur Q/6YyEKUQIUSLIHexLjY9kJbDix1+3k/Jt2bdaNcCWM9+l4a42KMoohJ45bhefB9JWlcYVzkQ2r7 fod6mH2XwI8wdzIMsknRkfsVMjj5EBKIavyV0S1x0dIfslZ/l3i9fXoAAAAldEVYdGRhdGU6Y3Jl YXRlADIwMjEtMDctMDdUMjA6MDk6MTIrMDA6MDDqPY/cAAAAJXRFWHRkYXRlOm1vZGlmeQAyMDIx LTA3LTA3VDIwOjA5OjEyKzAwOjAwm2A3YAAAAABJRU5ErkJggg== X-Now-Playing: Vanishing Twin's _The Age Of Immunology_: "Cryonic Suspension May Save Your Life" Date: Wed, 07 Jul 2021 22:09:53 +0200 In-Reply-To: <83r1g9evoy.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 07 Jul 2021 23:05:33 +0300") Message-ID: <87h7h53my6.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Eli Zaretskii writes: > The build seems to be broken: > > Finding pointers to doc strings...done > SCRAPE ./calendar > Debugger entered--Lisp error: (void-function make-lock-file-name) > make-lock-file-name("/srv/data/home [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49261 Cc: michael.albinus@gmx.de, ncaprisunfan@gmail.com, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: > The build seems to be broken: > > Finding pointers to doc strings...done > SCRAPE ./calendar > Debugger entered--Lisp error: (void-function make-lock-file-name) > make-lock-file-name("/srv/data/home/e/eliz/git/emacs/trunk/lisp/calenda...") > insert-file-contents("/srv/data/home/e/eliz/git/emacs/trunk/lisp/calenda..." t) And I'm seeing a segfault, too, ending with: Loading /home/larsi/src/emacs/trunk/lisp/cus-face.el (source)... Loading /home/larsi/src/emacs/trunk/lisp/faces.el (source)... Fatal error 11: Segmentation fault I'm investigating. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 07 16:10:35 2021 Received: (at 49261) by debbugs.gnu.org; 7 Jul 2021 20:10:35 +0000 Received: from localhost ([127.0.0.1]:53611 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1DsR-0003IZ-D5 for submit@debbugs.gnu.org; Wed, 07 Jul 2021 16:10:35 -0400 Received: from eggs.gnu.org ([209.51.188.92]:55184) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1DsQ-0003IN-7I for 49261@debbugs.gnu.org; Wed, 07 Jul 2021 16:10:34 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:44532) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m1DsK-0004R5-VV; Wed, 07 Jul 2021 16:10:28 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:4766 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m1DsK-0000U4-C8; Wed, 07 Jul 2021 16:10:28 -0400 Date: Wed, 07 Jul 2021 23:10:39 +0300 Message-Id: <83pmvtevgg.fsf@gnu.org> From: Eli Zaretskii To: larsi@gnus.org In-Reply-To: <83r1g9evoy.fsf@gnu.org> (message from Eli Zaretskii on Wed, 07 Jul 2021 23:05:33 +0300) Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: <87o8bn7bie.fsf@gnus.org> <87zgv6vuon.fsf@gmx.de> <837di9lwbm.fsf@gnu.org> <87a6n5vuu4.fsf@gnus.org> <8735sqnmei.fsf@gnus.org> <87zguyf4ht.fsf@gmx.de> <87pmvum54p.fsf@gnus.org> <87v95mf2lj.fsf@gmx.de> <87pmvt3ob1.fsf@gnus.org> <83r1g9evoy.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49261 Cc: michael.albinus@gmx.de, ncaprisunfan@gmail.com, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Wed, 07 Jul 2021 23:05:33 +0300 > From: Eli Zaretskii > Cc: michael.albinus@gmx.de, ncaprisunfan@gmail.com, 49261@debbugs.gnu.org > > > From: Lars Ingebrigtsen > > Cc: Eli Zaretskii , ncaprisunfan@gmail.com, > > 49261@debbugs.gnu.org > > Date: Wed, 07 Jul 2021 21:40:34 +0200 > > > > I've now pushed this change. > > The build seems to be broken: Sorry, that was my fault. From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 07 16:15:27 2021 Received: (at 49261) by debbugs.gnu.org; 7 Jul 2021 20:15:27 +0000 Received: from localhost ([127.0.0.1]:53616 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1Dx9-0003Q2-0k for submit@debbugs.gnu.org; Wed, 07 Jul 2021 16:15:27 -0400 Received: from eggs.gnu.org ([209.51.188.92]:56086) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1Dx4-0003Po-4x for 49261@debbugs.gnu.org; Wed, 07 Jul 2021 16:15:25 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:45052) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m1Dwy-0005AP-VR; Wed, 07 Jul 2021 16:15:16 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:1087 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m1Dwr-0001LM-Ad; Wed, 07 Jul 2021 16:15:16 -0400 Date: Wed, 07 Jul 2021 23:15:21 +0300 Message-Id: <83mtqxev8m.fsf@gnu.org> From: Eli Zaretskii To: Lars Ingebrigtsen In-Reply-To: <87h7h53my6.fsf@gnus.org> (message from Lars Ingebrigtsen on Wed, 07 Jul 2021 22:09:53 +0200) Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: <87o8bn7bie.fsf@gnus.org> <87zgv6vuon.fsf@gmx.de> <837di9lwbm.fsf@gnu.org> <87a6n5vuu4.fsf@gnus.org> <8735sqnmei.fsf@gnus.org> <87zguyf4ht.fsf@gmx.de> <87pmvum54p.fsf@gnus.org> <87v95mf2lj.fsf@gmx.de> <87pmvt3ob1.fsf@gnus.org> <83r1g9evoy.fsf@gnu.org> <87h7h53my6.fsf@gnus.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49261 Cc: michael.albinus@gmx.de, ncaprisunfan@gmail.com, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Lars Ingebrigtsen > Cc: michael.albinus@gmx.de, ncaprisunfan@gmail.com, 49261@debbugs.gnu.org > Date: Wed, 07 Jul 2021 22:09:53 +0200 > > Eli Zaretskii writes: > > > The build seems to be broken: > > > > Finding pointers to doc strings...done > > SCRAPE ./calendar > > Debugger entered--Lisp error: (void-function make-lock-file-name) > > make-lock-file-name("/srv/data/home/e/eliz/git/emacs/trunk/lisp/calenda...") > > insert-file-contents("/srv/data/home/e/eliz/git/emacs/trunk/lisp/calenda..." t) > > And I'm seeing a segfault, too, ending with: > > Loading /home/larsi/src/emacs/trunk/lisp/cus-face.el (source)... > Loading /home/larsi/src/emacs/trunk/lisp/faces.el (source)... > Fatal error 11: Segmentation fault My stupid typo, should be fixed now. From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 07 16:19:08 2021 Received: (at 49261) by debbugs.gnu.org; 7 Jul 2021 20:19:08 +0000 Received: from localhost ([127.0.0.1]:53621 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1E0i-0003Vk-IG for submit@debbugs.gnu.org; Wed, 07 Jul 2021 16:19:08 -0400 Received: from quimby.gnus.org ([95.216.78.240]:55308) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1E0g-0003VE-8O for 49261@debbugs.gnu.org; Wed, 07 Jul 2021 16:19:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=WyIdb+3hc8tWSOQBW0NBizAQO3rOfCt8EWjv1diFgHY=; b=QzeoRl52Zix7H6EHtkqQkv+YQy lSAamsGB0ZaJeS6HMjc+2wOSkugSkNx/6SQmppVQP4OIq5qah9YK1pEJklu8XquE6YEAUY3UKHRMp klng53dMJcS2tHHgkCMLRYHh/nvp/mjow8QxKNu0xO1Q/pE+DFlXHgTmgwb9Fpb4gn8o=; Received: from cm-84.212.220.105.getinternet.no ([84.212.220.105] helo=elva) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m1E0W-0001cH-Fa; Wed, 07 Jul 2021 22:18:59 +0200 From: Lars Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: <87o8bn7bie.fsf@gnus.org> <87zgv6vuon.fsf@gmx.de> <837di9lwbm.fsf@gnu.org> <87a6n5vuu4.fsf@gnus.org> <8735sqnmei.fsf@gnus.org> <87zguyf4ht.fsf@gmx.de> <87pmvum54p.fsf@gnus.org> <87v95mf2lj.fsf@gmx.de> <87pmvt3ob1.fsf@gnus.org> <83r1g9evoy.fsf@gnu.org> <83pmvtevgg.fsf@gnu.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAGFBMVEVDOjszKyxgVlSh loyIf3js4sciGx7///9364cjAAAAAWJLR0QHFmGI6wAAAAd0SU1FB+UHBxQJDGbxOPYAAAGzSURB VDjLlZTBcpwwDIZlspOzxWR8BkFzTjHknF3oAyTE95KD3/8RKllmYTe0M9VhWfTxS7KQAAAkNoPY eLUOxcAYtIdAfooEHjL4uQFM4CmDWoFVCQM7Td73U292wArAdhJ7w5xcY8mlbFN9Jj0LSgq+tUb8 VFRUJJAUJTuACiVE16rSUXbGUYCUtJdp9P5CNErFFQAELVuO3Rknj6zgPYOxcyo+MWASPhcF/SNm a7ypCgiz3ozn1Y9f3lgGgyafcLPGIME8pG62LztQGmRFSHW1Nd5YKeCVD9iYW4ACpOWE38G8/AV8 yKU6UsilPgDhH8D+l4JqFhyA9yjVHlT1ym2xQN/P8UI6Ond+jgFrQ++auP65y05XcJvE7sAuFr+n HdgKtrWlCq7aTSLVZwC27c0Wi4c0zzRQ489X/5dUCDFlszxwq9+dEvDyaqnk2T0vWXCpte08o2Ur Q/6YyEKUQIUSLIHexLjY9kJbDix1+3k/Jt2bdaNcCWM9+l4a42KMoohJ45bhefB9JWlcYVzkQ2r7 fod6mH2XwI8wdzIMsknRkfsVMjj5EBKIavyV0S1x0dIfslZ/l3i9fXoAAAAldEVYdGRhdGU6Y3Jl YXRlADIwMjEtMDctMDdUMjA6MDk6MTIrMDA6MDDqPY/cAAAAJXRFWHRkYXRlOm1vZGlmeQAyMDIx LTA3LTA3VDIwOjA5OjEyKzAwOjAwm2A3YAAAAABJRU5ErkJggg== X-Now-Playing: Vanishing Twin's _The Age Of Immunology_: "You Are Not An Island" Date: Wed, 07 Jul 2021 22:18:55 +0200 In-Reply-To: <83pmvtevgg.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 07 Jul 2021 23:10:39 +0300") Message-ID: <87czrt3mj4.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Eli Zaretskii writes: >> The build seems to be broken: > > Sorry, that was my fault. You were right that we needed to make the call-out to Lisp more robust, so I pushed a change that checks whether the function is defined before calling it. Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49261 Cc: michael.albinus@gmx.de, ncaprisunfan@gmail.com, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: >> The build seems to be broken: > > Sorry, that was my fault. You were right that we needed to make the call-out to Lisp more robust, so I pushed a change that checks whether the function is defined before calling it. After your faces.el fix and that additional check, Emacs now builds for me again, both incremental and bootstrap. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 07 16:29:46 2021 Received: (at 49261) by debbugs.gnu.org; 7 Jul 2021 20:29:46 +0000 Received: from localhost ([127.0.0.1]:53625 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1EB0-0003ku-Iy for submit@debbugs.gnu.org; Wed, 07 Jul 2021 16:29:46 -0400 Received: from quimby.gnus.org ([95.216.78.240]:55358) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1EAy-0003kh-NB for 49261@debbugs.gnu.org; Wed, 07 Jul 2021 16:29:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=sPpYZAvZXNpkCG/FllP/fkB0EMIKiOTWtUF/lPp0Abc=; b=iT1W4gi5eeApK21FTX8l6LJ/BO oQXs+KgPxgtDN7hDjIQHdPUl/SEyQylz4LXtU4HUMYgPnGS2OHirG5JoQJnXkylPUcZBNLtSMg9pk u0iDedwFwK41IspwF9eDfLOzHjLsXjopiEh1lBw0y0pfiEAsfJaFCW+/L5mEJIezJGVo=; Received: from cm-84.212.220.105.getinternet.no ([84.212.220.105] helo=elva) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m1EAp-0001iP-32; Wed, 07 Jul 2021 22:29:37 +0200 From: Lars Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: <87o8bn7bie.fsf@gnus.org> <87zgv6vuon.fsf@gmx.de> <837di9lwbm.fsf@gnu.org> <87a6n5vuu4.fsf@gnus.org> <8735sqnmei.fsf@gnus.org> <87zguyf4ht.fsf@gmx.de> <87pmvum54p.fsf@gnus.org> <87v95mf2lj.fsf@gmx.de> <87pmvt3ob1.fsf@gnus.org> <83r1g9evoy.fsf@gnu.org> <83pmvtevgg.fsf@gnu.org> <87czrt3mj4.fsf@gnus.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAGFBMVEVDOjszKyxgVlSh loyIf3js4sciGx7///9364cjAAAAAWJLR0QHFmGI6wAAAAd0SU1FB+UHBxQJDGbxOPYAAAGzSURB VDjLlZTBcpwwDIZlspOzxWR8BkFzTjHknF3oAyTE95KD3/8RKllmYTe0M9VhWfTxS7KQAAAkNoPY eLUOxcAYtIdAfooEHjL4uQFM4CmDWoFVCQM7Td73U292wArAdhJ7w5xcY8mlbFN9Jj0LSgq+tUb8 VFRUJJAUJTuACiVE16rSUXbGUYCUtJdp9P5CNErFFQAELVuO3Rknj6zgPYOxcyo+MWASPhcF/SNm a7ypCgiz3ozn1Y9f3lgGgyafcLPGIME8pG62LztQGmRFSHW1Nd5YKeCVD9iYW4ACpOWE38G8/AV8 yKU6UsilPgDhH8D+l4JqFhyA9yjVHlT1ym2xQN/P8UI6Ond+jgFrQ++auP65y05XcJvE7sAuFr+n HdgKtrWlCq7aTSLVZwC27c0Wi4c0zzRQ489X/5dUCDFlszxwq9+dEvDyaqnk2T0vWXCpte08o2Ur Q/6YyEKUQIUSLIHexLjY9kJbDix1+3k/Jt2bdaNcCWM9+l4a42KMoohJ45bhefB9JWlcYVzkQ2r7 fod6mH2XwI8wdzIMsknRkfsVMjj5EBKIavyV0S1x0dIfslZ/l3i9fXoAAAAldEVYdGRhdGU6Y3Jl YXRlADIwMjEtMDctMDdUMjA6MDk6MTIrMDA6MDDqPY/cAAAAJXRFWHRkYXRlOm1vZGlmeQAyMDIx LTA3LTA3VDIwOjA5OjEyKzAwOjAwm2A3YAAAAABJRU5ErkJggg== X-Now-Playing: Vanishing Twin's _The Age Of Immunology_: =?utf-8?Q?=22Plan?= =?utf-8?Q?=C3=A8te?= Sauvage" Date: Wed, 07 Jul 2021 22:29:34 +0200 In-Reply-To: <87czrt3mj4.fsf@gnus.org> (Lars Ingebrigtsen's message of "Wed, 07 Jul 2021 22:18:55 +0200") Message-ID: <878s2h3m1d.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Lars Ingebrigtsen writes: > After your faces.el fix and that additional check, Emacs now builds for > me again, both incremental and bootstrap. Or... did I speak too soon? It builds fine on Debian and Windows (incrementally and bootstrap), but I'm getting this on Macos: Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49261 Cc: michael.albinus@gmx.de, ncaprisunfan@gmail.com, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Lars Ingebrigtsen writes: > After your faces.el fix and that additional check, Emacs now builds for > me again, both incremental and bootstrap. Or... did I speak too soon? It builds fine on Debian and Windows (incrementally and bootstrap), but I'm getting this on Macos: Applications/Xcode.app/Contents/Developer/usr/bin/make -C ../admin/grammars all EMACS="../../src/bootstrap-emacs" make[3]: Nothing to be done for `all'. GEN loaddefs.el /bin/sh: line 1: 51261 Killed: 9 EMACSLOADPATH= '../src/bootstrap-emacs' -batch --no-site-file --no-site-lisp -l autoload --eval '(setq autoload-ensure-writable t)' --eval '(setq autoload-builtin-package-versions t)' --eval '(setq generated-autoload-file (expand-file-name (unmsys--file-name "loaddefs.el")))' -f batch-update-autoloads . ./calc ./calendar ./cedet ./cedet/ede ./cedet/semantic ./cedet/semantic/analyze ./cedet/semantic/bovine ./cedet/semantic/decorate ./cedet/semantic/symref ./cedet/semantic/wisent ./cedet/srecode ./emacs-lisp ./emulation ./erc ./eshell ./gnus ./image ./international ./language ./leim ./leim/ja-dic ./leim/quail ./mail ./mh-e ./net ./nxml ./org ./play ./progmodes ./textmodes ./url ./vc make[2]: *** [loaddefs.el] Error 137 make[1]: *** [../lisp/loaddefs.el] Error 2 make: *** [src] Error 2 -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 07 16:38:02 2021 Received: (at 49261) by debbugs.gnu.org; 7 Jul 2021 20:38:02 +0000 Received: from localhost ([127.0.0.1]:53630 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1EJ0-0003y0-Fn for submit@debbugs.gnu.org; Wed, 07 Jul 2021 16:38:02 -0400 Received: from quimby.gnus.org ([95.216.78.240]:55404) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1EIy-0003xf-F8 for 49261@debbugs.gnu.org; Wed, 07 Jul 2021 16:38:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=Y8tCXIZ0iDzaFR7Qmqr19d/MGYapXixnb6W8LjCZz7c=; b=sR03whPqKULAyIlwtFNL3zTrrt kc7Tb4aoL7X56mMkeq7Q2AcOv40EuL3KFDRUTf2rQkmVae22dvAnDU45UG3J7lKdrFJGhlaHi2IGr Rx7183R6wCP9XLnM3EsyaFtxgfENrFHfVVeXndIoUN77tHWFYcRSrUCkFf6lwuadRVwo=; Received: from cm-84.212.220.105.getinternet.no ([84.212.220.105] helo=elva) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m1EIp-0001nB-31; Wed, 07 Jul 2021 22:37:53 +0200 From: Lars Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: <87o8bn7bie.fsf@gnus.org> <87zgv6vuon.fsf@gmx.de> <837di9lwbm.fsf@gnu.org> <87a6n5vuu4.fsf@gnus.org> <8735sqnmei.fsf@gnus.org> <87zguyf4ht.fsf@gmx.de> <87pmvum54p.fsf@gnus.org> <87v95mf2lj.fsf@gmx.de> <87pmvt3ob1.fsf@gnus.org> <83r1g9evoy.fsf@gnu.org> <83pmvtevgg.fsf@gnu.org> <87czrt3mj4.fsf@gnus.org> <878s2h3m1d.fsf@gnus.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAGFBMVEVDOjszKyxgVlSh loyIf3js4sciGx7///9364cjAAAAAWJLR0QHFmGI6wAAAAd0SU1FB+UHBxQJDGbxOPYAAAGzSURB VDjLlZTBcpwwDIZlspOzxWR8BkFzTjHknF3oAyTE95KD3/8RKllmYTe0M9VhWfTxS7KQAAAkNoPY eLUOxcAYtIdAfooEHjL4uQFM4CmDWoFVCQM7Td73U292wArAdhJ7w5xcY8mlbFN9Jj0LSgq+tUb8 VFRUJJAUJTuACiVE16rSUXbGUYCUtJdp9P5CNErFFQAELVuO3Rknj6zgPYOxcyo+MWASPhcF/SNm a7ypCgiz3ozn1Y9f3lgGgyafcLPGIME8pG62LztQGmRFSHW1Nd5YKeCVD9iYW4ACpOWE38G8/AV8 yKU6UsilPgDhH8D+l4JqFhyA9yjVHlT1ym2xQN/P8UI6Ond+jgFrQ++auP65y05XcJvE7sAuFr+n HdgKtrWlCq7aTSLVZwC27c0Wi4c0zzRQ489X/5dUCDFlszxwq9+dEvDyaqnk2T0vWXCpte08o2Ur Q/6YyEKUQIUSLIHexLjY9kJbDix1+3k/Jt2bdaNcCWM9+l4a42KMoohJ45bhefB9JWlcYVzkQ2r7 fod6mH2XwI8wdzIMsknRkfsVMjj5EBKIavyV0S1x0dIfslZ/l3i9fXoAAAAldEVYdGRhdGU6Y3Jl YXRlADIwMjEtMDctMDdUMjA6MDk6MTIrMDA6MDDqPY/cAAAAJXRFWHRkYXRlOm1vZGlmeQAyMDIx LTA3LTA3VDIwOjA5OjEyKzAwOjAwm2A3YAAAAABJRU5ErkJggg== X-Now-Playing: Vanishing Twin's _The Age Of Immunology_: "Backstroke" Date: Wed, 07 Jul 2021 22:37:50 +0200 In-Reply-To: <878s2h3m1d.fsf@gnus.org> (Lars Ingebrigtsen's message of "Wed, 07 Jul 2021 22:29:34 +0200") Message-ID: <874kd53lnl.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Lars Ingebrigtsen writes: > Or... did I speak too soon? It builds fine on Debian and Windows > (incrementally and bootstrap), but I'm getting this on Macos: Ah, I'm seeing it elsewhere too when saying "touch lisp/*.el": Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49261 Cc: michael.albinus@gmx.de, ncaprisunfan@gmail.com, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Lars Ingebrigtsen writes: > Or... did I speak too soon? It builds fine on Debian and Windows > (incrementally and bootstrap), but I'm getting this on Macos: Ah, I'm seeing it elsewhere too when saying "touch lisp/*.el": make[2]: *** [Makefile:279: ../lisp/cus-start.elc] Error 139 make[1]: *** [Makefile:765: ../lisp/cus-start.elc] Error 2 /bin/sh: line 2: 113032 Segmentation fault (core dumped) EMACSLOADPATH= '../src/bootstrap-emacs' -batch --no-site-file --no-site-lisp --eval '(setq load-prefer-newer t)' -l bytecomp -f byte-compile-refresh-preloaded -f batch-byte-compile ../lisp/button.el make[2]: *** [Makefile:279: ../lisp/button.elc] Error 139 make[1]: *** [Makefile:765: ../lisp/button.elc] Error 2 /bin/sh: line 2: 113024 Segmentation fault (core dumped) EMACSLOADPATH= '../src/bootstrap-emacs' -batch --no-site-file --no-site-lisp --eval '(setq load-prefer-newer t)' -l bytecomp -f byte-compile-refresh-preloaded -f batch-byte-compile ../lisp/abbrev.el Still investigating... perhaps I got the lifecycle of a variable wrong or something? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 07 16:55:25 2021 Received: (at 49261) by debbugs.gnu.org; 7 Jul 2021 20:55:25 +0000 Received: from localhost ([127.0.0.1]:53642 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1EZp-0004Nx-Br for submit@debbugs.gnu.org; Wed, 07 Jul 2021 16:55:25 -0400 Received: from quimby.gnus.org ([95.216.78.240]:55506) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1EZl-0004Nh-QG for 49261@debbugs.gnu.org; Wed, 07 Jul 2021 16:55:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=eghzjO9YYe5rNqT70fXrba5L0RoKqSDjZJ2xf6gojpc=; b=d7W7u32Fm6ijA5J8Ps2hC4ariZ lrwiNieohLZIod+vJxJ6uuaCrrIOeRnTIe3B2cOrc82AHSCf9ZeXkRiKKIaLuCAJ7sE53RZX+e1KB /wSGaL+BiC20oxI8aIvAoFAywGMUhCNrwCIsrzf1owxHr0ouqSdsSrqzA5Fdn+o5eNjI=; Received: from cm-84.212.220.105.getinternet.no ([84.212.220.105] helo=elva) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m1EZc-0001wi-5L; Wed, 07 Jul 2021 22:55:14 +0200 From: Lars Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: <87o8bn7bie.fsf@gnus.org> <87zgv6vuon.fsf@gmx.de> <837di9lwbm.fsf@gnu.org> <87a6n5vuu4.fsf@gnus.org> <8735sqnmei.fsf@gnus.org> <87zguyf4ht.fsf@gmx.de> <87pmvum54p.fsf@gnus.org> <87v95mf2lj.fsf@gmx.de> <87pmvt3ob1.fsf@gnus.org> <83r1g9evoy.fsf@gnu.org> <83pmvtevgg.fsf@gnu.org> <87czrt3mj4.fsf@gnus.org> <878s2h3m1d.fsf@gnus.org> <874kd53lnl.fsf@gnus.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAElBMVEX48NH28dbh0rbG rJWVblz///+FUha/AAAAAWJLR0QF+G/pxwAAAAd0SU1FB+UHBxQzO/vlQ4AAAAGjSURBVDjLdZKN ecIgEIYP7AAH6QAIGSDhGECF/WfqBwRJavupeeK93D9EZH6JmIg0fQLzL2jkT2D+A92uxl8r8UIG WIqkfLyrM8h4+XpOO5lOvnfejUmnUMztXYzF8WXv9daCu90+ySIDP2bzhm00LD6GonR4nTzYlvSQ AuGReTZCVmSXnEpTrYXbUNSaNxRVDs1Qak0iKSBKtecoEu6986+cS5IDVKVn73y955xSteObKn50 j9XB40hdAg6VB5+muDT7S2KI6jr35rMnONzpsigLsnEdhqLpwXX73pHTit8bbAARXgU+WRErnsCI F7Qmsr0HNZJ4r53Tjumk7iISc70OF2Bj8AgWovexF6V7KAw+1Bw1jSIzwVk3iQOoaUVuDMUNj0pu SIFqaak1H6AFC9LaoFstbwJWNbuPkRYUgH34o2LGwRQBN43nNoHRvkp7p9APTQCT9eQ8PrrmHkAF WW9JtpzlRe1+DpCChFxiB3QORchQf1hWG9UA1LeBq01XD5JDH+At15qeofSRAXVr3Ak/Ae5IA0Nv oM/WCfyHRoYP/QB702bcjfceOwAAACV0RVh0ZGF0ZTpjcmVhdGUAMjAyMS0wNy0wN1QyMDo1MTo1 OSswMDowMA7wOWoAAAAldEVYdGRhdGU6bW9kaWZ5ADIwMjEtMDctMDdUMjA6NTE6NTkrMDA6MDB/ rYHWAAAAAElFTkSuQmCC X-Now-Playing: Black Midi's _Live on Canal St, NYC_: "Live on Canal St, NYC" Date: Wed, 07 Jul 2021 22:55:08 +0200 In-Reply-To: <874kd53lnl.fsf@gnus.org> (Lars Ingebrigtsen's message of "Wed, 07 Jul 2021 22:37:50 +0200") Message-ID: <87zgux26ab.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Lars Ingebrigtsen writes: > Still investigating... perhaps I got the lifecycle of a variable wrong > or something? It only happens with an -O2 build -- an -O0 build works fine. Here's what gdb says: Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49261 Cc: michael.albinus@gmx.de, ncaprisunfan@gmail.com, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Lars Ingebrigtsen writes: > Still investigating... perhaps I got the lifecycle of a variable wrong > or something? It only happens with an -O2 build -- an -O0 build works fine. Here's what gdb says: #0 0x00005555557103a7 in AREF (idx=23456123314108, array=0x7ffff1a398cd) at lisp.h:731 #1 HASH_KEY (idx=11728061657054, h=0x7ffff1a39848) at lisp.h:2374 #2 hash_lookup (h=0x7ffff1a39848, key=0x555555cae444, hash=hash@entry=0x0) at fns.c:4479 #3 0x000055555573f9f2 in exec_byte_code (bytestr=, vector=, maxdepth=, args_template=, nargs=, args=) at bytecode.c:1415 #4 0x0000555555701d07 in Ffuncall (nargs=2, args=args@entry=0x7fffffffcec8) at eval.c:3055 #5 0x000055555573d1c8 in exec_byte_code (bytestr=, vector=, maxdepth=, args_template=, nargs=, args=) at bytecode.c:632 #6 0x0000555555701d07 in Ffuncall (nargs=1, args=args@entry=0x7fffffffd790) at eval.c:3055 #7 0x000055555573d1c8 in exec_byte_code (bytestr=, vector=, maxdepth=, args_template=, nargs=, args=) at bytecode.c:632 #8 0x000055555570502f in apply_lambda (fun=0x7ffff1a23485, args=, count=4) at eval.c:3188 #9 0x00005555557040b3 in eval_sub (form=) at eval.c:2591 #10 0x0000555555705cd9 in Feval (form=0x7ffff1fc6b23, lexical=) at eval.c:2343 #11 0x0000555555700da7 in internal_condition_case (bfun=bfun@entry=0x5555556872a0 , handlers=handlers@entry=0x90, hfun=hfun@entry=0x55555568ccf0 ) at eval.c:1478 #12 0x0000555555687f26 in top_level_1 (ignore=ignore@entry=0x0) at keyboard.c:1111 #13 0x00005555557032a3 in internal_catch (tag=tag@entry=0xe610, func=func@entry=0x555555687f00 , arg=arg@entry=0x0) at eval.c:1198 #14 0x0000555555687228 in command_loop () at lisp.h:1002 #15 0x000055555568c906 in recursive_edit_1 () at keyboard.c:720 #16 0x000055555568cc32 in Frecursive_edit () at keyboard.c:789 #17 0x00005555555a286f in main (argc=13, argv=) at emacs.c:2308 Which isn't very useful. (gdb) xbacktrace "command-line-1" (0xffffcee0) "command-line" (0xffffd7a8) "normal-top-level" (0xffffdc70) And this is with all the new file locking stuff disabled. Very odd. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 07 17:04:42 2021 Received: (at 49261) by debbugs.gnu.org; 7 Jul 2021 21:04:42 +0000 Received: from localhost ([127.0.0.1]:53646 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1Eio-0004cS-Bv for submit@debbugs.gnu.org; Wed, 07 Jul 2021 17:04:42 -0400 Received: from quimby.gnus.org ([95.216.78.240]:55584) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1Eil-0004cC-Gh for 49261@debbugs.gnu.org; Wed, 07 Jul 2021 17:04:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=Sa0nM9Y/W7m2c6KQLV/RYu809pmAhTU/YArd9rzgMAk=; b=tT0oRB3U0cfjS5nIOcUmkCzW8o MFFDLvPAGwsSSs1c3zUv9yObD6mdV66VkIdzDpb/rdSZJFvzYcQAF8ic1Du4RmsTTgHRo0KqCuqgT 3hJXD/f5BXG1VNUWSCljU3nhsEb/LPkK/CnJ2PpZuZVhmTg4bujJ0FeKoDTiDVfcNbG8=; Received: from cm-84.212.220.105.getinternet.no ([84.212.220.105] helo=elva) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m1Eic-00021X-8N; Wed, 07 Jul 2021 23:04:32 +0200 From: Lars Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: <87o8bn7bie.fsf@gnus.org> <87zgv6vuon.fsf@gmx.de> <837di9lwbm.fsf@gnu.org> <87a6n5vuu4.fsf@gnus.org> <8735sqnmei.fsf@gnus.org> <87zguyf4ht.fsf@gmx.de> <87pmvum54p.fsf@gnus.org> <87v95mf2lj.fsf@gmx.de> <87pmvt3ob1.fsf@gnus.org> <83r1g9evoy.fsf@gnu.org> <83pmvtevgg.fsf@gnu.org> <87czrt3mj4.fsf@gnus.org> <878s2h3m1d.fsf@gnus.org> <874kd53lnl.fsf@gnus.org> <87zgux26ab.fsf@gnus.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAElBMVEX48NH28dbh0rbG rJWVblz///+FUha/AAAAAWJLR0QF+G/pxwAAAAd0SU1FB+UHBxQzO/vlQ4AAAAGjSURBVDjLdZKN ecIgEIYP7AAH6QAIGSDhGECF/WfqBwRJavupeeK93D9EZH6JmIg0fQLzL2jkT2D+A92uxl8r8UIG WIqkfLyrM8h4+XpOO5lOvnfejUmnUMztXYzF8WXv9daCu90+ySIDP2bzhm00LD6GonR4nTzYlvSQ AuGReTZCVmSXnEpTrYXbUNSaNxRVDs1Qak0iKSBKtecoEu6986+cS5IDVKVn73y955xSteObKn50 j9XB40hdAg6VB5+muDT7S2KI6jr35rMnONzpsigLsnEdhqLpwXX73pHTit8bbAARXgU+WRErnsCI F7Qmsr0HNZJ4r53Tjumk7iISc70OF2Bj8AgWovexF6V7KAw+1Bw1jSIzwVk3iQOoaUVuDMUNj0pu SIFqaak1H6AFC9LaoFstbwJWNbuPkRYUgH34o2LGwRQBN43nNoHRvkp7p9APTQCT9eQ8PrrmHkAF WW9JtpzlRe1+DpCChFxiB3QORchQf1hWG9UA1LeBq01XD5JDH+At15qeofSRAXVr3Ak/Ae5IA0Nv oM/WCfyHRoYP/QB702bcjfceOwAAACV0RVh0ZGF0ZTpjcmVhdGUAMjAyMS0wNy0wN1QyMDo1MTo1 OSswMDowMA7wOWoAAAAldEVYdGRhdGU6bW9kaWZ5ADIwMjEtMDctMDdUMjA6NTE6NTkrMDA6MDB/ rYHWAAAAAElFTkSuQmCC X-Now-Playing: Black Midi's _Live on Canal St, NYC_: "Live on Canal St, NYC" Date: Wed, 07 Jul 2021 23:04:29 +0200 In-Reply-To: <87zgux26ab.fsf@gnus.org> (Lars Ingebrigtsen's message of "Wed, 07 Jul 2021 22:55:08 +0200") Message-ID: <87pmvt25uq.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Hm! I rewound back to checkout 90c89e8bdeca61aceae79e4c60a9a51800574914, and then said make bootstrap; touch lisp/*.el; make Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49261 Cc: michael.albinus@gmx.de, ncaprisunfan@gmail.com, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Hm! I rewound back to checkout 90c89e8bdeca61aceae79e4c60a9a51800574914, and then said make bootstrap; touch lisp/*.el; make and that segfaults. So this build failure doesn't seem to be related to the locking changes. *phew* So I'm bisecting now back to the offending commit. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 07 18:22:30 2021 Received: (at 49261) by debbugs.gnu.org; 7 Jul 2021 22:22:30 +0000 Received: from localhost ([127.0.0.1]:53700 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1Fw6-0006Tz-2r for submit@debbugs.gnu.org; Wed, 07 Jul 2021 18:22:30 -0400 Received: from quimby.gnus.org ([95.216.78.240]:55982) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1Fw2-0006Tk-HW for 49261@debbugs.gnu.org; Wed, 07 Jul 2021 18:22:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=5Wk3wGnllED3FYEDVaXPx8quaCsIUARAD/TRYWkFzGo=; b=ObvZFCv6raA8C0U56w/toCFL09 BuABVtnsrR6TAMQszyZFxYcTjoOmbQWdR/4Lo/dOdiGcbFt5Sd5KESlLpTnri9uL1XkoPcdEv2hdr An5roHPFRIOMfE7aRs6xsQlqj2zrmCP9o+n9KpvKv+5RlHpOioMmpH8eXn+HBv/3ckPE=; Received: from cm-84.212.220.105.getinternet.no ([84.212.220.105] helo=elva) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m1Fvt-0002ZC-35; Thu, 08 Jul 2021 00:22:19 +0200 From: Lars Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: <87o8bn7bie.fsf@gnus.org> <87zgv6vuon.fsf@gmx.de> <837di9lwbm.fsf@gnu.org> <87a6n5vuu4.fsf@gnus.org> <8735sqnmei.fsf@gnus.org> <87zguyf4ht.fsf@gmx.de> <87pmvum54p.fsf@gnus.org> <87v95mf2lj.fsf@gmx.de> <87pmvt3ob1.fsf@gnus.org> <83r1g9evoy.fsf@gnu.org> <83pmvtevgg.fsf@gnu.org> <87czrt3mj4.fsf@gnus.org> <878s2h3m1d.fsf@gnus.org> <874kd53lnl.fsf@gnus.org> <87zgux26ab.fsf@gnus.org> <87pmvt25uq.fsf@gnus.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwAgMAAAAqbBEUAAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAADFBMVEXBv8AxMTZ/fYH/ //9f11wxAAAAAWJLR0QDEQxM8gAAAAd0SU1FB+UHBxYUGIDDVPkAAAFrSURBVCjPdZFBS8NAEIUf C0LM2RTaUyhG2vwKr95KYRayJy2kmPyKJSBITiJs0J62YqXZX+mMaW09OOSwX97Om+UNEiJDVLZZ SQQGIk23J+hpmZGALlnouguBzPS6de7uU4tiQtj1tLo2HWHE4GoywYwcJssQYlevp4ukx2QVwmYe xfYlKTC9VxZxFCFlSD0AhdimiUNq+dww5PPqR+GLgJ8sgRlgLZTy+StSDGV93osQuAM+jbaIwZ/y 8nOKqUUkCsMlbrxYRdKrMJrZGD9zI4Vs31w0TSSzFCZvPls2XjwU5k1DxZ6f8Zgq5KGuaM9NV3mD 9GG1Ja2ukHcBs2z1TouPvWo5kPmOM6oXPnaSTiUpbrKd3g2JGmqfSLsBHqnd/sKz6TYSOCT9oqo7 ZwIDKwX16yp8DSBVG5lzAN0zjA/QOdLD5rhKWeOxp6DjTg+F/F8YUyXPGiCh+jjpj4E7h/IcCoby 5ObOrL8B712sv+MEtpIAAAAldEVYdGRhdGU6Y3JlYXRlADIwMjEtMDctMDdUMjI6MjA6MjQrMDA6 MDDDR5pFAAAAJXRFWHRkYXRlOm1vZGlmeQAyMDIxLTA3LTA3VDIyOjIwOjI0KzAwOjAwshoi+QAA AABJRU5ErkJggg== X-Now-Playing: UNKLE's _20 Years of Fabric (2)_: "Catch Me When I Fall (fabric Club Mix)" Date: Thu, 08 Jul 2021 00:22:15 +0200 In-Reply-To: <87pmvt25uq.fsf@gnus.org> (Lars Ingebrigtsen's message of "Wed, 07 Jul 2021 23:04:29 +0200") Message-ID: <87lf6h2294.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Lars Ingebrigtsen writes: > I rewound back to checkout 90c89e8bdeca61aceae79e4c60a9a51800574914, and > then said > > make bootstrap; touch lisp/*.el; make > > and that segfaults. So this build failure doesn't seem to be relate [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49261 Cc: michael.albinus@gmx.de, ncaprisunfan@gmail.com, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Lars Ingebrigtsen writes: > I rewound back to checkout 90c89e8bdeca61aceae79e4c60a9a51800574914, and > then said > > make bootstrap; touch lisp/*.el; make > > and that segfaults. So this build failure doesn't seem to be related to > the locking changes. *phew* So I'm bisecting now back to the offending > commit. OK, I give up -- I rewound back to October 2020, and it still displays this behaviour. I'm guessing the problem arrived on master from a branch that was merged, but I'm not proficient enough in git to poke through that stuff. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 07 20:10:06 2021 Received: (at 49261) by debbugs.gnu.org; 8 Jul 2021 00:10:06 +0000 Received: from localhost ([127.0.0.1]:53758 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1HcE-0000j1-I9 for submit@debbugs.gnu.org; Wed, 07 Jul 2021 20:10:06 -0400 Received: from quimby.gnus.org ([95.216.78.240]:56646) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1Hc9-0000iL-Nc for 49261@debbugs.gnu.org; Wed, 07 Jul 2021 20:10:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=lqdDELCYdBPPt9TSCL7/7v0utS+39T1Rklc3piZgTok=; b=LTKKURD81ZP/nlLZfDL+5iN3g9 TGC2azTFhSJKGw89Qpd4t0CMdibEZBftvW0p/knvc8Rsfswqz8Etov229EKPVyc50AI8rkrvSvZZI pC3UZJGTL0o9epyJYotnhQxGK6XhMb9EZsia5W8voeeTdjGjKtmDIRvXJLwTIr5HJug0=; Received: from cm-84.212.220.105.getinternet.no ([84.212.220.105] helo=elva) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m1Hbz-0003Xu-Lp; Thu, 08 Jul 2021 02:09:54 +0200 From: Lars Ingebrigtsen To: Paul Eggert Subject: Re: Segfault during loadup References: <87o8bn7bie.fsf@gnus.org> <87zgv6vuon.fsf@gmx.de> <837di9lwbm.fsf@gnu.org> <87a6n5vuu4.fsf@gnus.org> <8735sqnmei.fsf@gnus.org> <87zguyf4ht.fsf@gmx.de> <87pmvum54p.fsf@gnus.org> <87v95mf2lj.fsf@gmx.de> <87pmvt3ob1.fsf@gnus.org> <83r1g9evoy.fsf@gnu.org> <83pmvtevgg.fsf@gnu.org> <87czrt3mj4.fsf@gnus.org> <878s2h3m1d.fsf@gnus.org> <874kd53lnl.fsf@gnus.org> <87zgux26ab.fsf@gnus.org> <87pmvt25uq.fsf@gnus.org> <87lf6h2294.fsf@gnus.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAG1BMVEXw7+1oZGNBKEZ1 Y6C+s6tEm+XLNj/k0zH////9N41TAAAAAWJLR0QIht6VegAAAAd0SU1FB+UHBxc7BmkSO8AAAAGn SURBVDjLdZRBc4IwEIVhzIznEEavzYJ4NWDtFa3Vc6v2rIxDr2qd8veb7AbCiLwLzH7sbrJ5wfN6 FQBKKq4VyEDiM/Y8TiD6wkcA9KEBEmol2fQeD+MCFALhwHF7WQ/vPnADxFuFuhkwvHjDy4BKCYpX q0fAp7S6tANCjDPogKqnB+/v0ZcxI9DpETKMX7vA56iiUwrHyUcGnLf3nHkDRQAow5Qq5E36uR8F lLFG6XEnJ6HEezgQNN2ZG0n5cSClBswxYQMtsMMTjEoUQFkWNmGHpfYYPyGIMpIpJeqyGtjkslQO 7FIY/fwuLChMqRdrIz3MW52BPSjugwbXkQUpzoosEkTOhGB6hOQwmcKsAUvlhihAlk4IrGCyeQBj OsFCfjdxqVpmKGDUgBOC2E43OjR6PxiQW8Mlrw34nOyNGewUktaqSrMPu5gC2uDcHG2+kpXTnwHj ukcLVAZUHI9Gm4flHmOYz3SP8c0OEY6tuzx39llBlJEvUG6DeDvrwZnbxDP8Yong1AJC0asypLVB xrPaMhoI+744e0xODk+kAchnYN/7U/oHxUjmLTsE9/cAAAAldEVYdGRhdGU6Y3JlYXRlADIwMjEt MDctMDdUMjM6NTk6MDUrMDA6MDAvrXFAAAAAJXRFWHRkYXRlOm1vZGlmeQAyMDIxLTA3LTA3VDIz OjU5OjA1KzAwOjAwXvDJ/AAAAABJRU5ErkJggg== X-Now-Playing: Battles's _Juice B Crypts_: "The Last Supper On Shasta" Date: Thu, 08 Jul 2021 02:09:45 +0200 In-Reply-To: <87lf6h2294.fsf@gnus.org> (Lars Ingebrigtsen's message of "Thu, 08 Jul 2021 00:22:15 +0200") Message-ID: <87h7h51x9y.fsf_-_@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: To reproduce: make bootstrap; touch lisp/*.el; make ... make[2]: *** [Makefile:279: ../lisp/cus-start.elc] Error 139 make[1]: *** [Makefile:765: ../lisp/cus-start.elc] Error 2 /bin/sh: line 2: 113032 Segmentation fault (core dumped) Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49261 Cc: Eli Zaretskii , 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) To reproduce: make bootstrap; touch lisp/*.el; make ... make[2]: *** [Makefile:279: ../lisp/cus-start.elc] Error 139 make[1]: *** [Makefile:765: ../lisp/cus-start.elc] Error 2 /bin/sh: line 2: 113032 Segmentation fault (core dumped) I bisected this, and git bisect pointed me to: commit 6cf62141c4467314f67c2ef75a4bf94d41ff050f Author: Paul Eggert AuthorDate: Sat Sep 5 12:13:32 2020 -0700 Reinstall recent GC-related changes The report that they broke macOS was a false alarm, as the previous commit was also broken (Bug#43152#62). Running under gdb after the "make" fails: gdb ./bootstrap-emacs run -batch --no-site-file --no-site-lisp --eval '(setq load-prefer-newer t)' -l bytecomp -f byte-compile-refresh-preloaded -f batch-byte-compile ../lisp/abbrev.elb #0 0x00005555557103a7 in AREF (idx=23456123314108, array=0x7ffff1a398cd) at lisp.h:731 #1 HASH_KEY (idx=11728061657054, h=0x7ffff1a39848) at lisp.h:2374 #2 hash_lookup (h=0x7ffff1a39848, key=0x555555cae444, hash=hash@entry=0x0) at fns.c:4479 ... There seems to be a corruption in the hash tables somewhere. It's totally reproducible with the recipe, but I haven't found more self-contained example to reproduce it. This does not show up with -O0, but does show up with -O1 and -O2. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 08 02:03:57 2021 Received: (at 49261) by debbugs.gnu.org; 8 Jul 2021 06:03:57 +0000 Received: from localhost ([127.0.0.1]:54029 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1N8e-0001pX-VK for submit@debbugs.gnu.org; Thu, 08 Jul 2021 02:03:57 -0400 Received: from mout.gmx.net ([212.227.17.21]:48679) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1N8a-0001pD-0v for 49261@debbugs.gnu.org; Thu, 08 Jul 2021 02:03:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1625724222; bh=6AgrhWF1VQ5wRLFKY30SMMHLqRnFZggKVGa2H0pXti8=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=dxcmzciSBFNRV7KCs6P+ldhxoxjM8ieyyFFWmbst1BVakdYvSF8SlfkPrxk8e5eUv eKXnTjhx3zVMGK6WXwodShY5EakZ8u3TzxMwW6BFyYa4VLIqY5Se98L6jcfE0f29en hnoVY3VjEjxs1WlUszA7SUTePBUb9IUtPaPsRWRg= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from gandalf.gmx.de ([213.220.147.36]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MSKu0-1ldHlN3jqq-00SeoE; Thu, 08 Jul 2021 08:03:42 +0200 From: Michael Albinus To: Lars Ingebrigtsen Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: <87o8bn7bie.fsf@gnus.org> <87zgv6vuon.fsf@gmx.de> <837di9lwbm.fsf@gnu.org> <87a6n5vuu4.fsf@gnus.org> <8735sqnmei.fsf@gnus.org> <87zguyf4ht.fsf@gmx.de> <87pmvum54p.fsf@gnus.org> <87v95mf2lj.fsf@gmx.de> <87pmvt3ob1.fsf@gnus.org> <87fswpgacv.fsf@gmx.de> Date: Thu, 08 Jul 2021 08:03:40 +0200 In-Reply-To: <87fswpgacv.fsf@gmx.de> (Michael Albinus's message of "Wed, 07 Jul 2021 22:03:28 +0200") Message-ID: <87bl7dfikj.fsf@gmx.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:w8DQffWmmTP+3W92pAq81EqpjgleqI5AcUIn3PgDIfi2VFBbzYc w1rDjeiUeiwdnjpCTB3TSL1UU1jG3Wn5oy1wPoZJEGkWh4Wbh6UwwCtkEYL7NRCIay3YOaV QvCsshXDn/4AoLuBl8WNU85PUBRmBr2daKEmakZj9USyx3b9eCfxD0pw1rjocF1WFz76chj CGgWy74hQ1L5KqIFYrCMw== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:RXSZnWtrdk0=:6KhQow/eJs6S0pUHJBO6lu hDRjq+80MLQSNNkWhvSbXSCDWITbsJ5hrFb1I8KLPiT8V7PDJSDU+zXx6lwpYpjsf3qkZEFV0 rBJBUxq5XDzKF53pbLy4ByTNeuUNlrlibxLaXpUb104iWG5MlkgcgL95qmtwXSsWDPjFyzy63 zDgY/96/RgoRzN+2yewzm27pWtIooYcwrsu01kb9/N3MNJDPC7caqCSeTlNhUos7nkIY+nh1N wFqTmWTBuqwwgZz3UJE57qJVRiRKHsiBQHfu20RwbMH9GxqvKfg1XJN2rXqQsNrh1aVb9qVaU mRyO4/Z6o17HR91etkjOYGgBqnXgoGGWuaFlFVB1iaU3tzMyC40+/vN3mt6PxwIAeEpLcd5GX ziufhQAySTJHhKK+tbWIp2VMm9k0+xy03FfewzpL0KOtiMneNAybtuvJgZG2tfMOQzvPj6oui JuWdSWZISsJ8LJBVOXUu8q4e5vUJHtiZev15Sgo6wQWHigLDZ9Dht4pueHnY7maXuHXwUwNR/ mLJ1iFG32VSAm7OZj57ejuw99p1Em7eaOvt5xxnf33K2n5rufYrx8bFNiFEkHfBZ/YRotjnWm KOCRVeoSO5sQzGX8xMXYc33/wfWoIM/wPtWwiN4qnmyIiiUs/k1XoX9bMEM5CdhOXl3PApgfJ 70vOr1sfkgxqXAzv17/3O9AJny0MNFOGn4WyJ3ClLzmUNNYADmdEq8JR/llauKiFXa7bM4AnC ef+jzBW0XzVv2rmIMqmcLq9amUAKAhnSBngkI4BAjAFaZQ9sAtDJg12Bs8B77wn41WMkSjEJb vWi+FBTGdTTtHDq5zUvsJ44NRv3AP92MojI8B7L5VMBeahG/Y2qjDXoIKPKFk/v8ca3YPW3Bs tNk9nH9jjE/j/pBOMmCv9ywk48vaQY72+vQU+xOM9cyCctdNkuiyz17blZHUEoRRagGMxeNAg G30Eihhf72ZX0H5wJOyFGR1qRj3y0OviMasoKYLcbgUsiVkbj/xGFaClPSRFkxUHw2jJzjv/L W7MGh1KQuqH2OzMqgn0TFT5ir5K38Yblz0etSwBy5UXsnleZ7cL6g6pvO9/1xF2giONn9GST9 0aC4ZYlmwK405vigRlO0xgn2VXey0c60UT/Bmlikl5vVKomjXZAbbVNmw== X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 49261 Cc: Eli Zaretskii , ncaprisunfan@gmail.com, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Michael Albinus writes: Hi Lars, > I see no regressions. Three test cases still fail > (file-notify-test03-events-remote, shadow-test08-shadow-todo, > shadow-test09-shadow-copy-files), but the most important one, > tramp-test39-lock-file, still succeeds. I've pushed another change which let all test cases succeed, as far as I am involved. Furthermore, I have renamed auto-save--transform-file-name to files--transform-file-name, because it isn't restricted to auto-save files. I don't apply make bootstrap, so I'm not plagued with the segfault problem. > I will check tomorrow why these test cases fail, and how to integrate > the new lock-file-name-transforms into Tramp. This remains open for later today, or tomorrow. Best regards, Michael. From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 08 02:15:02 2021 Received: (at 49261) by debbugs.gnu.org; 8 Jul 2021 06:15:02 +0000 Received: from localhost ([127.0.0.1]:54048 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1NJN-00025T-KS for submit@debbugs.gnu.org; Thu, 08 Jul 2021 02:15:01 -0400 Received: from eggs.gnu.org ([209.51.188.92]:52102) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1NJL-00025F-0a for 49261@debbugs.gnu.org; Thu, 08 Jul 2021 02:15:00 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:56560) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m1NJF-0003VZ-4N; Thu, 08 Jul 2021 02:14:53 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:1840 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m1NJE-0007r5-OT; Thu, 08 Jul 2021 02:14:53 -0400 Date: Thu, 08 Jul 2021 09:15:04 +0300 Message-Id: <83lf6he3h3.fsf@gnu.org> From: Eli Zaretskii To: Lars Ingebrigtsen In-Reply-To: <87lf6h2294.fsf@gnus.org> (message from Lars Ingebrigtsen on Thu, 08 Jul 2021 00:22:15 +0200) Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: <87o8bn7bie.fsf@gnus.org> <87zgv6vuon.fsf@gmx.de> <837di9lwbm.fsf@gnu.org> <87a6n5vuu4.fsf@gnus.org> <8735sqnmei.fsf@gnus.org> <87zguyf4ht.fsf@gmx.de> <87pmvum54p.fsf@gnus.org> <87v95mf2lj.fsf@gmx.de> <87pmvt3ob1.fsf@gnus.org> <83r1g9evoy.fsf@gnu.org> <83pmvtevgg.fsf@gnu.org> <87czrt3mj4.fsf@gnus.org> <878s2h3m1d.fsf@gnus.org> <874kd53lnl.fsf@gnus.org> <87zgux26ab.fsf@gnus.org> <87pmvt25uq.fsf@gnus.org> <87lf6h2294.fsf@gnus.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49261 Cc: michael.albinus@gmx.de, ncaprisunfan@gmail.com, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Lars Ingebrigtsen > Cc: michael.albinus@gmx.de, ncaprisunfan@gmail.com, 49261@debbugs.gnu.org > Date: Thu, 08 Jul 2021 00:22:15 +0200 > > Lars Ingebrigtsen writes: > > > I rewound back to checkout 90c89e8bdeca61aceae79e4c60a9a51800574914, and > > then said > > > > make bootstrap; touch lisp/*.el; make > > > > and that segfaults. So this build failure doesn't seem to be related to > > the locking changes. *phew* So I'm bisecting now back to the offending > > commit. > > OK, I give up -- I rewound back to October 2020, and it still displays > this behaviour. I'm guessing the problem arrived on master from a > branch that was merged, but I'm not proficient enough in git to poke > through that stuff. Is this only on macOS? If not, on which systems do you see this crash? From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 08 02:17:11 2021 Received: (at 49261) by debbugs.gnu.org; 8 Jul 2021 06:17:12 +0000 Received: from localhost ([127.0.0.1]:54061 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1NLT-00029r-JX for submit@debbugs.gnu.org; Thu, 08 Jul 2021 02:17:11 -0400 Received: from eggs.gnu.org ([209.51.188.92]:52428) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1NLO-00029H-4x for 49261@debbugs.gnu.org; Thu, 08 Jul 2021 02:17:10 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:56580) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m1NLI-0004JX-Tz; Thu, 08 Jul 2021 02:17:00 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:1978 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m1NLI-000849-HI; Thu, 08 Jul 2021 02:17:00 -0400 Date: Thu, 08 Jul 2021 09:17:15 +0300 Message-Id: <83k0m1e3dg.fsf@gnu.org> From: Eli Zaretskii To: Lars Ingebrigtsen In-Reply-To: <87zgux26ab.fsf@gnus.org> (message from Lars Ingebrigtsen on Wed, 07 Jul 2021 22:55:08 +0200) Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: <87o8bn7bie.fsf@gnus.org> <87zgv6vuon.fsf@gmx.de> <837di9lwbm.fsf@gnu.org> <87a6n5vuu4.fsf@gnus.org> <8735sqnmei.fsf@gnus.org> <87zguyf4ht.fsf@gmx.de> <87pmvum54p.fsf@gnus.org> <87v95mf2lj.fsf@gmx.de> <87pmvt3ob1.fsf@gnus.org> <83r1g9evoy.fsf@gnu.org> <83pmvtevgg.fsf@gnu.org> <87czrt3mj4.fsf@gnus.org> <878s2h3m1d.fsf@gnus.org> <874kd53lnl.fsf@gnus.org> <87zgux26ab.fsf@gnus.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49261 Cc: michael.albinus@gmx.de, ncaprisunfan@gmail.com, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Lars Ingebrigtsen > Cc: michael.albinus@gmx.de, ncaprisunfan@gmail.com, 49261@debbugs.gnu.org > Date: Wed, 07 Jul 2021 22:55:08 +0200 > > Lars Ingebrigtsen writes: > > > Still investigating... perhaps I got the lifecycle of a variable wrong > > or something? > > It only happens with an -O2 build -- an -O0 build works fine. Here's > what gdb says: > > #0 0x00005555557103a7 in AREF (idx=23456123314108, array=0x7ffff1a398cd) > at lisp.h:731 > #1 HASH_KEY (idx=11728061657054, h=0x7ffff1a39848) at lisp.h:2374 > #2 hash_lookup (h=0x7ffff1a39848, key=0x555555cae444, hash=hash@entry=0x0) > at fns.c:4479 > #3 0x000055555573f9f2 in exec_byte_code > (bytestr=, vector=, maxdepth=, args_template=, nargs=, args=) > at bytecode.c:1415 > #4 0x0000555555701d07 in Ffuncall (nargs=2, args=args@entry=0x7fffffffcec8) > at eval.c:3055 > #5 0x000055555573d1c8 in exec_byte_code > (bytestr=, vector=, maxdepth=, args_template=, nargs=, args=) > at bytecode.c:632 > #6 0x0000555555701d07 in Ffuncall (nargs=1, args=args@entry=0x7fffffffd790) > at eval.c:3055 > #7 0x000055555573d1c8 in exec_byte_code > (bytestr=, vector=, maxdepth=, args_template=, nargs=, args=) > at bytecode.c:632 > #8 0x000055555570502f in apply_lambda > (fun=0x7ffff1a23485, args=, count=4) at eval.c:3188 > #9 0x00005555557040b3 in eval_sub (form=) at eval.c:2591 > #10 0x0000555555705cd9 in Feval (form=0x7ffff1fc6b23, lexical=) > at eval.c:2343 > #11 0x0000555555700da7 in internal_condition_case > (bfun=bfun@entry=0x5555556872a0 , handlers=handlers@entry=0x90, hfun=hfun@entry=0x55555568ccf0 ) at eval.c:1478 > #12 0x0000555555687f26 in top_level_1 (ignore=ignore@entry=0x0) > at keyboard.c:1111 > #13 0x00005555557032a3 in internal_catch > (tag=tag@entry=0xe610, func=func@entry=0x555555687f00 , arg=arg@entry=0x0) at eval.c:1198 > #14 0x0000555555687228 in command_loop () at lisp.h:1002 > #15 0x000055555568c906 in recursive_edit_1 () at keyboard.c:720 > #16 0x000055555568cc32 in Frecursive_edit () at keyboard.c:789 > #17 0x00005555555a286f in main (argc=13, argv=) at emacs.c:2308 > > > Which isn't very useful. > > (gdb) xbacktrace > "command-line-1" (0xffffcee0) > "command-line" (0xffffd7a8) > "normal-top-level" (0xffffdc70) Can you show the form being evaluated in frame #10? Like this: (gdb) fr 10 (gdb) pp form From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 08 02:20:02 2021 Received: (at 49261) by debbugs.gnu.org; 8 Jul 2021 06:20:02 +0000 Received: from localhost ([127.0.0.1]:54082 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1NOE-0002Ew-0o for submit@debbugs.gnu.org; Thu, 08 Jul 2021 02:20:02 -0400 Received: from eggs.gnu.org ([209.51.188.92]:52902) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1NOC-0002ES-Cx for 49261@debbugs.gnu.org; Thu, 08 Jul 2021 02:20:00 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:56612) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m1NO6-0005Id-Pl; Thu, 08 Jul 2021 02:19:54 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2152 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m1NO5-0008G9-90; Thu, 08 Jul 2021 02:19:54 -0400 Date: Thu, 08 Jul 2021 09:20:07 +0300 Message-Id: <83im1le38o.fsf@gnu.org> From: Eli Zaretskii To: Lars Ingebrigtsen In-Reply-To: <87pmvt25uq.fsf@gnus.org> (message from Lars Ingebrigtsen on Wed, 07 Jul 2021 23:04:29 +0200) Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: <87o8bn7bie.fsf@gnus.org> <87zgv6vuon.fsf@gmx.de> <837di9lwbm.fsf@gnu.org> <87a6n5vuu4.fsf@gnus.org> <8735sqnmei.fsf@gnus.org> <87zguyf4ht.fsf@gmx.de> <87pmvum54p.fsf@gnus.org> <87v95mf2lj.fsf@gmx.de> <87pmvt3ob1.fsf@gnus.org> <83r1g9evoy.fsf@gnu.org> <83pmvtevgg.fsf@gnu.org> <87czrt3mj4.fsf@gnus.org> <878s2h3m1d.fsf@gnus.org> <874kd53lnl.fsf@gnus.org> <87zgux26ab.fsf@gnus.org> <87pmvt25uq.fsf@gnus.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49261 Cc: michael.albinus@gmx.de, ncaprisunfan@gmail.com, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Lars Ingebrigtsen > Cc: michael.albinus@gmx.de, ncaprisunfan@gmail.com, 49261@debbugs.gnu.org > Date: Wed, 07 Jul 2021 23:04:29 +0200 > > I rewound back to checkout 90c89e8bdeca61aceae79e4c60a9a51800574914, and > then said > > make bootstrap; touch lisp/*.el; make > > and that segfaults. So this build failure doesn't seem to be related to > the locking changes. *phew* So I'm bisecting now back to the offending > commit. To make sure this is indeed segfaults for that commit, I suggest to clone the upstream repository into a separate directory and repeat the experiment there. There could be some left-overs of newer builds that are not deleted/remade by a rebuild in a tree that is not 100% clean. From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 08 02:35:10 2021 Received: (at 49261) by debbugs.gnu.org; 8 Jul 2021 06:35:10 +0000 Received: from localhost ([127.0.0.1]:54097 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1Ncg-0002d3-8Y for submit@debbugs.gnu.org; Thu, 08 Jul 2021 02:35:10 -0400 Received: from eggs.gnu.org ([209.51.188.92]:54756) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1Nce-0002cn-3Z for 49261@debbugs.gnu.org; Thu, 08 Jul 2021 02:34:57 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:56794) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m1NcY-0001ML-25; Thu, 08 Jul 2021 02:34:50 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3075 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m1NcX-0007rB-N2; Thu, 08 Jul 2021 02:34:50 -0400 Date: Thu, 08 Jul 2021 09:35:03 +0300 Message-Id: <83eec9e2js.fsf@gnu.org> From: Eli Zaretskii To: Lars Ingebrigtsen In-Reply-To: <87h7h51x9y.fsf_-_@gnus.org> (message from Lars Ingebrigtsen on Thu, 08 Jul 2021 02:09:45 +0200) Subject: Re: Segfault during loadup References: <87o8bn7bie.fsf@gnus.org> <87zgv6vuon.fsf@gmx.de> <837di9lwbm.fsf@gnu.org> <87a6n5vuu4.fsf@gnus.org> <8735sqnmei.fsf@gnus.org> <87zguyf4ht.fsf@gmx.de> <87pmvum54p.fsf@gnus.org> <87v95mf2lj.fsf@gmx.de> <87pmvt3ob1.fsf@gnus.org> <83r1g9evoy.fsf@gnu.org> <83pmvtevgg.fsf@gnu.org> <87czrt3mj4.fsf@gnus.org> <878s2h3m1d.fsf@gnus.org> <874kd53lnl.fsf@gnus.org> <87zgux26ab.fsf@gnus.org> <87pmvt25uq.fsf@gnus.org> <87lf6h2294.fsf@gnus.org> <87h7h51x9y.fsf_-_@gnus.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49261 Cc: eggert@cs.ucla.edu, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > From: Lars Ingebrigtsen > Cc: 49261@debbugs.gnu.org, Eli Zaretskii > Date: Thu, 08 Jul 2021 02:09:45 +0200 > > To reproduce: > > make bootstrap; touch lisp/*.el; make > > ... > make[2]: *** [Makefile:279: ../lisp/cus-start.elc] Error 139 > make[1]: *** [Makefile:765: ../lisp/cus-start.elc] Error 2 > /bin/sh: line 2: 113032 Segmentation fault (core dumped) > > > I bisected this, and git bisect pointed me to: > > commit 6cf62141c4467314f67c2ef75a4bf94d41ff050f > Author: Paul Eggert > AuthorDate: Sat Sep 5 12:13:32 2020 -0700 > > Reinstall recent GC-related changes > > The report that they broke macOS was a false alarm, as the > previous commit was also broken (Bug#43152#62). So the last paragraph above is incorrect, and "the previous commit" is not broken? Then what about the information in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=43152#65 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=43152#68 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=43152#71 And the rest of the discussion about verify.h being the culprit? From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 08 08:43:04 2021 Received: (at 49261) by debbugs.gnu.org; 8 Jul 2021 12:43:04 +0000 Received: from localhost ([127.0.0.1]:54597 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1TMt-0005mV-Um for submit@debbugs.gnu.org; Thu, 08 Jul 2021 08:43:04 -0400 Received: from quimby.gnus.org ([95.216.78.240]:34542) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1TMs-0005m2-0l for 49261@debbugs.gnu.org; Thu, 08 Jul 2021 08:43:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=zsJjJIblfVKddYXknYfiq/MKK1C6e9KdOJYFcOv6Kl8=; b=VEI/kP1AOX6A5eoHw9pSPcNr84 gOYzRqAKxK1tMNlVeeuU+4nPiDEWuRYFkCwG158BQNJ/BpqZK1/b7Ol33qIS10vnNctjOpvkUtvCM pZlQiIzqW1fiXYd5g4pfkCRdQMKLHZYQAS73w5l31qaZRj15m6Yu4tQukjxA4GD2WOgc=; Received: from cm-84.212.220.105.getinternet.no ([84.212.220.105] helo=elva) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m1TMa-0002aC-PI; Thu, 08 Jul 2021 14:42:50 +0200 From: Lars Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: <87o8bn7bie.fsf@gnus.org> <87zgv6vuon.fsf@gmx.de> <837di9lwbm.fsf@gnu.org> <87a6n5vuu4.fsf@gnus.org> <8735sqnmei.fsf@gnus.org> <87zguyf4ht.fsf@gmx.de> <87pmvum54p.fsf@gnus.org> <87v95mf2lj.fsf@gmx.de> <87pmvt3ob1.fsf@gnus.org> <83r1g9evoy.fsf@gnu.org> <83pmvtevgg.fsf@gnu.org> <87czrt3mj4.fsf@gnus.org> <878s2h3m1d.fsf@gnus.org> <874kd53lnl.fsf@gnus.org> <87zgux26ab.fsf@gnus.org> <83k0m1e3dg.fsf@gnu.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAElBMVEX6+/i0tq51eoI5 P1tNUmT////HiKSZAAAAAWJLR0QF+G/pxwAAAAd0SU1FB+UHCAwnOXETF2cAAAF+SURBVDjLzZJR lqwgDETB6QVA6wK0YQEPkwUoyf7XNAngCL4z/8NHt4drpSoxxvx3nPmTx3rfHj6/vDHTqn9v5u0B OMlvBGY+B8AcnVkwC2A3AjYWs4lPSeBsXrxKyYdkxiTwEChn7XNHZ/ECo71YSLJSKo9gQmaPCvgB Mse4xdHdHuIiNx+3jCCypRxzxC0oOO42cjjVIzCOsabPruaUd37EmteSKjPxYGKxxpVZ8lBrSheo Crwkr6MCbICxfa+5gVw7FyFsPaCbtGpL9cAQ+efsxaOmyjvdgFRiQfuQKXbJ6KhfcJPVyZ2Ay94Y S4DYlbkBU2mjXGEHAuG7TLYCwAYWRPdqxqokqGBCcBKZClIAQAosaTRRNAByUHcm4F6abLMQQACq AHAFlAIqA9KyyVCqYwGsQN6oYN16IIKiUTC3Unh9jGJ+6io4BW14vHvPJa6AIH1IJdXkt9zoFp8X SMvpfbZpSqIwHfj3JRss4KUdelzU/Ab7VMYl5jZ9A+57jQag6idkAAAAJXRFWHRkYXRlOmNyZWF0 ZQAyMDIxLTA3LTA4VDEyOjM5OjU2KzAwOjAwkQ00ngAAACV0RVh0ZGF0ZTptb2RpZnkAMjAyMS0w Ny0wOFQxMjozOTo1NiswMDowMOBQjCIAAAAASUVORK5CYII= X-Now-Playing: Oval's _Scis_: "Piqqo" Date: Thu, 08 Jul 2021 14:42:44 +0200 In-Reply-To: <83k0m1e3dg.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 08 Jul 2021 09:17:15 +0300") Message-ID: <875yxlugcb.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Eli Zaretskii writes: > Can you show the form being evaluated in frame #10? Like this: > > (gdb) fr 10 > (gdb) pp form Hm: Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49261 Cc: michael.albinus@gmx.de, ncaprisunfan@gmail.com, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: > Can you show the form being evaluated in frame #10? Like this: > > (gdb) fr 10 > (gdb) pp form Hm: (gdb) fr 10 #10 0x0000555555706a59 in Feval (form=XIL(0x7ffff20f5023), lexical=) at eval.c:2343 2343 return unbind_to (count, eval_sub (form)); (gdb) pp form # This is with an -O2 build; the bug also reproduces with an -O1 build; I'll try that... -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 08 08:44:58 2021 Received: (at 49261) by debbugs.gnu.org; 8 Jul 2021 12:44:58 +0000 Received: from localhost ([127.0.0.1]:54601 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1TOk-0005pF-9q for submit@debbugs.gnu.org; Thu, 08 Jul 2021 08:44:58 -0400 Received: from quimby.gnus.org ([95.216.78.240]:34558) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1TOj-0005p3-4D for 49261@debbugs.gnu.org; Thu, 08 Jul 2021 08:44:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=k7bueFfDf6tA83Ltb1yhPSnONsoKq5K0tfjbnA3wUpc=; b=nxsoLGHXC1tFKcGL1qYnHi5rsP bE1qyCAicpzJJVIfut1c5gR3v8a7Lgt1CTy+wTYGKR7SW0AW0BQWcVbXq3jjxTrDELJMWM2OsaVkJ J2bacguaISowLUMb1HZ3qBt0c+WD2Lstc1TwD7FjbCpJ9kXf9Tl35oth+l9EGRQk0MZI=; Received: from cm-84.212.220.105.getinternet.no ([84.212.220.105] helo=elva) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m1TOJ-0002b6-Gt; Thu, 08 Jul 2021 14:44:40 +0200 From: Lars Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: <87o8bn7bie.fsf@gnus.org> <87zgv6vuon.fsf@gmx.de> <837di9lwbm.fsf@gnu.org> <87a6n5vuu4.fsf@gnus.org> <8735sqnmei.fsf@gnus.org> <87zguyf4ht.fsf@gmx.de> <87pmvum54p.fsf@gnus.org> <87v95mf2lj.fsf@gmx.de> <87pmvt3ob1.fsf@gnus.org> <83r1g9evoy.fsf@gnu.org> <83pmvtevgg.fsf@gnu.org> <87czrt3mj4.fsf@gnus.org> <878s2h3m1d.fsf@gnus.org> <874kd53lnl.fsf@gnus.org> <87zgux26ab.fsf@gnus.org> <87pmvt25uq.fsf@gnus.org> <83im1le38o.fsf@gnu.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAElBMVEX6+/i0tq51eoI5 P1tNUmT////HiKSZAAAAAWJLR0QF+G/pxwAAAAd0SU1FB+UHCAwnOXETF2cAAAF+SURBVDjLzZJR lqwgDETB6QVA6wK0YQEPkwUoyf7XNAngCL4z/8NHt4drpSoxxvx3nPmTx3rfHj6/vDHTqn9v5u0B OMlvBGY+B8AcnVkwC2A3AjYWs4lPSeBsXrxKyYdkxiTwEChn7XNHZ/ECo71YSLJSKo9gQmaPCvgB Mse4xdHdHuIiNx+3jCCypRxzxC0oOO42cjjVIzCOsabPruaUd37EmteSKjPxYGKxxpVZ8lBrSheo Crwkr6MCbICxfa+5gVw7FyFsPaCbtGpL9cAQ+efsxaOmyjvdgFRiQfuQKXbJ6KhfcJPVyZ2Ay94Y S4DYlbkBU2mjXGEHAuG7TLYCwAYWRPdqxqokqGBCcBKZClIAQAosaTRRNAByUHcm4F6abLMQQACq AHAFlAIqA9KyyVCqYwGsQN6oYN16IIKiUTC3Unh9jGJ+6io4BW14vHvPJa6AIH1IJdXkt9zoFp8X SMvpfbZpSqIwHfj3JRss4KUdelzU/Ab7VMYl5jZ9A+57jQag6idkAAAAJXRFWHRkYXRlOmNyZWF0 ZQAyMDIxLTA3LTA4VDEyOjM5OjU2KzAwOjAwkQ00ngAAACV0RVh0ZGF0ZTptb2RpZnkAMjAyMS0w Ny0wOFQxMjozOTo1NiswMDowMOBQjCIAAAAASUVORK5CYII= X-Now-Playing: Oval's _Scis_: "Piqqo" Date: Thu, 08 Jul 2021 14:44:31 +0200 In-Reply-To: <83im1le38o.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 08 Jul 2021 09:20:07 +0300") Message-ID: <871r89ug9c.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Eli Zaretskii writes: > To make sure this is indeed segfaults for that commit, I suggest to > clone the upstream repository into a separate directory and repeat the > experiment there. There could be some left-overs of new [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49261 Cc: michael.albinus@gmx.de, ncaprisunfan@gmail.com, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: > To make sure this is indeed segfaults for that commit, I suggest to > clone the upstream repository into a separate directory and repeat the > experiment there. There could be some left-overs of newer builds that > are not deleted/remade by a rebuild in a tree that is not 100% clean. I'm doing a "git clean -xf" between each build, which should remove everything that's not from upstream, I think? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 08 08:49:35 2021 Received: (at 49261) by debbugs.gnu.org; 8 Jul 2021 12:49:35 +0000 Received: from localhost ([127.0.0.1]:54609 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1TTD-00087i-C7 for submit@debbugs.gnu.org; Thu, 08 Jul 2021 08:49:35 -0400 Received: from quimby.gnus.org ([95.216.78.240]:34580) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1TTB-00087U-0u for 49261@debbugs.gnu.org; Thu, 08 Jul 2021 08:49:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=VFm+/gmONiPf7JgjnsoRcWv5UoZl9PfNae0woBsbt6s=; b=eFLL928mVoIN4RLJwpgB5tpTFr u1rXu3lh8hinubVJ23fm53AFtDodqZDj+1co0zyo5pWSXhBa9SMO9Xnyywr3nevwLPGL6E/wb8/7j dN1du60DlEyjCqwilO4hcaUrG46Dt9hiiMFhWwQb1DB0IMZh3R11CwcwgBJ2Euly0Mag=; Received: from cm-84.212.220.105.getinternet.no ([84.212.220.105] helo=elva) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m1TSk-0002cx-WB; Thu, 08 Jul 2021 14:49:16 +0200 From: Lars Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: <87o8bn7bie.fsf@gnus.org> <87zgv6vuon.fsf@gmx.de> <837di9lwbm.fsf@gnu.org> <87a6n5vuu4.fsf@gnus.org> <8735sqnmei.fsf@gnus.org> <87zguyf4ht.fsf@gmx.de> <87pmvum54p.fsf@gnus.org> <87v95mf2lj.fsf@gmx.de> <87pmvt3ob1.fsf@gnus.org> <83r1g9evoy.fsf@gnu.org> <83pmvtevgg.fsf@gnu.org> <87czrt3mj4.fsf@gnus.org> <878s2h3m1d.fsf@gnus.org> <874kd53lnl.fsf@gnus.org> <87zgux26ab.fsf@gnus.org> <83k0m1e3dg.fsf@gnu.org> <875yxlugcb.fsf@gnus.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAG1BMVEXJm3HPoXfVpYSv NSA/GRnMiVTyYiTvhU3///+jJ7KTAAAAAWJLR0QIht6VegAAAAd0SU1FB+UHCAwvOiDDzNUAAAG3 SURBVDjLdZJBUgIxEEXThbruUTyAegGsDHErTthDybi2KtLeYLy+vzvJzCCSAorql9//Jx1H7Fwz LW4ax1pAlWrx9qFp9w51fMjhw1olpkV/iK+P2KtMF2cNR1tr7W2ktrrKIO5t7wyUetygpv3wo/58 j5oXSXFbHMhZSDpYXeQrsuOZB6y7IPIjUiK7fD6CtQ/yDfC1QapGBTQB+R4M2MnHsNbqR9IW+5sx bQWDATpReO2VQnp1k4IBus4jr/dpo7vHVktVQILvs9NZlFb8FLvYAbSLsNcbr/PQuDErZJUP2ORx HKLvzF1kzTaoAq50fwoyiBzZrpfMhRcAkl4GHP0TNSru7O4UeA0MkK/dpuHutVXbhWEG1AIAYU1Q gR2DkAqhcqzdXKFz8pkUAQDjBpZxa0AmYKGojcusOO2Eib/VXt7NFcv4biBIWldAZMeLWRH8aqZg 4gq8H71J5/huj/PEwvLe4P2Veqjlzveu/8CTLZ1GCymrLWB3DqyezkC9w+ME9CHDI1/VHIiBFu6z YeRWgxg6B8XFxnf8AzA5H+3f7kxR1+4SKEf5B6wvAJH++gKQvu9/AWtJzJE2a+JlAAAAJXRFWHRk YXRlOmNyZWF0ZQAyMDIxLTA3LTA4VDEyOjQ3OjU4KzAwOjAw9sBq8wAAACV0RVh0ZGF0ZTptb2Rp ZnkAMjAyMS0wNy0wOFQxMjo0Nzo1OCswMDowMIed0k8AAAAASUVORK5CYII= X-Now-Playing: FKA Twigs's _Magdalene_: "Thousand Eyes" Date: Thu, 08 Jul 2021 14:49:01 +0200 In-Reply-To: <875yxlugcb.fsf@gnus.org> (Lars Ingebrigtsen's message of "Thu, 08 Jul 2021 14:42:44 +0200") Message-ID: <87wnq1t1he.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Lars Ingebrigtsen writes: > This is with an -O2 build; the bug also reproduces with an -O1 build; > I'll try that... Here's the -O1 backtrace: Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49261 Cc: michael.albinus@gmx.de, ncaprisunfan@gmail.com, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Lars Ingebrigtsen writes: > This is with an -O2 build; the bug also reproduces with an -O1 build; > I'll try that... Here's the -O1 backtrace: Thread 1 "bootstrap-emacs" received signal SIGSEGV, Segmentation fault. 0x00005555556f0549 in AREF (idx=6988131860, array=XIL(0x7ffff1bd901d)) at lisp.h:731 731 return lisp_h_XLP (o); (gdb) bt #0 0x00005555556f0549 in AREF (idx=6988131860, array=XIL(0x7ffff1bd901d)) at lisp.h:731 #1 HASH_KEY (idx=3494065930, h=0x7ffff1bd8f98) at lisp.h:2374 #2 hash_lookup (h=0x7ffff1bd8f98, key=XIL(0x555555c76c64), hash=hash@entry=0x0) at fns.c:4479 #3 0x0000555555719cb9 in exec_byte_code (bytestr=, vector=, maxdepth=, args_template=args_template@entry=make_fixnum(257), nargs=nargs@entry=1, args=, args@entry=0x7fffffffd940) at bytecode.c:1415 #4 0x00005555556e643f in fetch_and_exec_byte_code (args=0x7fffffffd940, nargs=1, syms_left=make_fixnum(257), fun=XIL(0x7ffff1bc9895)) at lisp.h:731 #5 funcall_lambda (fun=XIL(0x7ffff1bc9895), nargs=nargs@entry=1, arg_vector=arg_vector@entry=0x7fffffffd940) at eval.c:3244 #6 0x00005555556e3bb4 in Ffuncall (nargs=2, args=args@entry=0x7fffffffd938) at eval.c:3043 #7 0x0000555555717cb6 in exec_byte_code (bytestr=, vector=, maxdepth=, args_template=args_template@entry=make_fixnum(0), nargs=nargs@entry=0, args=, args@entry=0x7fffffffe0e8) at bytecode.c:632 #8 0x00005555556e643f in fetch_and_exec_byte_code (args=0x7fffffffe0e8, nargs=0, syms_left=make_fixnum(0), fun=XIL(0x7ffff1bc79ed)) at lisp.h:731 #9 funcall_lambda (fun=XIL(0x7ffff1bc79ed), nargs=nargs@entry=0, arg_vector=arg_vector@entry=0x7fffffffe0e8) at eval.c:3244 #10 0x00005555556e3bb4 in Ffuncall (nargs=1, args=args@entry=0x7fffffffe0e0) at eval.c:3043 #11 0x0000555555717cb6 in exec_byte_code (bytestr=, vector=, maxdepth=, args_template=args_template@entry=make_fixnum(0), nargs=nargs@entry=0, args=, args@entry=0x7fffffffe4a0) at bytecode.c:632 #12 0x00005555556e643f in fetch_and_exec_byte_code (args=0x7fffffffe4a0, nargs=0, syms_left=make_fixnum(0), fun=XIL(0x7ffff1bc759d)) at lisp.h:731 #13 funcall_lambda (fun=fun@entry=XIL(0x7ffff1bc759d), nargs=nargs@entry=0, arg_vector=arg_vector@entry=0x7fffffffe4a0) at eval.c:3244 #14 0x00005555556e5aec in apply_lambda (fun=fun@entry=XIL(0x7ffff1bc759d), args=, count=count@entry=4) at eval.c:3188 #15 0x00005555556e5d64 in eval_sub (form=form@entry=XIL(0x7ffff20f4fe3)) at eval.c:2561 #16 0x00005555556e76d7 in Feval --Type for more, q to quit, c to continue without paging-- (form=XIL(0x7ffff20f4fe3), lexical=lexical@entry=XIL(0)) at eval.c:2343 #17 0x0000555555670a48 in top_level_2 () at lisp.h:1002 #18 0x00005555556e2f8d in internal_condition_case (bfun=bfun@entry=0x555555670a33 , handlers=handlers@entry=XIL(0x90), hfun=hfun@entry=0x555555673df4 ) at eval.c:1478 #19 0x0000555555670a03 in top_level_1 (ignore=ignore@entry=XIL(0)) at keyboard.c:1111 #20 0x00005555556e5158 in internal_catch (tag=tag@entry=XIL(0xe610), func=func@entry=0x5555556709dd , arg=arg@entry=XIL(0)) at eval.c:1198 #21 0x0000555555670986 in command_loop () at lisp.h:1002 #22 0x0000555555673a9c in recursive_edit_1 () at keyboard.c:720 #23 0x0000555555673d4d in Frecursive_edit () at keyboard.c:789 #24 0x000055555566fea2 in main (argc=13, argv=0x7fffffffe8b8) at emacs.c:2308 Lisp Backtrace: "command-line-1" (0xffffd940) "command-line" (0xffffe0e8) "normal-top-level" (0xffffe4a0) (gdb) fr 16 #16 0x00005555556e76d7 in Feval (form=XIL(0x7ffff20f4fe3), lexical=lexical@entry=XIL(0)) at eval.c:2343 2343 return unbind_to (count, eval_sub (form)); (gdb) pp form # (gdb) Same invalid object. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 08 08:52:01 2021 Received: (at 49261) by debbugs.gnu.org; 8 Jul 2021 12:52:01 +0000 Received: from localhost ([127.0.0.1]:54627 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1TVZ-0008C9-Cq for submit@debbugs.gnu.org; Thu, 08 Jul 2021 08:52:01 -0400 Received: from quimby.gnus.org ([95.216.78.240]:34602) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1TVY-0008Bu-0b for 49261@debbugs.gnu.org; Thu, 08 Jul 2021 08:52:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=9Hu9G3TJ3cvExQVEJUicl2jIq/UbprBBPju9GXpkJro=; b=n1P1RkBJ+BefH8JrfEUrhoIq2j MEqdEBWXUIr73dS4K9W55ziUm406Lk7UsqsGXq1te0S/t84SwnRMZrTRFvwxRbdSa9fN3zXuRyXJg 8eEAEOx1tc/ZX1O5J27QSrgTl5xp6xBQNi9JXeIrAjX4lRWYE8UIYVK0OoR2pjfxjfGQ=; Received: from cm-84.212.220.105.getinternet.no ([84.212.220.105] helo=elva) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m1TVE-0002gN-At; Thu, 08 Jul 2021 14:51:42 +0200 From: Lars Ingebrigtsen To: Eli Zaretskii Subject: Re: Segfault during loadup References: <87o8bn7bie.fsf@gnus.org> <87zgv6vuon.fsf@gmx.de> <837di9lwbm.fsf@gnu.org> <87a6n5vuu4.fsf@gnus.org> <8735sqnmei.fsf@gnus.org> <87zguyf4ht.fsf@gmx.de> <87pmvum54p.fsf@gnus.org> <87v95mf2lj.fsf@gmx.de> <87pmvt3ob1.fsf@gnus.org> <83r1g9evoy.fsf@gnu.org> <83pmvtevgg.fsf@gnu.org> <87czrt3mj4.fsf@gnus.org> <878s2h3m1d.fsf@gnus.org> <874kd53lnl.fsf@gnus.org> <87zgux26ab.fsf@gnus.org> <87pmvt25uq.fsf@gnus.org> <87lf6h2294.fsf@gnus.org> <87h7h51x9y.fsf_-_@gnus.org> <83eec9e2js.fsf@gnu.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAG1BMVEXJm3HPoXfVpYSv NSA/GRnMiVTyYiTvhU3///+jJ7KTAAAAAWJLR0QIht6VegAAAAd0SU1FB+UHCAwvOiDDzNUAAAG3 SURBVDjLdZJBUgIxEEXThbruUTyAegGsDHErTthDybi2KtLeYLy+vzvJzCCSAorql9//Jx1H7Fwz LW4ax1pAlWrx9qFp9w51fMjhw1olpkV/iK+P2KtMF2cNR1tr7W2ktrrKIO5t7wyUetygpv3wo/58 j5oXSXFbHMhZSDpYXeQrsuOZB6y7IPIjUiK7fD6CtQ/yDfC1QapGBTQB+R4M2MnHsNbqR9IW+5sx bQWDATpReO2VQnp1k4IBus4jr/dpo7vHVktVQILvs9NZlFb8FLvYAbSLsNcbr/PQuDErZJUP2ORx HKLvzF1kzTaoAq50fwoyiBzZrpfMhRcAkl4GHP0TNSru7O4UeA0MkK/dpuHutVXbhWEG1AIAYU1Q gR2DkAqhcqzdXKFz8pkUAQDjBpZxa0AmYKGojcusOO2Eib/VXt7NFcv4biBIWldAZMeLWRH8aqZg 4gq8H71J5/huj/PEwvLe4P2Veqjlzveu/8CTLZ1GCymrLWB3DqyezkC9w+ME9CHDI1/VHIiBFu6z YeRWgxg6B8XFxnf8AzA5H+3f7kxR1+4SKEf5B6wvAJH++gKQvu9/AWtJzJE2a+JlAAAAJXRFWHRk YXRlOmNyZWF0ZQAyMDIxLTA3LTA4VDEyOjQ3OjU4KzAwOjAw9sBq8wAAACV0RVh0ZGF0ZTptb2Rp ZnkAMjAyMS0wNy0wOFQxMjo0Nzo1OCswMDowMIed0k8AAAAASUVORK5CYII= X-Now-Playing: FKA Twigs's _Magdalene_: "Home With You" Date: Thu, 08 Jul 2021 14:51:39 +0200 In-Reply-To: <83eec9e2js.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 08 Jul 2021 09:35:03 +0300") Message-ID: <87sg0pt1d0.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Eli Zaretskii writes: > So the last paragraph above is incorrect, and "the previous commit" is > not broken? Then what about the information in > > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=43152#65 > https://debbugs.g [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49261 Cc: eggert@cs.ucla.edu, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: > So the last paragraph above is incorrect, and "the previous commit" is > not broken? Then what about the information in > > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=43152#65 > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=43152#68 > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=43152#71 > > And the rest of the discussion about verify.h being the culprit? Hm... is that for Macos only, though? I'm currently doing the testing on Linux (Debian and Fedora, which both displays the same behaviour). -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 08 09:11:50 2021 Received: (at 49261) by debbugs.gnu.org; 8 Jul 2021 13:11:51 +0000 Received: from localhost ([127.0.0.1]:54664 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1Tok-0000H0-JY for submit@debbugs.gnu.org; Thu, 08 Jul 2021 09:11:50 -0400 Received: from quimby.gnus.org ([95.216.78.240]:34750) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1Toh-0000Gj-If for 49261@debbugs.gnu.org; Thu, 08 Jul 2021 09:11:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=C5GmpO5//W/iCOskbz840VobitgchypBze7YYF2h9Tg=; b=FXTvTx58hpWgHblXBnnn9RpBAi E4DrxfWzGfoQC8h6gFFJr0rB3Y3QC8XOrFK/q/JW1qh8ww+JNL3J9BWhlicLBZJ/TIycIzvuZSX1a 6iFiZWy+G4Ijp8obI9TgxJAainAdwC74riPTQlmxIkKsW1PW3+jF/rOwHkyg5ngZtD0I=; Received: from cm-84.212.220.105.getinternet.no ([84.212.220.105] helo=elva) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m1ToO-0002sm-4u; Thu, 08 Jul 2021 15:11:35 +0200 From: Lars Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: <87o8bn7bie.fsf@gnus.org> <87zgv6vuon.fsf@gmx.de> <837di9lwbm.fsf@gnu.org> <87a6n5vuu4.fsf@gnus.org> <8735sqnmei.fsf@gnus.org> <87zguyf4ht.fsf@gmx.de> <87pmvum54p.fsf@gnus.org> <87v95mf2lj.fsf@gmx.de> <87pmvt3ob1.fsf@gnus.org> <83r1g9evoy.fsf@gnu.org> <83pmvtevgg.fsf@gnu.org> <87czrt3mj4.fsf@gnus.org> <878s2h3m1d.fsf@gnus.org> <874kd53lnl.fsf@gnus.org> <87zgux26ab.fsf@gnus.org> <87pmvt25uq.fsf@gnus.org> <83im1le38o.fsf@gnu.org> <871r89ug9c.fsf@gnus.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAG1BMVEXJm3HPoXfVpYSv NSA/GRnMiVTyYiTvhU3///+jJ7KTAAAAAWJLR0QIht6VegAAAAd0SU1FB+UHCAwvOiDDzNUAAAG3 SURBVDjLdZJBUgIxEEXThbruUTyAegGsDHErTthDybi2KtLeYLy+vzvJzCCSAorql9//Jx1H7Fwz LW4ax1pAlWrx9qFp9w51fMjhw1olpkV/iK+P2KtMF2cNR1tr7W2ktrrKIO5t7wyUetygpv3wo/58 j5oXSXFbHMhZSDpYXeQrsuOZB6y7IPIjUiK7fD6CtQ/yDfC1QapGBTQB+R4M2MnHsNbqR9IW+5sx bQWDATpReO2VQnp1k4IBus4jr/dpo7vHVktVQILvs9NZlFb8FLvYAbSLsNcbr/PQuDErZJUP2ORx HKLvzF1kzTaoAq50fwoyiBzZrpfMhRcAkl4GHP0TNSru7O4UeA0MkK/dpuHutVXbhWEG1AIAYU1Q gR2DkAqhcqzdXKFz8pkUAQDjBpZxa0AmYKGojcusOO2Eib/VXt7NFcv4biBIWldAZMeLWRH8aqZg 4gq8H71J5/huj/PEwvLe4P2Veqjlzveu/8CTLZ1GCymrLWB3DqyezkC9w+ME9CHDI1/VHIiBFu6z YeRWgxg6B8XFxnf8AzA5H+3f7kxR1+4SKEf5B6wvAJH++gKQvu9/AWtJzJE2a+JlAAAAJXRFWHRk YXRlOmNyZWF0ZQAyMDIxLTA3LTA4VDEyOjQ3OjU4KzAwOjAw9sBq8wAAACV0RVh0ZGF0ZTptb2Rp ZnkAMjAyMS0wNy0wOFQxMjo0Nzo1OCswMDowMIed0k8AAAAASUVORK5CYII= X-Now-Playing: FKA Twigs's _Magdalene_: "Fallen Alien" Date: Thu, 08 Jul 2021 15:11:26 +0200 In-Reply-To: <871r89ug9c.fsf@gnus.org> (Lars Ingebrigtsen's message of "Thu, 08 Jul 2021 14:44:31 +0200") Message-ID: <87k0m1t0g1.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Lars Ingebrigtsen writes: > I'm doing a "git clean -xf" between each build, which should remove > everything that's not from upstream, I think? Just to ensure that there's nothing there, I did: Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49261 Cc: michael.albinus@gmx.de, ncaprisunfan@gmail.com, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Lars Ingebrigtsen writes: > I'm doing a "git clean -xf" between each build, which should remove > everything that's not from upstream, I think? Just to ensure that there's nothing there, I did: git clone git://git.savannah.gnu.org/emacs.git cd emacs git checkout 6cf62141c4467314f67c2ef75a4bf94d41ff050f sh autogen.sh; ./configure; make -j16; touch lisp/*.el; make This segfaults for me reliably on Debian and Fedora. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 08 09:13:51 2021 Received: (at 49261) by debbugs.gnu.org; 8 Jul 2021 13:13:51 +0000 Received: from localhost ([127.0.0.1]:54668 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1Tqh-0000Jt-3R for submit@debbugs.gnu.org; Thu, 08 Jul 2021 09:13:51 -0400 Received: from eggs.gnu.org ([209.51.188.92]:50254) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1Tqe-0000Jg-W2 for 49261@debbugs.gnu.org; Thu, 08 Jul 2021 09:13:49 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:37108) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m1TqZ-0000ss-Pn; Thu, 08 Jul 2021 09:13:43 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:4089 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m1TqU-00036z-UM; Thu, 08 Jul 2021 09:13:41 -0400 Date: Thu, 08 Jul 2021 16:13:30 +0300 Message-Id: <834kd5dk3p.fsf@gnu.org> From: Eli Zaretskii To: Lars Ingebrigtsen In-Reply-To: <871r89ug9c.fsf@gnus.org> (message from Lars Ingebrigtsen on Thu, 08 Jul 2021 14:44:31 +0200) Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: <87o8bn7bie.fsf@gnus.org> <87zgv6vuon.fsf@gmx.de> <837di9lwbm.fsf@gnu.org> <87a6n5vuu4.fsf@gnus.org> <8735sqnmei.fsf@gnus.org> <87zguyf4ht.fsf@gmx.de> <87pmvum54p.fsf@gnus.org> <87v95mf2lj.fsf@gmx.de> <87pmvt3ob1.fsf@gnus.org> <83r1g9evoy.fsf@gnu.org> <83pmvtevgg.fsf@gnu.org> <87czrt3mj4.fsf@gnus.org> <878s2h3m1d.fsf@gnus.org> <874kd53lnl.fsf@gnus.org> <87zgux26ab.fsf@gnus.org> <87pmvt25uq.fsf@gnus.org> <83im1le38o.fsf@gnu.org> <871r89ug9c.fsf@gnus.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49261 Cc: michael.albinus@gmx.de, ncaprisunfan@gmail.com, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Lars Ingebrigtsen > Cc: michael.albinus@gmx.de, ncaprisunfan@gmail.com, 49261@debbugs.gnu.org > Date: Thu, 08 Jul 2021 14:44:31 +0200 > > Eli Zaretskii writes: > > > To make sure this is indeed segfaults for that commit, I suggest to > > clone the upstream repository into a separate directory and repeat the > > experiment there. There could be some left-overs of newer builds that > > are not deleted/remade by a rebuild in a tree that is not 100% clean. > > I'm doing a "git clean -xf" between each build, which should remove > everything that's not from upstream, I think? Theoretically, yes. From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 08 09:17:06 2021 Received: (at 49261) by debbugs.gnu.org; 8 Jul 2021 13:17:06 +0000 Received: from localhost ([127.0.0.1]:54673 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1Ttq-0000Pb-JE for submit@debbugs.gnu.org; Thu, 08 Jul 2021 09:17:06 -0400 Received: from eggs.gnu.org ([209.51.188.92]:51144) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1Tto-0000P1-Fm for 49261@debbugs.gnu.org; Thu, 08 Jul 2021 09:17:05 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:37186) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m1Tth-0001nt-Lx; Thu, 08 Jul 2021 09:16:57 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:4292 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m1Tth-0003Uc-9T; Thu, 08 Jul 2021 09:16:57 -0400 Date: Thu, 08 Jul 2021 16:16:50 +0300 Message-Id: <8335spdjy5.fsf@gnu.org> From: Eli Zaretskii To: Lars Ingebrigtsen In-Reply-To: <875yxlugcb.fsf@gnus.org> (message from Lars Ingebrigtsen on Thu, 08 Jul 2021 14:42:44 +0200) Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: <87o8bn7bie.fsf@gnus.org> <87zgv6vuon.fsf@gmx.de> <837di9lwbm.fsf@gnu.org> <87a6n5vuu4.fsf@gnus.org> <8735sqnmei.fsf@gnus.org> <87zguyf4ht.fsf@gmx.de> <87pmvum54p.fsf@gnus.org> <87v95mf2lj.fsf@gmx.de> <87pmvt3ob1.fsf@gnus.org> <83r1g9evoy.fsf@gnu.org> <83pmvtevgg.fsf@gnu.org> <87czrt3mj4.fsf@gnus.org> <878s2h3m1d.fsf@gnus.org> <874kd53lnl.fsf@gnus.org> <87zgux26ab.fsf@gnus.org> <83k0m1e3dg.fsf@gnu.org> <875yxlugcb.fsf@gnus.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49261 Cc: michael.albinus@gmx.de, ncaprisunfan@gmail.com, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Lars Ingebrigtsen > Cc: michael.albinus@gmx.de, ncaprisunfan@gmail.com, 49261@debbugs.gnu.org > Date: Thu, 08 Jul 2021 14:42:44 +0200 > > Eli Zaretskii writes: > > > Can you show the form being evaluated in frame #10? Like this: > > > > (gdb) fr 10 > > (gdb) pp form > > Hm: > > (gdb) fr 10 > #10 0x0000555555706a59 in Feval (form=XIL(0x7ffff20f5023), > lexical=) at eval.c:2343 > 2343 return unbind_to (count, eval_sub (form)); > (gdb) pp form > # Which means unfortunately that to see the form one needs to display the form piecemeal, one member at a time, using the xtype and the other x* commands... Let me know if you need more detailed instructions. From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 08 09:35:30 2021 Received: (at 49261) by debbugs.gnu.org; 8 Jul 2021 13:35:30 +0000 Received: from localhost ([127.0.0.1]:54698 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1UBd-00031h-PT for submit@debbugs.gnu.org; Thu, 08 Jul 2021 09:35:30 -0400 Received: from quimby.gnus.org ([95.216.78.240]:34990) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1UBb-00031T-At for 49261@debbugs.gnu.org; Thu, 08 Jul 2021 09:35:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=rEuM3lSY8TFuwwNLxvQP7IhCuUmc+1RjXYBu0J3FJZ4=; b=cvtBoJeceK1GY4Tw+vJgdjmfgd mtLPH73OJOR+BUV6sotDOpmAA6gjjC+suwiFZBb7YWQ2hxykgkDOwavoRCOabAI39yMh5d85b5J1o Ag1wr3sCdAT+RlpHfkYmXmaETO84PjGrZq91fD3G8UsM79o7TOPkTuKzTye3Mk09+uCE=; Received: from cm-84.212.220.105.getinternet.no ([84.212.220.105] helo=elva) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m1UBF-00036s-Fn; Thu, 08 Jul 2021 15:35:15 +0200 From: Lars Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: <87o8bn7bie.fsf@gnus.org> <87zgv6vuon.fsf@gmx.de> <837di9lwbm.fsf@gnu.org> <87a6n5vuu4.fsf@gnus.org> <8735sqnmei.fsf@gnus.org> <87zguyf4ht.fsf@gmx.de> <87pmvum54p.fsf@gnus.org> <87v95mf2lj.fsf@gmx.de> <87pmvt3ob1.fsf@gnus.org> <83r1g9evoy.fsf@gnu.org> <83pmvtevgg.fsf@gnu.org> <87czrt3mj4.fsf@gnus.org> <878s2h3m1d.fsf@gnus.org> <874kd53lnl.fsf@gnus.org> <87zgux26ab.fsf@gnus.org> <83k0m1e3dg.fsf@gnu.org> <875yxlugcb.fsf@gnus.org> <8335spdjy5.fsf@gnu.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAElBMVEWpnHDoplpRa5Cu WFQ+X5P///8JUYfnAAAAAWJLR0QF+G/pxwAAAAd0SU1FB+UHCA0eK43sgaIAAAGaSURBVDjLbVSJ jcQgDLRzKcBeGtiFbYDQAIrSf03nBwM6XfYR8TAzxoABUD7AAISIQHzImOUFAJllKF9CRvmB/wMd +Z/nLbgAxV6+ueU7EAZcjNbaFWMCPGNcBGiLwedGWAABnZNw5aV1LCkFyqTwAkSnXJOyecjksrSW h6qoSQsANiD3NIA3TKnW6nHhBBajNaZ34gWMrESJq9Q53DkYpVUFahoAhYcAFl/AlJIo8wRwARI2 k/AIqZqUwdWBPtMtOlvVUjBCSuNKcUBWPoHKjSXnAUzzjJKQlCXVyCpqdWudZPn8xzzfd7FTAnkA vh9fOUW3AY9Pg2Aw2/G5nnHkJpCYQM0BAnDzbstQb7ZAD4YBtozKr938Y6GkZUyvnfGx+llRKt3b nn9s+9gfk3apL46old6lcACWVrUSn5vHjwrVQRP3jiOroZ6S2ot7H4ehJ98lSyDtAE8dnWAeVgHf 8dSc1tbKi1eJR8Wuma5fTAv6nV6HwS+zh5/nVqnVAOI5dJu064CLS4baZ9jajnQfGihJXyKyLnXI 6BdI3oDAnJ6ZBQAAACV0RVh0ZGF0ZTpjcmVhdGUAMjAyMS0wNy0wOFQxMzozMDo0MyswMDowMC4c 6egAAAAldEVYdGRhdGU6bW9kaWZ5ADIwMjEtMDctMDhUMTM6MzA6NDMrMDA6MDBfQVFUAAAAAElF TkSuQmCC X-Now-Playing: Yorkston, Thorne, Khan's _Navarasa: Nine Emotions_: "Sukhe Phool" Date: Thu, 08 Jul 2021 15:34:54 +0200 In-Reply-To: <8335spdjy5.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 08 Jul 2021 16:16:50 +0300") Message-ID: <878s2hszcx.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Eli Zaretskii writes: > Which means unfortunately that to see the form one needs to display > the form piecemeal, one member at a time, using the xtype and the > other x* commands... Let me know if you need more detailed > [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49261 Cc: michael.albinus@gmx.de, ncaprisunfan@gmail.com, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: > Which means unfortunately that to see the form one needs to display > the form piecemeal, one member at a time, using the xtype and the > other x* commands... Let me know if you need more detailed > instructions. Yes, that'd be appreciated. (gdb) print form $1 = XIL(0x7ffff211c263) (gdb) pr form # (gdb) xtype form Lisp_Cons (gdb) xcons form $2 = (struct Lisp_Cons *) 0x7ffff211c260 { u = { s = { car = XIL(0x2aaa9c41a9e0), u = { cdr = XIL(0), chain = 0x0 } }, gcaligned = 0xe0 } } (gdb) xcar form $3 = 0x0 (gdb) xcdr form $4 = 0x0 Which doesn't seem ... right? Anyway, the build failures (on the old commit) aren't 100% reproducible now. When running the bootstrap under gdb, it now currently just hangs, so I have to C-c to get the backtrace. It does hang (always) at the same place (see below). So I'm still guessing that there's memory corruption introduced by the patch, so actually looking at the backtrace may not be very productive... Reloading stale subdirs.el Loading /tmp/emacs/lisp/subdirs.el (source)... ^C Thread 1 "bootstrap-emacs" hit Breakpoint 1, terminate_due_to_signal ( sig=sig@entry=2, backtrace_limit=backtrace_limit@entry=40) at emacs.c:378 378 signal (sig, SIG_DFL); (gdb) bt #0 terminate_due_to_signal (sig=sig@entry=2, backtrace_limit=backtrace_limit@entry=40) at emacs.c:378 #1 0x0000555555599698 in handle_fatal_signal (sig=sig@entry=2) at sysdep.c:1768 #2 0x00005555555996ae in deliver_process_signal (handler=0x55555559968d , sig=2) at sysdep.c:1726 #3 deliver_fatal_signal (sig=2) at sysdep.c:1774 #4 0x00007ffff59e3140 in () at /lib/x86_64-linux-gnu/libpthread.so.0 #5 hash_lookup (h=0x7ffff1fbe518, key=XIL(0x555555c54b94), hash=hash@entry=0x0) at lisp.h:718 #6 0x00005555557392a2 in exec_byte_code (bytestr=, vector=, maxdepth=, args_template=, nargs=, args=) at bytecode.c:1415 #7 0x00005555556fdeb7 in Ffuncall (nargs=2, args=args@entry=0x7fffffffd6b8) at eval.c:2809 #8 0x0000555555736a78 in exec_byte_code (bytestr=, vector=, maxdepth=, args_template=, nargs=, args=) at bytecode.c:632 #9 0x00005555556fdeb7 in Ffuncall (nargs=1, args=args@entry=0x7fffffffe040) --Type for more, q to quit, c to continue without paging-- at eval.c:2809 #10 0x0000555555736a78 in exec_byte_code (bytestr=, vector=, maxdepth=, args_template=, nargs=, args=) at bytecode.c:632 #11 0x0000555555700e7f in apply_lambda (fun=XIL(0x7ffff1fc26f5), args=, count=4) at eval.c:2942 #12 0x00005555556fff03 in eval_sub (form=) at eval.c:2349 #13 0x0000555555701a29 in Feval (form=XIL(0x7ffff211c263), lexical=) at eval.c:2103 -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 08 12:47:32 2021 Received: (at 49261) by debbugs.gnu.org; 8 Jul 2021 16:47:32 +0000 Received: from localhost ([127.0.0.1]:57354 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1XBU-0006z0-Ak for submit@debbugs.gnu.org; Thu, 08 Jul 2021 12:47:32 -0400 Received: from eggs.gnu.org ([209.51.188.92]:46192) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1XBR-0006sR-DM for 49261@debbugs.gnu.org; Thu, 08 Jul 2021 12:47:31 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:43844) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m1XBL-00028C-SQ; Thu, 08 Jul 2021 12:47:23 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:1282 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m1XBK-00025Q-VX; Thu, 08 Jul 2021 12:47:23 -0400 Date: Thu, 08 Jul 2021 19:47:10 +0300 Message-Id: <83y2agda7l.fsf@gnu.org> From: Eli Zaretskii To: Lars Ingebrigtsen In-Reply-To: <878s2hszcx.fsf@gnus.org> (message from Lars Ingebrigtsen on Thu, 08 Jul 2021 15:34:54 +0200) Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: <87o8bn7bie.fsf@gnus.org> <87zgv6vuon.fsf@gmx.de> <837di9lwbm.fsf@gnu.org> <87a6n5vuu4.fsf@gnus.org> <8735sqnmei.fsf@gnus.org> <87zguyf4ht.fsf@gmx.de> <87pmvum54p.fsf@gnus.org> <87v95mf2lj.fsf@gmx.de> <87pmvt3ob1.fsf@gnus.org> <83r1g9evoy.fsf@gnu.org> <83pmvtevgg.fsf@gnu.org> <87czrt3mj4.fsf@gnus.org> <878s2h3m1d.fsf@gnus.org> <874kd53lnl.fsf@gnus.org> <87zgux26ab.fsf@gnus.org> <83k0m1e3dg.fsf@gnu.org> <875yxlugcb.fsf@gnus.org> <8335spdjy5.fsf@gnu.org> <878s2hszcx.fsf@gnus.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49261 Cc: michael.albinus@gmx.de, ncaprisunfan@gmail.com, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Lars Ingebrigtsen > Cc: michael.albinus@gmx.de, ncaprisunfan@gmail.com, 49261@debbugs.gnu.org > Date: Thu, 08 Jul 2021 15:34:54 +0200 > > Eli Zaretskii writes: > > > Which means unfortunately that to see the form one needs to display > > the form piecemeal, one member at a time, using the xtype and the > > other x* commands... Let me know if you need more detailed > > instructions. > > Yes, that'd be appreciated. Well, you did it (almost) correctly: > (gdb) xtype form > Lisp_Cons > (gdb) xcons form > $2 = (struct Lisp_Cons *) 0x7ffff211c260 > { > u = { > s = { > car = XIL(0x2aaa9c41a9e0), > u = { > cdr = XIL(0), > chain = 0x0 > } > }, > gcaligned = 0xe0 > } > } > (gdb) xcar form > $3 = 0x0 > (gdb) xcdr form > $4 = 0x0 What you need to do is this: (gdb) xtype Lisp_Cons (gdb) xcons $2 = (struct Lisp_Cons *) 0x7ffff211c260 { u = { s = { car = XIL(0x2aaa9c41a9e0), u = { cdr = XIL(0), chain = 0x0 } }, gcaligned = 0xe0 } } (gdb) p $2->u.s.car (gdb) xtype And after the second "xtype" continue with the x* command according to the type. Your mistake was to use an argument after xcons, xcar, and xcdr: these should be invoked without an argument, immediately after printing a Lisp_Object variable. Like this: (gdb) p form (gdb) xcar (gdb) p form (gdb) xcdr etc. > Which doesn't seem ... right? No, but the real form has a non-nil 'car', see above. So that does look valid, at least at this level. The invalid part probably comes when you recurse deeper into 'form'. From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 08 15:53:20 2021 Received: (at 49261) by debbugs.gnu.org; 8 Jul 2021 19:53:20 +0000 Received: from localhost ([127.0.0.1]:57578 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1a5I-0005Sm-89 for submit@debbugs.gnu.org; Thu, 08 Jul 2021 15:53:20 -0400 Received: from mout.gmx.net ([212.227.15.19]:51531) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1a5F-0005SZ-RX for 49261@debbugs.gnu.org; Thu, 08 Jul 2021 15:53:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1625773990; bh=lgrQdt26BeAfkwd5mo76HhNagY6wKsa96wqC4NcA5yM=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=cqQHos9AvWI+q0HgBmnlzIOD7bcO3EtAMDCVGxsmK2xt8QFEtr0zPWjQ4tNRUc1Ql cEUe8lVOuuV0UEVWRmpecreuVABUK2cEL8REfrMFnRrTQgPjFznhFfPQSOGB4jfa57 /eyRe5EFq3JnqOamNmJiw5nraR4NYo3MO2p/4rek= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from gandalf.gmx.de ([213.220.147.36]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1N8ob6-1l4oWO0obu-015pBX; Thu, 08 Jul 2021 21:53:10 +0200 From: Michael Albinus To: Lars Ingebrigtsen Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: <87o8bn7bie.fsf@gnus.org> <87zgv6vuon.fsf@gmx.de> <837di9lwbm.fsf@gnu.org> <87a6n5vuu4.fsf@gnus.org> <8735sqnmei.fsf@gnus.org> <87zguyf4ht.fsf@gmx.de> <87pmvum54p.fsf@gnus.org> <87v95mf2lj.fsf@gmx.de> <87pmvt3ob1.fsf@gnus.org> <87fswpgacv.fsf@gmx.de> <87bl7dfikj.fsf@gmx.de> Date: Thu, 08 Jul 2021 21:53:08 +0200 In-Reply-To: <87bl7dfikj.fsf@gmx.de> (Michael Albinus's message of "Thu, 08 Jul 2021 08:03:40 +0200") Message-ID: <8735sofuqj.fsf@gmx.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:2ghGaPeJNzpPEEA6eN4WoMC96R00pQr+0ciFl4lPvJTp1CyrsjF xD24vNykOT2mPHr+QjD71cvHsW56R0kR7/SS616t5ejkp4qHMX4hPaDYFBMDH2JgM7khgAi 3I3XpcptpnIvnuidxB4LdQ0QiOTmD3L18cGH2oxBBmkP5OZoRcmMYSEWqig09i22Ca9V9G2 hmlE7rB1GFilgZWpxA4Mg== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:uw745TsRLsk=:MpjBrMviWZ+bnNkXSDgCVb KD832lkrzNJ5fo4Sb7/Cd4eX/wAO4TDjMMcX3YwojY3KMjbb0QYXRjbarNR6Fi6rw3Sn9UX27 p0Z9+fBfjuzL8g+kA6pRC5IC7c2GUvP8NDg1ctMW5gGDEbayAcTAbAlJICf1FuRkVXhObYCnT OAe2CLhK9e6tHLqIRy/S0104aYp8OefMGikZlHX88lZxpZfYVowAFz2U7aPoVH8YcvY/VCNZm zVGq0+5zEdxqoFGHzIra6igG1tJxTYZpZDWlsvUmRCIl6HgjIMPERQ8fZE9QCdQ6ANyQjHnCK e8yCc6QwRBzLyykhLAFAqu0wHgfaPPtgPAxOL6TQvV/aIz/+ZEKAgxZvixwNniua4gf4uCdeC svOSNkkykpGPZ50I5vRSsWBKUdwkzsLAqzj0TV6fg0eLjPEnPwEjnq1zeFoREImecSAgwB0sb d0KknUWH6Q2zyZb55iBd8oESebAnrXOeN3zl0BUrPHArIP3VDotMk1Jd13rsgFVCWfPdCTwGe mAOGvRmh4FxVLl90JDjXyooX2G2yxPot5RavsDUcBi20+2tpzIcveJb/PthfRVnyCYowDR/H1 5pxgwH/uXP4Jlby03jgzzG48fDAGpXTsJN0KjQo062aMWLJPpOXP9Ir1z4tyiZ5s0WM7u/cZV iuBEtsNo9L4xyvdMSuoTQ1xZq7AXf3RXrhLqC2NKLoMGtvxjR3MS5yq4xQAEr7rlZ/LpXMLYg bv+879XRAti66+QFAVnh3tsbr72gxLYuSazanVDW6hp7TYg8QaYsRTOECQIg9NiqjgNCaYfbf pE3ZvJrM7OkaeqWiDip00SI+75E67q3QmgbVYwKm69sCvfGuSqPkNwMEtRfBdg1jClQwwqGHD 3MiGZgH4bDxdb8mhTriyn8VsmYj3euD116Z6CO/hZRYDssiY7X5qDhMhM2KLUPGIHyQx21zAx YFtlIC0uZB+xVMfDma+hrF86fUC72uY4aa77ouDxS/ktkvZg1COEyz0iRrE+A4yZiE/Bxlp8v cledlaGQas3lzAu/FNNUiiryv5On+bfrB+3NJI0OR2BqHJkrAEqM9OB5R9QlnL8eo2hCTANeH lpB3OpKxtYZuqntb4j/IQ0Y1cvdHN+UWOwTuvIEIPzjg8n4MySgrYiRxg== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 49261 Cc: Eli Zaretskii , ncaprisunfan@gmail.com, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Michael Albinus writes: Hi Lars, >> I will check tomorrow why these test cases fail, and how to integrate >> the new lock-file-name-transforms into Tramp. > > This remains open for later today, or tomorrow. This is done. ATM, I've decided not to write an own Tramp handler for make-lock-file-name, the default function is good enough. But the infrastructure for such a handler is prepared, when needed. One point I am missing is to suppress lock files, customised by users. There is create-lockfiles, but this is all-or-nothing. One idea we've discussed shortly would be to add a file-lock-mode, similar to the existing auto-save-mode. Would be useful, but it is restricted to the current buffer. Another idea I have is to use the new lock-file-name-transforms user option. It contains entries (REGEXP REPLACEMENT UNIQUIFY) . What if we allow REPLACEMENT to be nil, meaning that there shoudn't be file locks for files matching REGEXP? An entry ("\\`/[^/]*:\\([^/]*/\\)*\\([^/]*\\)\\'") of that variable would suppress file locks for remote files then. A similar meaning could be offered for auto-save-file-name-transforms. Best regards, Michael. From debbugs-submit-bounces@debbugs.gnu.org Fri Jul 09 02:30:47 2021 Received: (at 49261) by debbugs.gnu.org; 9 Jul 2021 06:30:47 +0000 Received: from localhost ([127.0.0.1]:58224 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1k2A-0005n0-Vj for submit@debbugs.gnu.org; Fri, 09 Jul 2021 02:30:47 -0400 Received: from eggs.gnu.org ([209.51.188.92]:48168) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1k28-0005mn-Fi for 49261@debbugs.gnu.org; Fri, 09 Jul 2021 02:30:46 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:37422) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m1k23-0002Qs-1d; Fri, 09 Jul 2021 02:30:39 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3852 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m1k22-0006f7-KL; Fri, 09 Jul 2021 02:30:38 -0400 Date: Fri, 09 Jul 2021 09:30:22 +0300 Message-Id: <83sg0oc83l.fsf@gnu.org> From: Eli Zaretskii To: Michael Albinus In-Reply-To: <8735sofuqj.fsf@gmx.de> (message from Michael Albinus on Thu, 08 Jul 2021 21:53:08 +0200) Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: <87o8bn7bie.fsf@gnus.org> <87zgv6vuon.fsf@gmx.de> <837di9lwbm.fsf@gnu.org> <87a6n5vuu4.fsf@gnus.org> <8735sqnmei.fsf@gnus.org> <87zguyf4ht.fsf@gmx.de> <87pmvum54p.fsf@gnus.org> <87v95mf2lj.fsf@gmx.de> <87pmvt3ob1.fsf@gnus.org> <87fswpgacv.fsf@gmx.de> <87bl7dfikj.fsf@gmx.de> <8735sofuqj.fsf@gmx.de> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49261 Cc: larsi@gnus.org, ncaprisunfan@gmail.com, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Michael Albinus > Cc: Eli Zaretskii , ncaprisunfan@gmail.com, > 49261@debbugs.gnu.org > Date: Thu, 08 Jul 2021 21:53:08 +0200 > > One point I am missing is to suppress lock files, customised by > users. There is create-lockfiles, but this is all-or-nothing. What other degrees besides "all" and "nothing" would you like to have? And why? From debbugs-submit-bounces@debbugs.gnu.org Fri Jul 09 04:28:42 2021 Received: (at 49261) by debbugs.gnu.org; 9 Jul 2021 08:28:43 +0000 Received: from localhost ([127.0.0.1]:58303 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1lsI-0000OE-NN for submit@debbugs.gnu.org; Fri, 09 Jul 2021 04:28:42 -0400 Received: from mout.gmx.net ([212.227.15.19]:52795) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1lsD-0000Nv-Ht for 49261@debbugs.gnu.org; Fri, 09 Jul 2021 04:28:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1625819310; bh=BHowdOT4x6uQVcjYAfQ8hGgJ1zjliZeKg90kP3gkowc=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=GvvCZx8PxicHlmgbjVMwLWCatx0c1PEaXIoXmTKuHJK1kSzUgArK9SiQQVru5N2/4 SEdhurefFg1UHq8cty/wwihFATwbMjEevq0ikw7aoSWoT+ujgmuM75Kdag5Mu8oC/A kkDHSH5Yd0tn55LhcgtdAhSQBFVTW6JzKoqYdBFw= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from gandalf.gmx.de ([212.91.242.237]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MNKm0-1ln0B21dJi-00Osd8; Fri, 09 Jul 2021 10:28:30 +0200 From: Michael Albinus To: Eli Zaretskii Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: <87o8bn7bie.fsf@gnus.org> <87zgv6vuon.fsf@gmx.de> <837di9lwbm.fsf@gnu.org> <87a6n5vuu4.fsf@gnus.org> <8735sqnmei.fsf@gnus.org> <87zguyf4ht.fsf@gmx.de> <87pmvum54p.fsf@gnus.org> <87v95mf2lj.fsf@gmx.de> <87pmvt3ob1.fsf@gnus.org> <87fswpgacv.fsf@gmx.de> <87bl7dfikj.fsf@gmx.de> <8735sofuqj.fsf@gmx.de> <83sg0oc83l.fsf@gnu.org> Date: Fri, 09 Jul 2021 10:28:29 +0200 In-Reply-To: <83sg0oc83l.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 09 Jul 2021 09:30:22 +0300") Message-ID: <87v95jevrm.fsf@gmx.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:rJGpZV/zjfknfQ2WyA0U0gKB1TU+Cintw/IGgIuJqTjf2q9tT/L QvKb0p7k1iKQhzHcFqS9tSvYQ68WRCVrDXmNEsjn/NZJF1QyCwDbEK+XDWk3q6bSIYEOlZJ 3EDpFlbhLP2qsrdvBpCqa7yjvEea+X5UcKycKVCitwram0rX/0tREXi1ygyME78AonHdKDZ 39YYkVNyLE21yXHMubCQA== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:G+6+3aUYmhw=:zVa+d6zPeDPQ+dD0YsOQlI ob+XlVOZVqYp+ka7/N6kO8HE2mrdBhtABjOFk1fqE/yIj9hEz5X8phbViMbpn2oq1ecs6ddQo 6kUUGeKZ2zRLbMGSv2kurU3/WjZdOQv5BPGD4N2cSmRb89tmEv7xeJuhExpaihkHiY0+hr1Kz bQTlkAgTMTtrhRalm5unUZFMiEzpfMZBWLT9i8AiHg7zlBN50YUOFTzG6xEA6WajuyQX8VrGh cDBIM6ObLNiuHXI+oqXDDSR1lEWdLkWCTHZkpOU3MbkPOdX7uia5+KzOlM6h7q0BrQEeihYWt IW0eN6jrknWXy4RRr7FWMu2KZdCscTkHqoYW8glwoURHrU9TbBRcq/QyqIAVHU6ineDveBCcR AlNYMDF+bJNTpu8dXvib3w2tUhK0WDTQXHibRtmDFz5Wkpvq5XSu4nk/Rh7G1I4i7Q9amMSig geRq9knGWOCf0wD+H6ChrgIscJt1rTYr4cZ9s1AqW0af1tBbR3YeLlaXcnNH01UkvC2652+uC knW4QBp9/vyi069Y5cKRKxYl5zDYBf1Lb4hva0eilAbO5YJrBSpC5qzQ1Hia2lia2DNejvYvr jR2iMIsPw0eTKtzdbxDfT6lTpOJoD2ekM39x2mdTssdYF6lYsg+4r26UmbCc3asbdwilCRhFO 5N7ZooTHjGwIhvIYxdl+BdD3opqIXj2WS8cUHf3l1vXJfb46RODsgl/zU/kPM57czS6KbsKll yHZzNCFgeSjUPLQIDadVMnO2L6ru7u8OUOArRo9b3RDV0rLhbAIh/8q+TJJhIur1nJKtdI6Dk aZdG2mwwHZLSbXLJMKgV6CQFartjOLshOT1+HPB3qOhN3lAclxFz7lYEFQ7FNRXYRv5f3Ht18 MKI7jPUIqHDumr6L0tHbUhTXAMpEYL4Cc5/3hbVAp/FdtQXDqDauP0tI7Y6VcIq4LRIf+joTv 01++IaM0Fy0/KozeWt2H7U0fVKe1gCfnYfqMA+407Jpoen8009/gRNo6YnV3NmyvRoI/X5VNR PGWbJzdsBvEez3FUl2fuvdIUY9bpGY3p2xDWIB8ciwJK6B4/gEbenaJUcmU1FuEn4AgJ3KCXT kJS1BGpJvRbPJTLYpwayyCNhJ2py4R7u/yxHJQgxQ3fzBMinHYQZHu8kQ== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 49261 Cc: larsi@gnus.org, ncaprisunfan@gmail.com, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Eli Zaretskii writes: Hi Eli, >> One point I am missing is to suppress lock files, customised by >> users. There is create-lockfiles, but this is all-or-nothing. > > What other degrees besides "all" and "nothing" would you like to have? > And why? Remote files (all files which match tramp-file-name-regexp). For backward compatibility, and possibly due to performance reasons. Mounted files (all files which match `mounted-file-systems'). Possibly due to performance reasons. These are just examples. One could imagine more fine-grained choices (for example, only files located on a given host), or completely other selections. Best regards, Michael. From debbugs-submit-bounces@debbugs.gnu.org Fri Jul 09 06:45:44 2021 Received: (at 49261) by debbugs.gnu.org; 9 Jul 2021 10:45:44 +0000 Received: from localhost ([127.0.0.1]:58397 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1o0t-0008UU-Uw for submit@debbugs.gnu.org; Fri, 09 Jul 2021 06:45:44 -0400 Received: from eggs.gnu.org ([209.51.188.92]:36246) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1o0p-0008UG-Qj for 49261@debbugs.gnu.org; Fri, 09 Jul 2021 06:45:42 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:56112) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m1o0k-0000wY-6M; Fri, 09 Jul 2021 06:45:34 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3645 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m1o0j-0006lT-Qi; Fri, 09 Jul 2021 06:45:34 -0400 Date: Fri, 09 Jul 2021 13:45:19 +0300 Message-Id: <83lf6fdav4.fsf@gnu.org> From: Eli Zaretskii To: Michael Albinus In-Reply-To: <87v95jevrm.fsf@gmx.de> (message from Michael Albinus on Fri, 09 Jul 2021 10:28:29 +0200) Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: <87o8bn7bie.fsf@gnus.org> <87zgv6vuon.fsf@gmx.de> <837di9lwbm.fsf@gnu.org> <87a6n5vuu4.fsf@gnus.org> <8735sqnmei.fsf@gnus.org> <87zguyf4ht.fsf@gmx.de> <87pmvum54p.fsf@gnus.org> <87v95mf2lj.fsf@gmx.de> <87pmvt3ob1.fsf@gnus.org> <87fswpgacv.fsf@gmx.de> <87bl7dfikj.fsf@gmx.de> <8735sofuqj.fsf@gmx.de> <83sg0oc83l.fsf@gnu.org> <87v95jevrm.fsf@gmx.de> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49261 Cc: larsi@gnus.org, ncaprisunfan@gmail.com, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Michael Albinus > Cc: larsi@gnus.org, ncaprisunfan@gmail.com, 49261@debbugs.gnu.org > Date: Fri, 09 Jul 2021 10:28:29 +0200 > > > What other degrees besides "all" and "nothing" would you like to have? > > And why? > > Remote files (all files which match tramp-file-name-regexp). For > backward compatibility, and possibly due to performance reasons. > > Mounted files (all files which match `mounted-file-systems'). Possibly > due to performance reasons. You want a capability to exempt different kinds of files from locking? Why would that be a good idea? Performance doesn't cut it, IMO, because if one wants to be protected from clobbering, one doesn't care about performance. And if one cares about performance for those special kinds of files, it most probably means one doesn't care about file locking at all. So I submit that a binary switch is good enough. > These are just examples. One could imagine more fine-grained choices > (for example, only files located on a given host), or completely other > selections. I suggest not to imagine potential features. We already have too many features, so we should only add new ones if they are really required. just because someone could use a finer-grained setting doesn't yet mean we need to cater to that in core. In any case, now that make-lock-file-name is exposed to Lisp, they can override or advise it to do whatever they like, right? From debbugs-submit-bounces@debbugs.gnu.org Fri Jul 09 07:01:37 2021 Received: (at 49261) by debbugs.gnu.org; 9 Jul 2021 11:01:37 +0000 Received: from localhost ([127.0.0.1]:58414 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1oGH-0000RH-Cf for submit@debbugs.gnu.org; Fri, 09 Jul 2021 07:01:37 -0400 Received: from mout.gmx.net ([212.227.15.18]:45251) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1oGD-0000R0-GS for 49261@debbugs.gnu.org; Fri, 09 Jul 2021 07:01:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1625828486; bh=sK6NumLjhcHSN1E8LEFnSIx/aDTwEB+Abv3hvi0aOJ8=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=DsxqQVzXmVf533KyWQkcRk33kr5FHl1QXkVmUAba33LxCyGD/KlEkjJ2fzXqM0K0j AaLMcXekpa/UYSx8gVRflXX4iq5oHEVgiDymfHmi6GB61B4963ks84RyL3auV4PEky FapxINwhJ8sMc6WYZs6g2XUhv1ndzWSwolbfx5Pc= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from gandalf.gmx.de ([212.91.242.237]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MCbEf-1ltnuv0kYl-009gjg; Fri, 09 Jul 2021 13:01:26 +0200 From: Michael Albinus To: Eli Zaretskii Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: <87o8bn7bie.fsf@gnus.org> <87zgv6vuon.fsf@gmx.de> <837di9lwbm.fsf@gnu.org> <87a6n5vuu4.fsf@gnus.org> <8735sqnmei.fsf@gnus.org> <87zguyf4ht.fsf@gmx.de> <87pmvum54p.fsf@gnus.org> <87v95mf2lj.fsf@gmx.de> <87pmvt3ob1.fsf@gnus.org> <87fswpgacv.fsf@gmx.de> <87bl7dfikj.fsf@gmx.de> <8735sofuqj.fsf@gmx.de> <83sg0oc83l.fsf@gnu.org> <87v95jevrm.fsf@gmx.de> <83lf6fdav4.fsf@gnu.org> Date: Fri, 09 Jul 2021 13:01:24 +0200 In-Reply-To: <83lf6fdav4.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 09 Jul 2021 13:45:19 +0300") Message-ID: <87r1g7eoor.fsf@gmx.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:qgodFoo5k6epEydMWxW5B4kzg0BTHRF+OKYhnHAE9EabhvXqqWv Z6o+cJyuzwDySgNdcT/OAYXPSSQpdNSEtN0SSiKQ3IF9vNQv58Lp6HCrvZpKrAmUXesyvf1 FeuVjBEBhl/u3NCheRB1CqqN3pQWsD7Is6tJiR3agOCn94/ucxB7bBNUFsSQskccVMJJaxQ p/e0PEJVTD+fGcx/H3RNg== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:vvChGPeNjC0=:NsSmKFTt2dDrFFx8HWSonr 2PsVukRqsPiKOe2rZ7VWdiCCJBUU4SRlc0GCZFD5MmZokb+iFpA21AEg31WXJqFIcqQwjaOJ7 0WL9JCNvDX+53DysbgifGwF6z/idEYF/jKRbiNaRtDQNTvHCl3vGVvEAxYnPKQugQJY1Ncius afD1be+4iuEdhvZQmOAIyZL4wLYeqwlqaKMsKlD2iouwX+kbgRjQUdFd7wNHlC8n3IqPacrR3 Qy3NjZ7oGyu0EpjF874A9rBRmY1ERIZJWwP3aMDwltqRksQ6tl3ykSqIEiFPlmRH9jagjrylh XOcHFAb2qC1jTrUJDi2MfUDVbzyLC7/ewneTqAgOea7zx/jjsle9xL/NAnsFImnzxCoaq6buk IXkw459IYipPkV4zreMapIWZmE1lpv2hvlqyVV9kN2W2o/0zv8ZcO5nxbSPdarWzgBGR0YtQB GzYMmR29axkBZ3i4yX6eW5CxZFpZuAyQ5m7Z3e9RaZG7bIrMUy2p/DArNbZKCmyfB0vp7ggB0 MY3uYifk3dEy5hvZj3SKdnkx8iLsC5EP8d+RZ+KqAz8nP+qVCuWnDN0xDReuTSWnUKOoP/3pN 1tRD5m6JtUQoMNCgDxKL50adM6ig7bogITRWsieBYLtgRjuyu0zL4kos4WKRBZexIvOowzP/5 fDERg9u7C9aqc9Fr1lEwfYooStg+5ktMPUEQia+4DKPWGgrkp/w+Z1N5W4Eb6RMUDpkKtrpQ2 ukE9zrd5vAiBVmFACKGnjQYnFApEFWLjEN1jpJFXfmfaOTKzZATqMjloeeAAd7uZ66mBkds8k VefB2dSlpOZQ/tDgoxE6Ojyzs3G/h9guQ7MjD2XRpReQdeQNk4SUMY2EikKHNXa5qTtFuGlTa h2qolJIM2cPnsTPwHbuNfAE+t2ddvFwwDETBD32MHiSwdmDjCY5kTGlXrf/Qooeci9+8uWDKz 6yldkNRDzJjMQMA4/hkT68Ixt6gMNSmtIG0M44+k+/p9+79yGq4BJBesbXGPm2c9GTC4p0NWL PfzC1arht0DUB/RRJm9DZmW9fYh+d3g1sOr9CeVeVmw896FHtdIR7CpnI5q5ppC08O7RuEjWq LWVD4FoNOpyq8BEpihCQrDERpmGSEU7avi1NwmyBSDjiYp9aGFUfXnxkg== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 49261 Cc: larsi@gnus.org, ncaprisunfan@gmail.com, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Eli Zaretskii writes: Hi Eli, >> Remote files (all files which match tramp-file-name-regexp). For >> backward compatibility, and possibly due to performance reasons. > > You want a capability to exempt different kinds of files from locking? > Why would that be a good idea? Performance doesn't cut it, IMO, > because if one wants to be protected from clobbering, one doesn't care > about performance. And if one cares about performance for those > special kinds of files, it most probably means one doesn't care about > file locking at all. > > So I submit that a binary switch is good enough. Until now, there are no file locks for remote files at all. I thought disabling it for remote files would be requested by some users for backward compatibility. > In any case, now that make-lock-file-name is exposed to Lisp, they can > override or advise it to do whatever they like, right? Yes. But they cannot disable it. Advising the function is always possible, but it is less convenient than a user option setting. But well, let's see whether people shout ... Best regards, Michael. From debbugs-submit-bounces@debbugs.gnu.org Fri Jul 09 12:31:41 2021 Received: (at 49261) by debbugs.gnu.org; 9 Jul 2021 16:31:41 +0000 Received: from localhost ([127.0.0.1]:59611 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1tPh-0004d4-Mb for submit@debbugs.gnu.org; Fri, 09 Jul 2021 12:31:41 -0400 Received: from quimby.gnus.org ([95.216.78.240]:47210) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1tPg-0004cq-Ax for 49261@debbugs.gnu.org; Fri, 09 Jul 2021 12:31:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=LlHER++yqZfDAYa1tdVfftjRIRMV7T/gHIjJlVokJRw=; b=evhTn8EBjSceS9XEbs12HgrWps vIZZjY9N2B8Mljl/KX8wKa5rAjdVDfd/Blpr+Onflfi+AlYIXhJsXUqwTNaPa7fO/yQQ8wlBLyYsg deWhyTNhrJ6wLl8KHCAIT7WfLuFGlPboR9CstzTBEL9Zi+Gif9VFPDfb5ehT4/TGAeWc=; Received: from cm-84.212.220.105.getinternet.no ([84.212.220.105] helo=elva) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m1tP4-0000Z8-39; Fri, 09 Jul 2021 18:31:08 +0200 From: Lars Ingebrigtsen To: Michael Albinus Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: <87o8bn7bie.fsf@gnus.org> <87zgv6vuon.fsf@gmx.de> <837di9lwbm.fsf@gnu.org> <87a6n5vuu4.fsf@gnus.org> <8735sqnmei.fsf@gnus.org> <87zguyf4ht.fsf@gmx.de> <87pmvum54p.fsf@gnus.org> <87v95mf2lj.fsf@gmx.de> <87pmvt3ob1.fsf@gnus.org> <87fswpgacv.fsf@gmx.de> <87bl7dfikj.fsf@gmx.de> <8735sofuqj.fsf@gmx.de> <83sg0oc83l.fsf@gnu.org> <87v95jevrm.fsf@gmx.de> <83lf6fdav4.fsf@gnu.org> <87r1g7eoor.fsf@gmx.de> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAD1BMVEVOS1M7NDmLW1dg W2L///9nMV5hAAAAAWJLR0QEj2jZUQAAAAd0SU1FB+UHCRAeAI0SL6QAAAGGSURBVDjLbVOLlcMg DDPxAs5NcEcWoHj/3U6ygdC0vDShkj9CcUTOj2UVS8oX4iDxBkWUSX0Qllfgb4SMhONBmMXjqE8i k0yvZ6mob6a91qsvQrARECIAM0MKehY2FuCo36/MQNkCpKQg6bX3q9ULuSAYXEgIOiiJFjAbRxPR 5s2r+y9LRHBBKgnvrTsuB0go9AiJS4EiJwpE2iC4Gh5iwLSJTIJUAy5xqjZRxLJ+m5FIxh1/G+vj Fp2jMkKydr8ccbMn1WffyhvURDyD99UA+ejxjktkyUeCfSN4hBOlNFvfi9pgNeSHLt/NgH9hyVFs 1UtHuIcjP+OUoWeTdh4vvm17EB7zSCFDouokzp8/DnM6wJ8uoozBStcoMYgyCJuGDoEYsWJjRIep WQzEC1tm4TxZMXvc67QSPvhOUBFn+Jyq+o2LzAEevuQUzHL3J7TWJEuRDZX5bmSPbHwvdJx/8MAw NN0yPL6CWDsxvdA1KrlMp+E6zresQzoLaeiI72M4i72uEPd/qbBeFEFz3aUAAAAldEVYdGRhdGU6 Y3JlYXRlADIwMjEtMDctMDlUMTY6MzA6MDArMDA6MDAo+d8NAAAAJXRFWHRkYXRlOm1vZGlmeQAy MDIxLTA3LTA5VDE2OjMwOjAwKzAwOjAwWaRnsQAAAABJRU5ErkJggg== X-Now-Playing: Japan's _Exorcising Ghosts_: "Swing" Date: Fri, 09 Jul 2021 18:31:01 +0200 In-Reply-To: <87r1g7eoor.fsf@gmx.de> (Michael Albinus's message of "Fri, 09 Jul 2021 13:01:24 +0200") Message-ID: <87im1jphyy.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Michael Albinus writes: > Until now, there are no file locks for remote files at all. I thought > disabling it for remote files would be requested by some users for > backward compatibility. Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49261 Cc: Eli Zaretskii , ncaprisunfan@gmail.com, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Michael Albinus writes: > Until now, there are no file locks for remote files at all. I thought > disabling it for remote files would be requested by some users for > backward compatibility. Yeah, I think it's a good idea, and allowing REPLACEMENT to be nil seems like the natural way to implement it. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 10 12:25:51 2021 Received: (at 49261) by debbugs.gnu.org; 10 Jul 2021 16:25:51 +0000 Received: from localhost ([127.0.0.1]:33290 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m2Fnb-0007UC-KN for submit@debbugs.gnu.org; Sat, 10 Jul 2021 12:25:51 -0400 Received: from quimby.gnus.org ([95.216.78.240]:56920) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m2FnZ-0007Tz-D0 for 49261@debbugs.gnu.org; Sat, 10 Jul 2021 12:25:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=aqNdmWnyr5TecJDYrUvxZJHbh/hkAxgWLK7orp9OeuA=; b=WhHCyA/OMUdpH0xVgfF+EG4PBy Pa7Dnd5ZEnY+MMVHbV04voBnCltiho5vSUwsx8K3ZYHFAu3v/8CWO5tslSpuOfX02OlyxMzTPe+th yX1IoMJRKG2G69MoX04t/gpTbXGAb5wUF1OH6sWmxR7dLsG3D+PVbeKLXt3cr5B0FB+0=; Received: from cm-84.212.220.105.getinternet.no ([84.212.220.105] helo=elva) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m2FnF-0005bf-LR; Sat, 10 Jul 2021 18:25:32 +0200 From: Lars Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: <87o8bn7bie.fsf@gnus.org> <87zgv6vuon.fsf@gmx.de> <837di9lwbm.fsf@gnu.org> <87a6n5vuu4.fsf@gnus.org> <8735sqnmei.fsf@gnus.org> <87zguyf4ht.fsf@gmx.de> <87pmvum54p.fsf@gnus.org> <87v95mf2lj.fsf@gmx.de> <87pmvt3ob1.fsf@gnus.org> <83r1g9evoy.fsf@gnu.org> <83pmvtevgg.fsf@gnu.org> <87czrt3mj4.fsf@gnus.org> <878s2h3m1d.fsf@gnus.org> <874kd53lnl.fsf@gnus.org> <87zgux26ab.fsf@gnus.org> <83k0m1e3dg.fsf@gnu.org> <875yxlugcb.fsf@gnus.org> <8335spdjy5.fsf@gnu.org> <878s2hszcx.fsf@gnus.org> <83y2agda7l.fsf@gnu.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAElBMVEXq7e6npqGIgXNf VkkYFBH///+w5t/OAAAAAWJLR0QF+G/pxwAAAAd0SU1FB+UHChAYK2VB3owAAAGgSURBVDjLdZTt gcMgCIYx7QBqOkDVDtCoA1wD+890gB9Nrzn+pPIIvKAW4GDG+VS6wYc553P0W4yxDEf7WuOCXwJz ARdEIrKaij25pJgklakkhrYBTuMiE4AHNUMF7EpZIxYatimYqq4T0P0DvP307IDwD3gJqKqlDrA5 Xu8muNQ3NSBSb/x1YfgbED+sAlwdAEF1Sv/8I3s6Agw6WVndTgDceGJjCplrVE1lAK7bLEDbA6Xz YH0GWO5vsF94cpVy8OXOh9IB8s6FAYe8Fh26AkSUcFSdL9D6DXBbKayone0qa22CEoKza0uFCrrW rdrbZvYOjD2AJ6/2Nr072J5q53mxQoht38+swfIU+HYe2VkwrXiA+uLw1ADKVBrYoaeawLXi6BK8 gV6dfvFiCh/A+T6q54NLLANgDOu4XfEICEcAZTnpywRU5qFKiRKPF27eYQb5BCC/orWcAIk5BdLt 5QzoseX/wLcqrKLKMOiNzf7SaBD7xjEbHyTgKxVG/jMw/HQ1VT0EFX3MAvBdtm3QR3sASBWp1IID DD2IBcXZwS99p9AznJ08HgAAACV0RVh0ZGF0ZTpjcmVhdGUAMjAyMS0wNy0xMFQxNjoyNDo0Mysw MDowMA/jcU0AAAAldEVYdGRhdGU6bW9kaWZ5ADIwMjEtMDctMTBUMTY6MjQ6NDMrMDA6MDB+vsnx AAAAAElFTkSuQmCC X-Now-Playing: Tears For Fears's _Songs From The Big Chair_: "Head Over Heels-Broken (Live)" Date: Sat, 10 Jul 2021 18:25:27 +0200 In-Reply-To: <83y2agda7l.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 08 Jul 2021 19:47:10 +0300") Message-ID: <87a6mup24o.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Eli Zaretskii writes: > (gdb) p $2->u.s.car > (gdb) xtype > > And after the second "xtype" continue with the x* command according to > the type. Ah, thanks: Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49261 Cc: michael.albinus@gmx.de, ncaprisunfan@gmail.com, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: > (gdb) p $2->u.s.car > (gdb) xtype > > And after the second "xtype" continue with the x* command according to > the type. Ah, thanks: gdb) xtype Lisp_Cons (gdb) xcons $2 = (struct Lisp_Cons *) 0x7ffff211c260 { u = { s = { car = XIL(0x2aaa9c41a9e0), u = { cdr = XIL(0), chain = 0x0 } }, gcaligned = 0xe0 } } (gdb) p $2->u.s.car $3 = XIL(0x2aaa9c41a9e0) (gdb) xtype Lisp_Symbol (gdb) xsymbol $4 = (struct Lisp_Symbol *) 0x7ffff1fc26c0 "normal-top-level" (gdb) So it's segfaulting while evaling normal-top-level? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 10 13:05:11 2021 Received: (at 49261) by debbugs.gnu.org; 10 Jul 2021 17:05:11 +0000 Received: from localhost ([127.0.0.1]:33361 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m2GPf-0004PV-2m for submit@debbugs.gnu.org; Sat, 10 Jul 2021 13:05:11 -0400 Received: from eggs.gnu.org ([209.51.188.92]:43158) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m2GPe-0004PG-5r for 49261@debbugs.gnu.org; Sat, 10 Jul 2021 13:05:10 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:40452) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m2GPY-0004hK-PC; Sat, 10 Jul 2021 13:05:04 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2062 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m2GPY-0005Xt-Dl; Sat, 10 Jul 2021 13:05:04 -0400 Date: Sat, 10 Jul 2021 20:04:51 +0300 Message-Id: <83wnpyaymk.fsf@gnu.org> From: Eli Zaretskii To: Lars Ingebrigtsen , Stefan Monnier In-Reply-To: <87a6mup24o.fsf@gnus.org> (message from Lars Ingebrigtsen on Sat, 10 Jul 2021 18:25:27 +0200) Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: <87o8bn7bie.fsf@gnus.org> <87zgv6vuon.fsf@gmx.de> <837di9lwbm.fsf@gnu.org> <87a6n5vuu4.fsf@gnus.org> <8735sqnmei.fsf@gnus.org> <87zguyf4ht.fsf@gmx.de> <87pmvum54p.fsf@gnus.org> <87v95mf2lj.fsf@gmx.de> <87pmvt3ob1.fsf@gnus.org> <83r1g9evoy.fsf@gnu.org> <83pmvtevgg.fsf@gnu.org> <87czrt3mj4.fsf@gnus.org> <878s2h3m1d.fsf@gnus.org> <874kd53lnl.fsf@gnus.org> <87zgux26ab.fsf@gnus.org> <83k0m1e3dg.fsf@gnu.org> <875yxlugcb.fsf@gnus.org> <8335spdjy5.fsf@gnu.org> <878s2hszcx.fsf@gnus.org> <83y2agda7l.fsf@gnu.org> <87a6mup24o.fsf@gnus.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49261 Cc: michael.albinus@gmx.de, ncaprisunfan@gmail.com, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Lars Ingebrigtsen > Cc: michael.albinus@gmx.de, ncaprisunfan@gmail.com, 49261@debbugs.gnu.org > Date: Sat, 10 Jul 2021 18:25:27 +0200 > > (gdb) p $2->u.s.car > $3 = XIL(0x2aaa9c41a9e0) > (gdb) xtype > Lisp_Symbol > (gdb) xsymbol > $4 = (struct Lisp_Symbol *) 0x7ffff1fc26c0 > "normal-top-level" > (gdb) > > So it's segfaulting while evaling normal-top-level? Yes. Which is consistent with the backtrace, so this didn't teach us anything new. It would be good to try to understand byte code of which function is being run in frame #3 here: > Thread 1 "bootstrap-emacs" received signal SIGSEGV, Segmentation fault. > 0x00005555556f0549 in AREF (idx=6988131860, array=XIL(0x7ffff1bd901d)) > at lisp.h:731 > 731 return lisp_h_XLP (o); > (gdb) bt > #0 0x00005555556f0549 in AREF (idx=6988131860, array=XIL(0x7ffff1bd901d)) > at lisp.h:731 > #1 HASH_KEY (idx=3494065930, h=0x7ffff1bd8f98) at lisp.h:2374 > #2 hash_lookup > (h=0x7ffff1bd8f98, key=XIL(0x555555c76c64), hash=hash@entry=0x0) > at fns.c:4479 > #3 0x0000555555719cb9 in exec_byte_code > (bytestr=, vector=, maxdepth=, args_template=args_template@entry=make_fixnum(257), nargs=nargs@entry=1, args=, args@entry=0x7fffffffd940) at bytecode.c:1415 > #4 0x00005555556e643f in fetch_and_exec_byte_code > (args=0x7fffffffd940, nargs=1, syms_left=make_fixnum(257), fun=XIL(0x7ffff1bc9895)) at lisp.h:731 > #5 funcall_lambda > (fun=XIL(0x7ffff1bc9895), nargs=nargs@entry=1, arg_vector=arg_vector@entry=0x7fffffffd940) at eval.c:3244 The problem is this is an optimized build and many variables are "optimized out". Line 1415 of bytecomp.c is here: CASE (Bswitch): { /* TODO: Perhaps introduce another byte-code for switch when the number of cases is less, which uses a simple vector for linear search as the jump table. */ Lisp_Object jmp_table = POP; if (BYTE_CODE_SAFE && !HASH_TABLE_P (jmp_table)) emacs_abort (); Lisp_Object v1 = POP; ptrdiff_t i; struct Lisp_Hash_Table *h = XHASH_TABLE (jmp_table); /* h->count is a faster approximation for HASH_TABLE_SIZE (h) here. */ if (h->count <= 5 && !h->test.cmpfn) { /* Do a linear search if there are not many cases FIXME: 5 is arbitrarily chosen. */ for (i = h->count; 0 <= --i; ) if (EQ (v1, HASH_KEY (h, i))) break; } else i = hash_lookup (h, v1, NULL); <<<<<<<<<<<<<<<<< Stefan, what code in command-line-1 is likely to produce the Bswitch byte-code? Anyway, looking at frame 1, I guess the value of 'idx' is bogus, which means something is wrong with the hash table. So maybe we should audit the part(s) of the offending commit that have something to do with hash tables? Also, what kind of hash-table are we looking up there, is it possible to understand that by looking at the variables involved in the above code? From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 10 13:16:32 2021 Received: (at 49261) by debbugs.gnu.org; 10 Jul 2021 17:16:32 +0000 Received: from localhost ([127.0.0.1]:33383 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m2Gae-0005zV-5e for submit@debbugs.gnu.org; Sat, 10 Jul 2021 13:16:32 -0400 Received: from quimby.gnus.org ([95.216.78.240]:57458) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m2Gac-0005t6-9z for 49261@debbugs.gnu.org; Sat, 10 Jul 2021 13:16:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=jBhSXNqiQuJ35Pn2PPUmFNKStsnPTwvorl9sCjoD7fs=; b=T9sNRDReQwClNEsUVwatcmQLhK hZE+/RAm9iexbK8Cml3J5rqYVFpQ7xN9nzs0/gdO55KOlrQibV0LIlkokTl5XTBHjHWy86gOUNdJd KTr1UP/dN48pugbg1N50GVEhDPe2NKESaZ3SBd5ED/kl3LmW/ptziIpHwMbncONBWBxc=; Received: from cm-84.212.220.105.getinternet.no ([84.212.220.105] helo=elva) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m2Ga1-000633-NB; Sat, 10 Jul 2021 19:15:56 +0200 From: Lars Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: <837di9lwbm.fsf@gnu.org> <87a6n5vuu4.fsf@gnus.org> <8735sqnmei.fsf@gnus.org> <87zguyf4ht.fsf@gmx.de> <87pmvum54p.fsf@gnus.org> <87v95mf2lj.fsf@gmx.de> <87pmvt3ob1.fsf@gnus.org> <83r1g9evoy.fsf@gnu.org> <83pmvtevgg.fsf@gnu.org> <87czrt3mj4.fsf@gnus.org> <878s2h3m1d.fsf@gnus.org> <874kd53lnl.fsf@gnus.org> <87zgux26ab.fsf@gnus.org> <83k0m1e3dg.fsf@gnu.org> <875yxlugcb.fsf@gnus.org> <8335spdjy5.fsf@gnu.org> <878s2hszcx.fsf@gnus.org> <83y2agda7l.fsf@gnu.org> <87a6mup24o.fsf@gnus.org> <83wnpyaymk.fsf@gnu.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwAgMAAAAqbBEUAAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAADFBMVEUzLTSvo6aFeYH/ //+uDohvAAAAAWJLR0QDEQxM8gAAAAd0SU1FB+UHChEOC0N1IaQAAAFdSURBVCjPTZHBaoNAEIb/ LG3QvdtDT1Iw1DyFPfZWSkbUUwi0NHmKjRBovVsST1airPuU3V2NyR5m/m9n52eWgbctY6xnSrJM wCOicNPHSmU9vJ1SMlwD0FBFOs9MyAokJrsWfpBdKxKlyTAhLUARg1ONPb1wBSNhgCMXbiHIPJUc aeQCngHBtdsc4AZ0PIpBAYyDi1Gj5mAamL2oHe0GP1jBARoHzT57fu8wtyDys1/PEbwZyEVtGoLE wH5wezpC6WeTNXNQj5KvtWMjB1gmGjZjxcs0REOPoj98Y9BMtNtcGQPLixPFRlm4Uz1hOiqw4A/f ub8FXUn8y0c9DaN26hPhUuC3oGe4gWY7gY8mzfQ4/jBcn7VGMutciODa0+nLCX7tJsaBjvUe6UJW bZqGJbWE+PGrpBcKiQ6EUn22tKOA6DUGdedSQ/hBhxX6qqtaqZaqLKTZj1kg8AD8A2iXcoJUEAQV AAAAJXRFWHRkYXRlOmNyZWF0ZQAyMDIxLTA3LTEwVDE3OjE0OjExKzAwOjAwlOjRhAAAACV0RVh0 ZGF0ZTptb2RpZnkAMjAyMS0wNy0xMFQxNzoxNDoxMSswMDowMOW1aTgAAAAASUVORK5CYII= X-Now-Playing: The Style Council's _Our Favourite Shop_: "Homebreakers" Date: Sat, 10 Jul 2021 19:15:53 +0200 In-Reply-To: <83wnpyaymk.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 10 Jul 2021 20:04:51 +0300") Message-ID: <87v95im6nq.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Eli Zaretskii writes: > It would be good to try to understand byte code of which function is > being run in frame #3 here: > >> Thread 1 "bootstrap-emacs" received signal SIGSEGV, Segmentation fault. >> 0x00005555556f0549 [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49261 Cc: 49261@debbugs.gnu.org, Paul Eggert , michael.albinus@gmx.de, Stefan Monnier , ncaprisunfan@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: > It would be good to try to understand byte code of which function is > being run in frame #3 here: > >> Thread 1 "bootstrap-emacs" received signal SIGSEGV, Segmentation fault. >> 0x00005555556f0549 in AREF (idx=6988131860, array=XIL(0x7ffff1bd901d)) >> at lisp.h:731 >> 731 return lisp_h_XLP (o); >> (gdb) bt >> #0 0x00005555556f0549 in AREF (idx=6988131860, array=XIL(0x7ffff1bd901d)) >> at lisp.h:731 >> #1 HASH_KEY (idx=3494065930, h=0x7ffff1bd8f98) at lisp.h:2374 >> #2 hash_lookup >> (h=0x7ffff1bd8f98, key=XIL(0x555555c76c64), hash=hash@entry=0x0) >> at fns.c:4479 Well, the segfault is in this: for (i = HASH_INDEX (h, start_of_bucket); 0 <= i; i = HASH_NEXT (h, i)) { and you can see that idx (i.e., i here) is 3494065930, which is a very unusual value for idx -- it's usually below 2K. So it can't really be anything other than a memory corruption issue, I think? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 10 13:20:43 2021 Received: (at 49261) by debbugs.gnu.org; 10 Jul 2021 17:20:43 +0000 Received: from localhost ([127.0.0.1]:33400 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m2Ged-000700-Mv for submit@debbugs.gnu.org; Sat, 10 Jul 2021 13:20:43 -0400 Received: from eggs.gnu.org ([209.51.188.92]:44900) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m2Gec-0006zo-D5 for 49261@debbugs.gnu.org; Sat, 10 Jul 2021 13:20:39 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:40708) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m2GeU-0006bq-V2; Sat, 10 Jul 2021 13:20:30 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3010 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m2GeU-00071i-JI; Sat, 10 Jul 2021 13:20:30 -0400 Date: Sat, 10 Jul 2021 20:20:20 +0300 Message-Id: <83tul2axwr.fsf@gnu.org> From: Eli Zaretskii To: Lars Ingebrigtsen In-Reply-To: <87v95im6nq.fsf@gnus.org> (message from Lars Ingebrigtsen on Sat, 10 Jul 2021 19:15:53 +0200) Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: <837di9lwbm.fsf@gnu.org> <87a6n5vuu4.fsf@gnus.org> <8735sqnmei.fsf@gnus.org> <87zguyf4ht.fsf@gmx.de> <87pmvum54p.fsf@gnus.org> <87v95mf2lj.fsf@gmx.de> <87pmvt3ob1.fsf@gnus.org> <83r1g9evoy.fsf@gnu.org> <83pmvtevgg.fsf@gnu.org> <87czrt3mj4.fsf@gnus.org> <878s2h3m1d.fsf@gnus.org> <874kd53lnl.fsf@gnus.org> <87zgux26ab.fsf@gnus.org> <83k0m1e3dg.fsf@gnu.org> <875yxlugcb.fsf@gnus.org> <8335spdjy5.fsf@gnu.org> <878s2hszcx.fsf@gnus.org> <83y2agda7l.fsf@gnu.org> <87a6mup24o.fsf@gnus.org> <83wnpyaymk.fsf@gnu.org> <87v95im6nq.fsf@gnus.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49261 Cc: 49261@debbugs.gnu.org, eggert@cs.ucla.edu, michael.albinus@gmx.de, monnier@iro.umontreal.ca, ncaprisunfan@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Lars Ingebrigtsen > Cc: Stefan Monnier , michael.albinus@gmx.de, > ncaprisunfan@gmail.com, 49261@debbugs.gnu.org, Paul Eggert > > Date: Sat, 10 Jul 2021 19:15:53 +0200 > > >> 731 return lisp_h_XLP (o); > >> (gdb) bt > >> #0 0x00005555556f0549 in AREF (idx=6988131860, array=XIL(0x7ffff1bd901d)) > >> at lisp.h:731 > >> #1 HASH_KEY (idx=3494065930, h=0x7ffff1bd8f98) at lisp.h:2374 > >> #2 hash_lookup > >> (h=0x7ffff1bd8f98, key=XIL(0x555555c76c64), hash=hash@entry=0x0) > >> at fns.c:4479 > > Well, the segfault is in this: > > for (i = HASH_INDEX (h, start_of_bucket); 0 <= i; i = HASH_NEXT (h, i)) > { > > and you can see that idx (i.e., i here) is 3494065930, which is a very > unusual value for idx -- it's usually below 2K. So it can't really be > anything other than a memory corruption issue, I think? Yes, but why? and in which hash-table? From debbugs-submit-bounces@debbugs.gnu.org Sun Jul 11 04:36:31 2021 Received: (at 49261) by debbugs.gnu.org; 11 Jul 2021 08:36:31 +0000 Received: from localhost ([127.0.0.1]:33845 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m2Uwx-0008Gh-Al for submit@debbugs.gnu.org; Sun, 11 Jul 2021 04:36:31 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:57904) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m2Uwv-0008GQ-N7 for 49261@debbugs.gnu.org; Sun, 11 Jul 2021 04:36:30 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 99B6416006F; Sun, 11 Jul 2021 01:36:23 -0700 (PDT) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id IQGioXllqwx2; Sun, 11 Jul 2021 01:36:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 5657A16008D; Sun, 11 Jul 2021 01:36:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 1n0jqanoLdOm; Sun, 11 Jul 2021 01:36:22 -0700 (PDT) Received: from [192.168.1.9] (cpe-172-91-119-151.socal.res.rr.com [172.91.119.151]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 18A3716006F; Sun, 11 Jul 2021 01:36:22 -0700 (PDT) To: Lars Ingebrigtsen References: <87o8bn7bie.fsf@gnus.org> <87zgv6vuon.fsf@gmx.de> <837di9lwbm.fsf@gnu.org> <87a6n5vuu4.fsf@gnus.org> <8735sqnmei.fsf@gnus.org> <87zguyf4ht.fsf@gmx.de> <87pmvum54p.fsf@gnus.org> <87v95mf2lj.fsf@gmx.de> <87pmvt3ob1.fsf@gnus.org> <83r1g9evoy.fsf@gnu.org> <83pmvtevgg.fsf@gnu.org> <87czrt3mj4.fsf@gnus.org> <878s2h3m1d.fsf@gnus.org> <874kd53lnl.fsf@gnus.org> <87zgux26ab.fsf@gnus.org> <87pmvt25uq.fsf@gnus.org> <87lf6h2294.fsf@gnus.org> <87h7h51x9y.fsf_-_@gnus.org> From: Paul Eggert Organization: UCLA Computer Science Department Subject: Re: Segfault during loadup Message-ID: Date: Sun, 11 Jul 2021 01:36:21 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <87h7h51x9y.fsf_-_@gnus.org> Content-Type: multipart/mixed; boundary="------------F1DFBA2D6341F22CE1972BAC" Content-Language: en-US X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49261 Cc: Eli Zaretskii , 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) This is a multi-part message in MIME format. --------------F1DFBA2D6341F22CE1972BAC Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable On 7/7/21 5:09 PM, Lars Ingebrigtsen wrote: > There seems to be a corruption in the hash tables somewhere. It's > totally reproducible with the recipe Thanks for the recipe; it let me reproduce the problem on Fedora 34 x86-6= 4. The problem comes from the fact that mark_maybe_pointer works=20 differently on pdumper objects than it works on ordinary objects. On=20 ordinary objects, roots can point anywhere into an object (because this=20 sort of thing has happened on real machines), whereas on pdumper=20 objects, roots had to point to the start of the object. I worked around this particular problem changing mark_maybe_pointer so=20 that pdumper roots can also be tagged (see first attached patch).=20 However, I suspect this is not a complete fix, as it doesn't cover the=20 case where a root points to some part of a pdumper object that is not at=20 the object's start. I added a FIXME about this. Perhaps Daniel can take=20 a look at it sometime. I think the remaining bug will be hit only rarely=20 (if ever). The second attached patch is in the same area, but is not part of the=20 fix. It causes the GC to be a bit more accurate (i.e., less=20 conservative) for roots, which can help avoid some leaks. --------------F1DFBA2D6341F22CE1972BAC Content-Type: text/x-patch; charset=UTF-8; name="0001-Fix-pdumper-related-GC-bug.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0001-Fix-pdumper-related-GC-bug.patch" =46rom 2f7afef5ffe023a7a12520201ab70643f826abfd Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sun, 11 Jul 2021 00:27:43 -0700 Subject: [PATCH 1/2] Fix pdumper-related GC bug MIME-Version: 1.0 Content-Type: text/plain; charset=3DUTF-8 Content-Transfer-Encoding: 8bit * src/alloc.c (mark_maybe_pointer): Also mark pointers to pdumper objects, even when the pointers are tagged. Add a FIXME saying why this isn=E2=80=99t enough. --- src/alloc.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/src/alloc.c b/src/alloc.c index 76d8c7ddd1..752eaec135 100644 --- a/src/alloc.c +++ b/src/alloc.c @@ -4755,6 +4755,17 @@ mark_maybe_pointer (void *p) definitely _don't_ have an object. */ if (pdumper_object_p (p)) { + /* FIXME: This code assumes that every reachable pdumper object + is addressed either by a pointer to the object start, or by + the same pointer with an LSB-style tag. This assumption + fails if a pdumper object is reachable only via machine + addresses of non-initial object components. Although such + addressing is rare in machine code generated by C compilers + from Emacs source code, it can occur in some cases. To fix + this problem, the pdumper code should grok non-initial + addresses, as the non-pdumper code does. */ + uintptr_t mask =3D VALMASK; + p =3D (void *) ((uintptr_t) p & mask); /* Don't use pdumper_object_p_precise here! It doesn't check the tag bits. OBJ here might be complete garbage, so we need to verify both the pointer and the tag. */ --=20 2.31.1 --------------F1DFBA2D6341F22CE1972BAC Content-Type: text/x-patch; charset=UTF-8; name="0002-Make-pdumper-marking-pickier.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0002-Make-pdumper-marking-pickier.patch" =46rom f6472cc8e2fdcfd7365240783f34e101fe44142b Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sun, 11 Jul 2021 00:54:32 -0700 Subject: [PATCH 2/2] Make pdumper-marking pickier MIME-Version: 1.0 Content-Type: text/plain; charset=3DUTF-8 Content-Transfer-Encoding: 8bit Prevent some false-positives in conservative GC marking. This doesn=E2=80=99t fix any correctness bugs; it=E2=80=99s merely to reclaim some memory instead of keeping it unnecessarily. * src/alloc.c (mark_maybe_pointer): New arg SYMBOL_ONLY. All callers changed. Check that the pointer=E2=80=99s tag, if any, matches the pdumper-reported type. --- src/alloc.c | 34 +++++++++++++++++++++++++--------- 1 file changed, 25 insertions(+), 9 deletions(-) diff --git a/src/alloc.c b/src/alloc.c index 752eaec135..b3668d2131 100644 --- a/src/alloc.c +++ b/src/alloc.c @@ -4740,7 +4740,7 @@ live_small_vector_p (struct mem_node *m, void *p) marked. */ =20 static void -mark_maybe_pointer (void *p) +mark_maybe_pointer (void *p, bool symbol_only) { struct mem_node *m; =20 @@ -4765,15 +4765,21 @@ mark_maybe_pointer (void *p) this problem, the pdumper code should grok non-initial addresses, as the non-pdumper code does. */ uintptr_t mask =3D VALMASK; - p =3D (void *) ((uintptr_t) p & mask); + void *po =3D (void *) ((uintptr_t) p & mask); + char *cp =3D p; + char *cpo =3D po; /* Don't use pdumper_object_p_precise here! It doesn't check the tag bits. OBJ here might be complete garbage, so we need to verify both the pointer and the tag. */ - int type =3D pdumper_find_object_type (p); - if (pdumper_valid_object_type_p (type)) - mark_object (type =3D=3D Lisp_Symbol - ? make_lisp_symbol (p) - : make_lisp_ptr (p, type)); + int type =3D pdumper_find_object_type (po); + if (pdumper_valid_object_type_p (type) + && (!USE_LSB_TAG || p =3D=3D po || cp - cpo =3D=3D type)) + { + if (type =3D=3D Lisp_Symbol) + mark_object (make_lisp_symbol (po)); + else if (!symbol_only) + mark_object (make_lisp_ptr (po, type)); + } return; } =20 @@ -4791,6 +4797,8 @@ mark_maybe_pointer (void *p) =20 case MEM_TYPE_CONS: { + if (symbol_only) + return; struct Lisp_Cons *h =3D live_cons_holding (m, p); if (!h) return; @@ -4800,6 +4808,8 @@ mark_maybe_pointer (void *p) =20 case MEM_TYPE_STRING: { + if (symbol_only) + return; struct Lisp_String *h =3D live_string_holding (m, p); if (!h) return; @@ -4818,6 +4828,8 @@ mark_maybe_pointer (void *p) =20 case MEM_TYPE_FLOAT: { + if (symbol_only) + return; struct Lisp_Float *h =3D live_float_holding (m, p); if (!h) return; @@ -4827,6 +4839,8 @@ mark_maybe_pointer (void *p) =20 case MEM_TYPE_VECTORLIKE: { + if (symbol_only) + return; struct Lisp_Vector *h =3D live_large_vector_holding (m, p); if (!h) return; @@ -4836,6 +4850,8 @@ mark_maybe_pointer (void *p) =20 case MEM_TYPE_VECTOR_BLOCK: { + if (symbol_only) + return; struct Lisp_Vector *h =3D live_small_vector_holding (m, p); if (!h) return; @@ -4897,7 +4913,7 @@ mark_memory (void const *start, void const *end) for (pp =3D start; (void const *) pp < end; pp +=3D GC_POINTER_ALIGNME= NT) { void *p =3D *(void *const *) pp; - mark_maybe_pointer (p); + mark_maybe_pointer (p, false); =20 /* Unmask any struct Lisp_Symbol pointer that make_lisp_symbol previously disguised by adding the address of 'lispsym'. @@ -4906,7 +4922,7 @@ mark_memory (void const *start, void const *end) non-adjacent words and P might be the low-order word's value. */ intptr_t ip; INT_ADD_WRAPV ((intptr_t) p, (intptr_t) lispsym, &ip); - mark_maybe_pointer ((void *) ip); + mark_maybe_pointer ((void *) ip, true); } } =20 --=20 2.31.1 --------------F1DFBA2D6341F22CE1972BAC-- From debbugs-submit-bounces@debbugs.gnu.org Sun Jul 11 06:21:33 2021 Received: (at 49261) by debbugs.gnu.org; 11 Jul 2021 10:21:33 +0000 Received: from localhost ([127.0.0.1]:33961 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m2Wab-0002ba-DV for submit@debbugs.gnu.org; Sun, 11 Jul 2021 06:21:33 -0400 Received: from eggs.gnu.org ([209.51.188.92]:46378) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m2WaZ-0002bL-5N for 49261@debbugs.gnu.org; Sun, 11 Jul 2021 06:21:31 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:41552) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m2WaT-0001OO-6Q; Sun, 11 Jul 2021 06:21:25 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:1774 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m2WaS-0001We-Q0; Sun, 11 Jul 2021 06:21:25 -0400 Date: Sun, 11 Jul 2021 13:21:16 +0300 Message-Id: <83bl79b17n.fsf@gnu.org> From: Eli Zaretskii To: Paul Eggert In-Reply-To: (message from Paul Eggert on Sun, 11 Jul 2021 01:36:21 -0700) Subject: Re: Segfault during loadup References: <87o8bn7bie.fsf@gnus.org> <87zgv6vuon.fsf@gmx.de> <837di9lwbm.fsf@gnu.org> <87a6n5vuu4.fsf@gnus.org> <8735sqnmei.fsf@gnus.org> <87zguyf4ht.fsf@gmx.de> <87pmvum54p.fsf@gnus.org> <87v95mf2lj.fsf@gmx.de> <87pmvt3ob1.fsf@gnus.org> <83r1g9evoy.fsf@gnu.org> <83pmvtevgg.fsf@gnu.org> <87czrt3mj4.fsf@gnus.org> <878s2h3m1d.fsf@gnus.org> <874kd53lnl.fsf@gnus.org> <87zgux26ab.fsf@gnus.org> <87pmvt25uq.fsf@gnus.org> <87lf6h2294.fsf@gnus.org> <87h7h51x9y.fsf_-_@gnus.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49261 Cc: larsi@gnus.org, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: 49261@debbugs.gnu.org, Eli Zaretskii > From: Paul Eggert > Date: Sun, 11 Jul 2021 01:36:21 -0700 > > I worked around this particular problem changing mark_maybe_pointer so > that pdumper roots can also be tagged (see first attached patch). > However, I suspect this is not a complete fix, as it doesn't cover the > case where a root points to some part of a pdumper object that is not at > the object's start. I added a FIXME about this. Perhaps Daniel can take > a look at it sometime. I think the remaining bug will be hit only rarely > (if ever). > > The second attached patch is in the same area, but is not part of the > fix. It causes the GC to be a bit more accurate (i.e., less > conservative) for roots, which can help avoid some leaks. Thanks, but these changes don't cater to 32-bit builds --with-wide-int: CC alloc.o In file included from alloc.c:33: alloc.c: In function 'mark_maybe_pointer': lisp.h:251:18: warning: unsigned conversion from 'long long int' to 'uintptr_t' {aka 'unsigned int'} changes value from '2305843009213693951' to '4294967295' [-Woverflow] 251 | # define VALMASK (USE_LSB_TAG ? - (1 << GCTYPEBITS) : VAL_MAX) | ^ alloc.c:4767:24: note: in expansion of macro 'VALMASK' 4767 | uintptr_t mask = VALMASK; | ^~~~~~~ From debbugs-submit-bounces@debbugs.gnu.org Sun Jul 11 07:33:11 2021 Received: (at 49261) by debbugs.gnu.org; 11 Jul 2021 11:33:11 +0000 Received: from localhost ([127.0.0.1]:33996 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m2Xhv-0006do-E0 for submit@debbugs.gnu.org; Sun, 11 Jul 2021 07:33:11 -0400 Received: from quimby.gnus.org ([95.216.78.240]:37528) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m2Xht-0006da-CJ for 49261@debbugs.gnu.org; Sun, 11 Jul 2021 07:33:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=Yv+bWi+irvk6Uw+UKaLW+2dghkTqcXQvJNURzuwOhdA=; b=KInfVgN3upeaPZ86xdKOXGaMyf UYXY9yDAtfbJ01r0EBenczzdR73gVTmxzlQRn65/7eRMlb7sZUEov7f1ajTRTaoV/+jBsOhojbngl 2v3hUJRrjEnJIcCvSRgr5L1GO6iHV8tRjVF67LjYtD0F//umZH49pz/4pdgY+sEQUtFM=; Received: from cm-84.212.220.105.getinternet.no ([84.212.220.105] helo=elva) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m2Xhg-0002AN-Fd; Sun, 11 Jul 2021 13:33:02 +0200 From: Lars Ingebrigtsen To: Paul Eggert Subject: Re: Segfault during loadup References: <87o8bn7bie.fsf@gnus.org> <87zgv6vuon.fsf@gmx.de> <837di9lwbm.fsf@gnu.org> <87a6n5vuu4.fsf@gnus.org> <8735sqnmei.fsf@gnus.org> <87zguyf4ht.fsf@gmx.de> <87pmvum54p.fsf@gnus.org> <87v95mf2lj.fsf@gmx.de> <87pmvt3ob1.fsf@gnus.org> <83r1g9evoy.fsf@gnu.org> <83pmvtevgg.fsf@gnu.org> <87czrt3mj4.fsf@gnus.org> <878s2h3m1d.fsf@gnus.org> <874kd53lnl.fsf@gnus.org> <87zgux26ab.fsf@gnus.org> <87pmvt25uq.fsf@gnus.org> <87lf6h2294.fsf@gnus.org> <87h7h51x9y.fsf_-_@gnus.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAALVBMVEUQDQwgHRxBPj0v LSyPjYxvbGshIB6hn51NTEvBv761s7L6+fnQ0M6Bf33////E5CGhAAAAAWJLR0QOb70wTwAAAAd0 SU1FB+UHCwsdDWL0hMAAAAEHSURBVDjLY2AYnIARRDAJYJdhZHbEIgFW7AqlMWTSHeBqUI3jmIzD dualCZgSYANCsbkLBISbcUikuDNil+CqMMAuw7E0DGIZczCaZ0LAPmFgXtWAKpGQtRiscXUAuvfZ jwAtYZ29hVEQ3ZJVBgwsp3cvQLc8dXF0W+vq3XvQ/dm+e6v1ntO7d6HZzNCze/f27t27jxigGR8R PWtKdM/uqRjm3GgWYOgOdUa3l22JmgADY/UEeBzAQGsgiLy9GV2DKFicIWcLugTURhYML8CcttsB uwTD6m04JGy24pBg2YNDgm12A4YYxFvdC3BoYd2MQ4JhOi4JLgMcEhwBuLSE4ZJIZhjkAAD1ITez DQxRlAAAACV0RVh0ZGF0ZTpjcmVhdGUAMjAyMS0wNy0xMVQxMToyOToxMyswMDowMGHmY1AAAAAl dEVYdGRhdGU6bW9kaWZ5ADIwMjEtMDctMTFUMTE6Mjk6MTMrMDA6MDAQu9vsAAAAAElFTkSuQmCC X-Now-Playing: Burial's _Tunes 2011-2019 (1)_: "Night Market" Date: Sun, 11 Jul 2021 13:32:55 +0200 In-Reply-To: (Paul Eggert's message of "Sun, 11 Jul 2021 01:36:21 -0700") Message-ID: <87wnpxkrvc.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Paul Eggert writes: > I worked around this particular problem changing mark_maybe_pointer so > that pdumper roots can also be tagged (see first attached > patch). Thanks; I can confirm that I can no longer reproduce the crash after this patch. Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49261 Cc: Eli Zaretskii , 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Paul Eggert writes: > I worked around this particular problem changing mark_maybe_pointer so > that pdumper roots can also be tagged (see first attached > patch). Thanks; I can confirm that I can no longer reproduce the crash after this patch. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Sun Jul 11 11:25:39 2021 Received: (at 49261) by debbugs.gnu.org; 11 Jul 2021 15:25:39 +0000 Received: from localhost ([127.0.0.1]:35734 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m2bKs-0004Nl-Vn for submit@debbugs.gnu.org; Sun, 11 Jul 2021 11:25:39 -0400 Received: from eggs.gnu.org ([209.51.188.92]:41534) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m2bKo-0004NV-IC for 49261@debbugs.gnu.org; Sun, 11 Jul 2021 11:25:37 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:49936) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m2bKi-0002wZ-G0; Sun, 11 Jul 2021 11:25:28 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:1219 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m2bKZ-00077o-Qz; Sun, 11 Jul 2021 11:25:28 -0400 Date: Sun, 11 Jul 2021 18:25:09 +0300 Message-Id: <835yxgc1pm.fsf@gnu.org> From: Eli Zaretskii To: eggert@cs.ucla.edu In-Reply-To: <83bl79b17n.fsf@gnu.org> (message from Eli Zaretskii on Sun, 11 Jul 2021 13:21:16 +0300) Subject: Re: bug#49261: Segfault during loadup References: <87o8bn7bie.fsf@gnus.org> <87zgv6vuon.fsf@gmx.de> <837di9lwbm.fsf@gnu.org> <87a6n5vuu4.fsf@gnus.org> <8735sqnmei.fsf@gnus.org> <87zguyf4ht.fsf@gmx.de> <87pmvum54p.fsf@gnus.org> <87v95mf2lj.fsf@gmx.de> <87pmvt3ob1.fsf@gnus.org> <83r1g9evoy.fsf@gnu.org> <83pmvtevgg.fsf@gnu.org> <87czrt3mj4.fsf@gnus.org> <878s2h3m1d.fsf@gnus.org> <874kd53lnl.fsf@gnus.org> <87zgux26ab.fsf@gnus.org> <87pmvt25uq.fsf@gnus.org> <87lf6h2294.fsf@gnus.org> <87h7h51x9y.fsf_-_@gnus.org> <83bl79b17n.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49261 Cc: larsi@gnus.org, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Sun, 11 Jul 2021 13:21:16 +0300 > From: Eli Zaretskii > Cc: larsi@gnus.org, 49261@debbugs.gnu.org > > Thanks, but these changes don't cater to 32-bit builds --with-wide-int: > > CC alloc.o > In file included from alloc.c:33: > alloc.c: In function 'mark_maybe_pointer': > lisp.h:251:18: warning: unsigned conversion from 'long long int' to 'uintptr_t' {aka 'unsigned int'} changes value from '2305843009213693951' to '4294967295' [-Woverflow] > 251 | # define VALMASK (USE_LSB_TAG ? - (1 << GCTYPEBITS) : VAL_MAX) > | ^ > alloc.c:4767:24: note: in expansion of macro 'VALMASK' > 4767 | uintptr_t mask = VALMASK; > | ^~~~~~~ I tried to fix this on master, please take a look. From debbugs-submit-bounces@debbugs.gnu.org Mon Jul 12 03:16:18 2021 Received: (at 49261) by debbugs.gnu.org; 12 Jul 2021 07:16:18 +0000 Received: from localhost ([127.0.0.1]:36429 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m2qAr-00064Y-P0 for submit@debbugs.gnu.org; Mon, 12 Jul 2021 03:16:18 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:43640) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m2qAp-00064H-6V for 49261@debbugs.gnu.org; Mon, 12 Jul 2021 03:16:17 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id C14B2160064; Mon, 12 Jul 2021 00:16:09 -0700 (PDT) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 2n9fMW0K0avb; Mon, 12 Jul 2021 00:16:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id B3F1B16006F; Mon, 12 Jul 2021 00:16:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id khvVJkWDeXf1; Mon, 12 Jul 2021 00:16:07 -0700 (PDT) Received: from [192.168.1.9] (cpe-172-91-119-151.socal.res.rr.com [172.91.119.151]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 7B95D160064; Mon, 12 Jul 2021 00:16:07 -0700 (PDT) To: Eli Zaretskii References: <87o8bn7bie.fsf@gnus.org> <87zgv6vuon.fsf@gmx.de> <837di9lwbm.fsf@gnu.org> <87a6n5vuu4.fsf@gnus.org> <8735sqnmei.fsf@gnus.org> <87zguyf4ht.fsf@gmx.de> <87pmvum54p.fsf@gnus.org> <87v95mf2lj.fsf@gmx.de> <87pmvt3ob1.fsf@gnus.org> <83r1g9evoy.fsf@gnu.org> <83pmvtevgg.fsf@gnu.org> <87czrt3mj4.fsf@gnus.org> <878s2h3m1d.fsf@gnus.org> <874kd53lnl.fsf@gnus.org> <87zgux26ab.fsf@gnus.org> <87pmvt25uq.fsf@gnus.org> <87lf6h2294.fsf@gnus.org> <87h7h51x9y.fsf_-_@gnus.org> <83bl79b17n.fsf@gnu.org> <835yxgc1pm.fsf@gnu.org> From: Paul Eggert Organization: UCLA Computer Science Department Subject: Re: bug#49261: Segfault during loadup Message-ID: Date: Mon, 12 Jul 2021 00:16:07 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <835yxgc1pm.fsf@gnu.org> Content-Type: multipart/mixed; boundary="------------F8EEEB1413B5AA2A495BA107" Content-Language: en-US X-Spam-Score: -2.9 (--) X-Debbugs-Envelope-To: 49261 Cc: larsi@gnus.org, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.9 (---) This is a multi-part message in MIME format. --------------F8EEEB1413B5AA2A495BA107 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable On 7/11/21 8:25 AM, Eli Zaretskii wrote: >> lisp.h:251:18: warning: unsigned conversion from 'long long int' to= 'uintptr_t' {aka 'unsigned int'} changes value from '2305843009213693951= ' to '4294967295' [-Woverflow] >> 251 | # define VALMASK (USE_LSB_TAG ? - (1 << GCTYPEBITS) : VAL_M= AX) >> | ^ >> alloc.c:4767:24: note: in expansion of macro 'VALMASK' >> 4767 | uintptr_t mask =3D VALMASK; >> | ^~~~~~~ > I tried to fix this on master, please take a look. Yes that GCC warning was bogus, and your pacification of GCC is valid=20 now that we no longer tag the MSB of pointers. Still, there should be a=20 simpler way to pacify GCC so I installed a further fix that I hope does=20 that (see first attached patch). This fix simply uses a cast (uintptr_t)=20 VALMASK to pacify GCC; if GCC issues a bogus warning even for that cast,=20 we could substitute (uintptr_t) (VALMASK & UINTPTR_MAX) though this is=20 starting to get a little ridiculous. The version of GCC that I tried (11.1.1 20210531 (Red Hat 11.1.1-3))=20 don't warn about the original code, so perhaps the bogus warning that=20 you saw is a GCC bug that's been fixed in later GCC versions. However,=20 GCC 11.1.1 does warn about some other stuff so I installed the remaining=20 patches to pacify it. Some of these patches fix real (albeit unlikely)=20 bugs in Emacs. Some work around what are evidently flaws in GCC 11.1.1.=20 Oh well. --------------F8EEEB1413B5AA2A495BA107 Content-Type: text/x-patch; charset=UTF-8; name="0001-Pacify-gcc-Woverflow-more-nicely.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0001-Pacify-gcc-Woverflow-more-nicely.patch" =46rom da2f772fe575b20bff51b49aa5ded2bf15a2c89d Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sun, 11 Jul 2021 23:54:32 -0700 Subject: [PATCH 1/5] Pacify gcc -Woverflow more nicely * src/alloc.c (mark_maybe_pointer): Simplify pacification of gcc -Woverflow (unknown GCC version). --- src/alloc.c | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/src/alloc.c b/src/alloc.c index e3b038c51c..ee3fd64a00 100644 --- a/src/alloc.c +++ b/src/alloc.c @@ -4764,12 +4764,7 @@ mark_maybe_pointer (void *p, bool symbol_only) from Emacs source code, it can occur in some cases. To fix this problem, the pdumper code should grok non-initial addresses, as the non-pdumper code does. */ -#ifdef WIDE_EMACS_INT - uintptr_t mask =3D ~((uintptr_t) 0); -#else - uintptr_t mask =3D VALMASK; -#endif - void *po =3D (void *) ((uintptr_t) p & mask); + void *po =3D (void *) ((uintptr_t) p & (uintptr_t) VALMASK); char *cp =3D p; char *cpo =3D po; /* Don't use pdumper_object_p_precise here! It doesn't check the --=20 2.30.2 --------------F8EEEB1413B5AA2A495BA107 Content-Type: text/x-patch; charset=UTF-8; name="0002-Pacify-gcc-11.1.1-Wanalyzer-null-argument.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0002-Pacify-gcc-11.1.1-Wanalyzer-null-argument.patch" =46rom 2337869fbf8b967eb53ee57f978f3751987e43dc Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Mon, 12 Jul 2021 00:00:20 -0700 Subject: [PATCH 2/5] Pacify gcc 11.1.1 -Wanalyzer-null-argument MIME-Version: 1.0 Content-Type: text/plain; charset=3DUTF-8 Content-Transfer-Encoding: 8bit * lib-src/etags.c (regexp): Omit member force_explicit_name, since it=E2=80=99s always true. All uses removed. This lets us remove calls to strlen (name) where GCC isn=E2=80=99t smart enough to deduce that name must be nonnull. * lib-src/movemail.c (main): Fix bug that could cause link (tempname, NULL) to be called. * src/emacs.c (argmatch): Break check into two =E2=80=98if=E2=80=99s, since GCC doesn=E2=80=99t seem to be smart enough to check the single =E2= =80=98if=E2=80=99. * src/gtkutil.c (xg_update_menu_item): Fix bug where strcmp could be given a NULL arg. * src/xfont.c (xfont_list_family): Use nonnull value for dummy initial value. --- lib-src/etags.c | 49 ++++++++++++++++++---------------------------- lib-src/movemail.c | 14 +++++-------- src/emacs.c | 4 +++- src/gtkutil.c | 2 +- src/xfont.c | 5 ++++- 5 files changed, 32 insertions(+), 42 deletions(-) diff --git a/lib-src/etags.c b/lib-src/etags.c index c39c93db33..88b49f803e 100644 --- a/lib-src/etags.c +++ b/lib-src/etags.c @@ -340,7 +340,6 @@ #define xrnew(op, n, m) ((op) =3D xnrealloc (op, n, (= m) * sizeof *(op))) struct re_pattern_buffer *pat; /* the compiled pattern */ struct re_registers regs; /* re registers */ bool error_signaled; /* already signaled for this regexp */ - bool force_explicit_name; /* do not allow implicit tag name */ bool ignore_case; /* ignore case when matching */ bool multi_line; /* do a multi-line match on the whole file */ } regexp; @@ -6910,7 +6909,6 @@ add_regex (char *regexp_pattern, language *lang) struct re_pattern_buffer *patbuf; regexp *rp; bool - force_explicit_name =3D true, /* do not use implicit tag names */ ignore_case =3D false, /* case is significant */ multi_line =3D false, /* matches are done one line at a time */ single_line =3D false; /* dot does not match newline */ @@ -6949,7 +6947,8 @@ add_regex (char *regexp_pattern, language *lang) case 'N': if (modifiers =3D=3D name) error ("forcing explicit tag name but no name, ignoring"); - force_explicit_name =3D true; + /* This option has no effect and is present only for backward + compatibility. */ break; case 'i': ignore_case =3D true; @@ -7004,7 +7003,6 @@ add_regex (char *regexp_pattern, language *lang) p_head->pat =3D patbuf; p_head->name =3D savestr (name); p_head->error_signaled =3D false; - p_head->force_explicit_name =3D force_explicit_name; p_head->ignore_case =3D ignore_case; p_head->multi_line =3D multi_line; } @@ -7144,20 +7142,15 @@ regex_tag_multiline (void) name =3D NULL; else /* make a named tag */ name =3D substitute (buffer, rp->name, &rp->regs); - if (rp->force_explicit_name) - { - /* Force explicit tag name, if a name is there. */ - pfnote (name, true, buffer + linecharno, - charno - linecharno + 1, lineno, linecharno); - - if (debug) - fprintf (stderr, "%s on %s:%"PRIdMAX": %s\n", - name ? name : "(unnamed)", curfdp->taggedfname, - lineno, buffer + linecharno); - } - else - make_tag (name, strlen (name), true, buffer + linecharno, - charno - linecharno + 1, lineno, linecharno); + + /* Force explicit tag name, if a name is there. */ + pfnote (name, true, buffer + linecharno, + charno - linecharno + 1, lineno, linecharno); + + if (debug) + fprintf (stderr, "%s on %s:%"PRIdMAX": %s\n", + name ? name : "(unnamed)", curfdp->taggedfname, + lineno, buffer + linecharno); break; } } @@ -7471,18 +7464,14 @@ readline (linebuffer *lbp, FILE *stream) name =3D NULL; else /* make a named tag */ name =3D substitute (lbp->buffer, rp->name, &rp->regs); - if (rp->force_explicit_name) - { - /* Force explicit tag name, if a name is there. */ - pfnote (name, true, lbp->buffer, match, lineno, linecharno); - if (debug) - fprintf (stderr, "%s on %s:%"PRIdMAX": %s\n", - name ? name : "(unnamed)", curfdp->taggedfname, - lineno, lbp->buffer); - } - else - make_tag (name, strlen (name), true, - lbp->buffer, match, lineno, linecharno); + + /* Force explicit tag name, if a name is there. */ + pfnote (name, true, lbp->buffer, match, lineno, linecharno); + + if (debug) + fprintf (stderr, "%s on %s:%"PRIdMAX": %s\n", + name ? name : "(unnamed)", curfdp->taggedfname, + lineno, lbp->buffer); break; } } diff --git a/lib-src/movemail.c b/lib-src/movemail.c index cfdebccb8d..e683da179d 100644 --- a/lib-src/movemail.c +++ b/lib-src/movemail.c @@ -270,6 +270,7 @@ main (int argc, char **argv) You might also wish to verify that your system is one which uses lock files for this purpose. Some systems use other methods. */= =20 + bool lockname_unlinked =3D false; inname_len =3D strlen (inname); lockname =3D xmalloc (inname_len + sizeof ".lock"); strcpy (lockname, inname); @@ -312,15 +313,10 @@ main (int argc, char **argv) Five minutes should be good enough to cope with crashes and wedgitude, and long enough to avoid being fooled by time differences between machines. */ - if (stat (lockname, &st) >=3D 0) - { - time_t now =3D time (0); - if (st.st_ctime < now - 300) - { - unlink (lockname); - lockname =3D 0; - } - } + if (!lockname_unlinked + && stat (lockname, &st) =3D=3D 0 + && st.st_ctime < time (0) - 300) + lockname_unlinked =3D unlink (lockname) =3D=3D 0 || errno =3D=3D EN= OENT; } =20 delete_lockname =3D lockname; diff --git a/src/emacs.c b/src/emacs.c index b7982ece64..866e43fda9 100644 --- a/src/emacs.c +++ b/src/emacs.c @@ -670,7 +670,9 @@ argmatch (char **argv, int argc, const char *sstr, co= nst char *lstr, } arglen =3D (valptr !=3D NULL && (p =3D strchr (arg, '=3D')) !=3D NULL ? p - arg : strlen (arg)); - if (lstr =3D=3D 0 || arglen < minlen || strncmp (arg, lstr, arglen) !=3D= 0) + if (!lstr) + return 0; + if (arglen < minlen || strncmp (arg, lstr, arglen) !=3D 0) return 0; else if (valptr =3D=3D NULL) { diff --git a/src/gtkutil.c b/src/gtkutil.c index dee2a93089..313cfc82c2 100644 --- a/src/gtkutil.c +++ b/src/gtkutil.c @@ -3221,7 +3221,7 @@ xg_update_menu_item (widget_value *val, gtk_label_set_text (wkey, utf8_key); } =20 - if (! old_label || strcmp (utf8_label, old_label) !=3D 0) + if (utf8_label && (! old_label || strcmp (utf8_label, old_label) !=3D = 0)) { label_changed =3D true; gtk_label_set_text (wlbl, utf8_label); diff --git a/src/xfont.c b/src/xfont.c index 0570ee96a9..81d356175a 100644 --- a/src/xfont.c +++ b/src/xfont.c @@ -596,7 +596,10 @@ xfont_list_family (struct frame *f) char **names; int num_fonts, i; Lisp_Object list; - char *last_family UNINIT; + char const *last_family; +#if defined GCC_LINT || defined lint + last_family =3D ""; +#endif int last_len; =20 block_input (); --=20 2.30.2 --------------F8EEEB1413B5AA2A495BA107 Content-Type: text/x-patch; charset=UTF-8; name="0003-Pacify-gcc-11.1.1-Wanalyzer-possible-null-dereferenc.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename*0="0003-Pacify-gcc-11.1.1-Wanalyzer-possible-null-dereferenc.pa"; filename*1="tch" =46rom 1a0fe2a5184cd4c57972994cf4b688042aecc534 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Mon, 12 Jul 2021 00:06:34 -0700 Subject: [PATCH 3/5] Pacify gcc 11.1.1 -Wanalyzer-possible-null-dereferen= ce MIME-Version: 1.0 Content-Type: text/plain; charset=3DUTF-8 Content-Transfer-Encoding: 8bit * oldXMenu/Create.c (XMenuCreate): * oldXMenu/Internal.c (_XMRecomputePane, _XMRecomputeSelection): * oldXMenu/XMakeAssoc.c (XMakeAssoc): * test/src/emacs-module-resources/mod-test.c (Fmod_test_userptr_make): Don=E2=80=99t assume that malloc and calloc succeed. --- oldXMenu/Create.c | 2 ++ oldXMenu/Internal.c | 31 +++++++++------------- oldXMenu/XMakeAssoc.c | 2 ++ test/src/emacs-module-resources/mod-test.c | 4 +++ 4 files changed, 20 insertions(+), 19 deletions(-) diff --git a/oldXMenu/Create.c b/oldXMenu/Create.c index 7eb17c508d..e209bbecee 100644 --- a/oldXMenu/Create.c +++ b/oldXMenu/Create.c @@ -598,6 +598,8 @@ XMenuCreate(Display *display, Window parent, register= char const *def_env) * Create pane, active, and inactive GC's. */ values =3D (XGCValues *)malloc(sizeof(XGCValues)); + if (!values) + return NULL; valuemask =3D (GCForeground | GCBackground | GCFont | GCLineWidth); =20 /* diff --git a/oldXMenu/Internal.c b/oldXMenu/Internal.c index f489e27bea..3e97f9ab3f 100644 --- a/oldXMenu/Internal.c +++ b/oldXMenu/Internal.c @@ -534,7 +534,6 @@ _XMRecomputePane(register Display *display, register = XMenu *menu, register XMPan register int window_y; /* Recomputed window Y coordinate. */ =20 unsigned long change_mask; /* Value mask to reconfigure window. */ - XWindowChanges *changes; /* Values to use in configure window. */ =20 register Bool config_p =3D False; /* Reconfigure pane window? */ =20 @@ -612,21 +611,19 @@ _XMRecomputePane(register Display *display, registe= r XMenu *menu, register XMPan * it for creation with the new configuration. */ if (p_ptr->window) { + XWindowChanges changes; change_mask =3D (CWX | CWY | CWWidth | CWHeight); - changes =3D (XWindowChanges *)malloc(sizeof(XWindowChanges)); - changes->x =3D p_ptr->window_x; - changes->y =3D p_ptr->window_y; - changes->width =3D p_ptr->window_w; - changes->height =3D p_ptr->window_h; + changes.x =3D p_ptr->window_x; + changes.y =3D p_ptr->window_y; + changes.width =3D p_ptr->window_w; + changes.height =3D p_ptr->window_h; =20 XConfigureWindow( display, p_ptr->window, change_mask, - changes + &changes ); - free(changes); - } else { if (_XMWinQueAddPane(display, menu, p_ptr) =3D=3D _FAILURE) { @@ -681,7 +678,6 @@ _XMRecomputeSelection(register Display *display, regi= ster XMenu *menu, register /* Selection sequence number. */ { register Bool config_s =3D False; /* Reconfigure selection window? *= / - XWindowChanges *changes; /* Values to change in configure. */ unsigned long change_mask; /* Value mask for XConfigureWindow. */ =20 /* @@ -738,22 +734,19 @@ _XMRecomputeSelection(register Display *display, re= gister XMenu *menu, register * for creation with the new configuration. */ if (s_ptr->window) { - changes =3D (XWindowChanges *)malloc(sizeof(XWindowChanges)); + XWindowChanges changes; change_mask =3D (CWX | CWY | CWWidth | CWHeight); - changes =3D (XWindowChanges *)malloc(sizeof(XWindowChanges)); - changes->x =3D s_ptr->window_x; - changes->y =3D s_ptr->window_y; - changes->width =3D s_ptr->window_w; - changes->height =3D s_ptr->window_h; + changes.x =3D s_ptr->window_x; + changes.y =3D s_ptr->window_y; + changes.width =3D s_ptr->window_w; + changes.height =3D s_ptr->window_h; =20 XConfigureWindow( display, s_ptr->window, change_mask, - changes + &changes ); - free(changes); - } else { if (_XMWinQueAddSelection(display, menu, s_ptr) =3D=3D _FAILURE) { diff --git a/oldXMenu/XMakeAssoc.c b/oldXMenu/XMakeAssoc.c index 9bbde2cf94..2530e8e507 100644 --- a/oldXMenu/XMakeAssoc.c +++ b/oldXMenu/XMakeAssoc.c @@ -69,6 +69,8 @@ XMakeAssoc(register Display *dpy, register XAssocTable = *table, register XID x_id /* before the current value of "Entry". */ /* Create a new XAssoc and load it with new provided data. */ new_entry =3D (XAssoc *) malloc(sizeof(XAssoc)); + if (!new_entry) + return; /* This obsolete API has no way to report failure! */ new_entry->display =3D dpy; new_entry->x_id =3D x_id; new_entry->data =3D data; diff --git a/test/src/emacs-module-resources/mod-test.c b/test/src/emacs-= module-resources/mod-test.c index ad59cfc18c..5720af8c60 100644 --- a/test/src/emacs-module-resources/mod-test.c +++ b/test/src/emacs-module-resources/mod-test.c @@ -288,6 +288,8 @@ Fmod_test_return_unibyte (emacs_env *env, ptrdiff_t n= args, emacs_value args[], char large_unused_buffer[512]; }; =20 +static void signal_errno (emacs_env *, char const *); + /* Return a new user-pointer to a super_struct, with amazing_int set to the passed parameter. */ static emacs_value @@ -295,6 +297,8 @@ Fmod_test_userptr_make (emacs_env *env, ptrdiff_t nar= gs, emacs_value args[], void *data) { struct super_struct *p =3D calloc (1, sizeof *p); + if (!p) + signal_errno (env, "calloc"); p->amazing_int =3D env->extract_integer (env, args[0]); return env->make_user_ptr (env, free, p); } --=20 2.30.2 --------------F8EEEB1413B5AA2A495BA107 Content-Type: text/x-patch; charset=UTF-8; name="0004-Pacify-gcc-11.1.1-Wclobbered.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0004-Pacify-gcc-11.1.1-Wclobbered.patch" =46rom c22cf4d02ff7ebd85839aac5336f6e279f32db54 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Mon, 12 Jul 2021 00:07:38 -0700 Subject: [PATCH 4/5] Pacify gcc 11.1.1 -Wclobbered * src/eval.c (Fprogn, internal_lisp_condition_case): Add CACHEABLE to work around more instances of -Wclobbered bug. --- src/eval.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/eval.c b/src/eval.c index 18faa0b9b1..b76ced79d6 100644 --- a/src/eval.c +++ b/src/eval.c @@ -462,7 +462,7 @@ DEFUN ("progn", Fprogn, Sprogn, 0, UNEVALLED, 0, usage: (progn BODY...) */) (Lisp_Object body) { - Lisp_Object val =3D Qnil; + Lisp_Object CACHEABLE val =3D Qnil; =20 while (CONSP (body)) { @@ -1429,7 +1429,7 @@ internal_lisp_condition_case (Lisp_Object var, Lisp= _Object bodyform, } } =20 - Lisp_Object result =3D eval_sub (bodyform); + Lisp_Object CACHEABLE result =3D eval_sub (bodyform); handlerlist =3D oldhandlerlist; if (!NILP (success_handler)) { --=20 2.30.2 --------------F8EEEB1413B5AA2A495BA107 Content-Type: text/x-patch; charset=UTF-8; name="0005-Port-test-module-to-glibc-2.33.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0005-Port-test-module-to-glibc-2.33.patch" =46rom a79c578f3d77101964b837e8fa8b8109f21c7a88 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Mon, 12 Jul 2021 00:11:22 -0700 Subject: [PATCH 5/5] Port test module to glibc 2.33 * test/Makefile.in (REPLACE_FREE, FREE_SOURCE_0, FREE_SOURCE_1): New macros. ($(test_module)): Improve accuracy of test as to whether free.c should be compiled; glibc 2.33 does not need it compiled and the compilation breaks if you try, if you build with --enable-gcc-warnings. --- test/Makefile.in | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/test/Makefile.in b/test/Makefile.in index c1518d3dcd..7047c24482 100644 --- a/test/Makefile.in +++ b/test/Makefile.in @@ -49,6 +49,8 @@ SEPCHAR =3D =20 HAVE_NATIVE_COMP =3D @HAVE_NATIVE_COMP@ =20 +REPLACE_FREE =3D @REPLACE_FREE@ + -include ${top_builddir}/src/verbose.mk =20 # Load any GNU ELPA dependencies that are present, for optional tests. @@ -274,6 +276,9 @@ MODULE_CFLAGS =3D test_module =3D $(test_module_dir)/mod-test${SO} src/emacs-module-tests.log src/emacs-module-tests.elc: $(test_module) =20 +FREE_SOURCE_0 =3D +FREE_SOURCE_1 =3D $(srcdir)/../lib/free.c + # In the compilation command, we can't use any object or archive file # as source because those are not compiled with -fPIC. Therefore we # use only source files. @@ -282,7 +287,7 @@ $(test_module): $(test_module: $(AM_V_CCLD)$(CC) -shared $(CPPFLAGS) $(MODULE_CFLAGS) $(LDFLAGS) \ -o $@ $< $(LIBGMP) \ $(and $(GMP_H),$(srcdir)/../lib/mini-gmp-gnulib.c) \ - $(if $(OMIT_GNULIB_MODULE_free-posix),,$(srcdir)/../lib/free.c) \ + $(FREE_SOURCE_$(REPLACE_FREE)) \ $(srcdir)/../lib/timespec.c $(srcdir)/../lib/gettime.c endif =20 --=20 2.30.2 --------------F8EEEB1413B5AA2A495BA107-- From debbugs-submit-bounces@debbugs.gnu.org Mon Jul 12 08:07:49 2021 Received: (at 49261) by debbugs.gnu.org; 12 Jul 2021 12:07:49 +0000 Received: from localhost ([127.0.0.1]:36683 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m2uiy-00070K-NR for submit@debbugs.gnu.org; Mon, 12 Jul 2021 08:07:48 -0400 Received: from eggs.gnu.org ([209.51.188.92]:38482) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m2uix-000708-Ix for 49261@debbugs.gnu.org; Mon, 12 Jul 2021 08:07:48 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:48740) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m2uir-0007ef-A4; Mon, 12 Jul 2021 08:07:41 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:1520 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m2uiq-0000z3-UJ; Mon, 12 Jul 2021 08:07:41 -0400 Date: Mon, 12 Jul 2021 15:07:32 +0300 Message-Id: <83wnpvag6z.fsf@gnu.org> From: Eli Zaretskii To: Paul Eggert In-Reply-To: (message from Paul Eggert on Mon, 12 Jul 2021 00:16:07 -0700) Subject: Re: bug#49261: Segfault during loadup References: <87o8bn7bie.fsf@gnus.org> <87zgv6vuon.fsf@gmx.de> <837di9lwbm.fsf@gnu.org> <87a6n5vuu4.fsf@gnus.org> <8735sqnmei.fsf@gnus.org> <87zguyf4ht.fsf@gmx.de> <87pmvum54p.fsf@gnus.org> <87v95mf2lj.fsf@gmx.de> <87pmvt3ob1.fsf@gnus.org> <83r1g9evoy.fsf@gnu.org> <83pmvtevgg.fsf@gnu.org> <87czrt3mj4.fsf@gnus.org> <878s2h3m1d.fsf@gnus.org> <874kd53lnl.fsf@gnus.org> <87zgux26ab.fsf@gnus.org> <87pmvt25uq.fsf@gnus.org> <87lf6h2294.fsf@gnus.org> <87h7h51x9y.fsf_-_@gnus.org> <83bl79b17n.fsf@gnu.org> <835yxgc1pm.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49261 Cc: larsi@gnus.org, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: larsi@gnus.org, 49261@debbugs.gnu.org > From: Paul Eggert > Date: Mon, 12 Jul 2021 00:16:07 -0700 > > >> lisp.h:251:18: warning: unsigned conversion from 'long long int' to 'uintptr_t' {aka 'unsigned int'} changes value from '2305843009213693951' to '4294967295' [-Woverflow] > >> 251 | # define VALMASK (USE_LSB_TAG ? - (1 << GCTYPEBITS) : VAL_MAX) > >> | ^ > >> alloc.c:4767:24: note: in expansion of macro 'VALMASK' > >> 4767 | uintptr_t mask = VALMASK; > >> | ^~~~~~~ > > I tried to fix this on master, please take a look. > > Yes that GCC warning was bogus, and your pacification of GCC is valid Hmm... is it really a bogus warning? VALMASK is a 64-bit value, and uintptr_t is 32-bit wide. > now that we no longer tag the MSB of pointers. Still, there should be a > simpler way to pacify GCC so I installed a further fix that I hope does > that (see first attached patch). This fix simply uses a cast (uintptr_t) > VALMASK to pacify GCC; if GCC issues a bogus warning even for that cast, > we could substitute (uintptr_t) (VALMASK & UINTPTR_MAX) though this is > starting to get a little ridiculous. Your fix compiles cleanly, thanks. From debbugs-submit-bounces@debbugs.gnu.org Mon Jul 12 09:53:23 2021 Received: (at 49261) by debbugs.gnu.org; 12 Jul 2021 13:53:23 +0000 Received: from localhost ([127.0.0.1]:36874 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m2wN9-0003U7-AG for submit@debbugs.gnu.org; Mon, 12 Jul 2021 09:53:23 -0400 Received: from mout.gmx.net ([212.227.15.18]:39883) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m2wN7-0003Tu-K1 for 49261@debbugs.gnu.org; Mon, 12 Jul 2021 09:53:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1626097994; bh=3uHBkx/kFhbqu2OVv2nYSD+vTCjTiDnfYy8AMajYYLg=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=X5m++wgukr/gLE782Hy0BEG4Quu95n8dmeVM6+/tiJIYM+lXG92psKCJ/OY23FsIo KP4D37H1tviT9tO5B2YagdZntdzLpq07aVeCQcKsq4iqTvVUclTMPV7xJ9FGeS7ov9 Br2gFTJryKvz+SsItpwnFDJcj9W7Bs4t5NdqDeTE= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from gandalf.gmx.de ([213.220.146.224]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MMGN2-1lkjGO1aRq-00JG1S; Mon, 12 Jul 2021 15:53:14 +0200 From: Michael Albinus To: Lars Ingebrigtsen Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: <87o8bn7bie.fsf@gnus.org> <87zgv6vuon.fsf@gmx.de> <837di9lwbm.fsf@gnu.org> <87a6n5vuu4.fsf@gnus.org> <8735sqnmei.fsf@gnus.org> <87zguyf4ht.fsf@gmx.de> <87pmvum54p.fsf@gnus.org> <87v95mf2lj.fsf@gmx.de> <87pmvt3ob1.fsf@gnus.org> <87fswpgacv.fsf@gmx.de> <87bl7dfikj.fsf@gmx.de> <8735sofuqj.fsf@gmx.de> <83sg0oc83l.fsf@gnu.org> <87v95jevrm.fsf@gmx.de> <83lf6fdav4.fsf@gnu.org> <87r1g7eoor.fsf@gmx.de> <87im1jphyy.fsf@gnus.org> Date: Mon, 12 Jul 2021 15:53:12 +0200 In-Reply-To: <87im1jphyy.fsf@gnus.org> (Lars Ingebrigtsen's message of "Fri, 09 Jul 2021 18:31:01 +0200") Message-ID: <87im1fd4fr.fsf@gmx.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:UOON3LTpFE8IVDK2jTUmVUVLgLgL13ZxM3cwYRm1JV0fgey5GrM +ev1J64yLwgZSE+Wyh5GnAtnOrnOMVErUtvgcfKM7Jho9z4+3vnUtFTiYzusZYVplFgFrJ+ +2vWyZXJTNwk1nL4YTMcdODmBfxzndtMkpHPSKp1zReI6dX6kUufo4iTAuOm8gbjJ9qLcLC dorzyQyIhQw14rg6z94xA== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:UJjGsGyQ99M=:de5C1cvLhock3An7NeRWKJ lPmXAroxLbSUzWe0wlf6QABY9f86vxfAkeC+8q/SD4FSPvn+LO2d0OaxLqKqpQEduCVlvidvL NKbaP0sDhjksuQkFHmKtRuWToXcg0oud7TYewS8vzjH7rB76tjVgSgiIysHcb1qqnHXg8bUXY 7XIy2oPmfyezyt/FmuI+kLLmHV0l+bh+yyO9XKiKk171ErvLtH6OTXyoVpcsWrKbal398U37e 7OvNllfJGHXzv0HCX5T03PcIYHfLMQXKIsP8iPDerGt2VLYSRLBjHofOiwMt4O1B4cSWH/4w3 YTnL4f6hHO2Um00pND8G4WkNkbkCxPBVYBLEvzhZSL+CLC9vyNOSOZo9A5mhKaC91UMk8bzBV ZkpV1KDOYtOtEQm+VxXF0X61NoG+zg8nTq8OCeV71efxZ2NxEXUpBr2H5D8rFIaOU+0AUW47W ckWNuG6O8lb+XlCE1HlDyxHjEQt4oZcr8h1CUtpt4t0GwSSubw40+Me/+Q+vDUdlBqertY4jt QDl1JjE0zmMmVKD63bc0tbq+s6LWm1DBQnPFqptt2lnuhR45Of0WGGuEhbvdkDUL+mfGgJB2i FaxDAa5GOyHApv/7/FgCajuX+croVdUj6Yo/2zY7m+kOolHhd5gGWBLFDAc8W+QS4b0F20Qic Vmj/rWnArjgse+9+I9XWhB1Sxf7fW6boklgmq36gLN1HdHLIw1bTzv+NL+a6tgyDBN9E+D11J GwHWE1N66i/chcTlGLC0ZTGL2qiXCkKsKlstivrmDb1ZAE2cUSLBm4B5B2LHgkWbcf68dJfVu uflW8puHZhacS2IzxKGsBeryBv8+FhqyKkNJ9Zuuvo4SML7e1XXsORyo3VW4OxBffxARsKVt8 rY6hCsk3GXLaMPPw/7G9EiKg+K8DUO+dvjdxizZowEAKL9qSYQhC0Ll63GDuu/6XmIKfvGpLy vWDrFypdOqPOUcbiCUq1lTfku9GFxFOAFj1YRi2QuyW8nQ3bNWyZMIY7A7qn1XmiaaKdrIJHB ggcMwb+8CH9rRJR0EdbF3O5HeedWWHmoDSAZnZQ/A8KORhKa3N1T2C9IuKthRxweWYGQ9JHJ6 RYkokcln4Dgyboz4R8x44IoVH8dns3lIyjK0B4VcK6bar8nIrVcH444zA== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 49261 Cc: Eli Zaretskii , ncaprisunfan@gmail.com, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Lars Ingebrigtsen writes: >> Until now, there are no file locks for remote files at all. I thought >> disabling it for remote files would be requested by some users for >> backward compatibility. > > Yeah, I think it's a good idea, and allowing REPLACEMENT to be nil seems > like the natural way to implement it. And now? You and Eli disagree in this point, and I don't know what to do. Best regards, Michael. From debbugs-submit-bounces@debbugs.gnu.org Mon Jul 12 10:03:21 2021 Received: (at 49261) by debbugs.gnu.org; 12 Jul 2021 14:03:21 +0000 Received: from localhost ([127.0.0.1]:38607 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m2wWn-0004BA-EC for submit@debbugs.gnu.org; Mon, 12 Jul 2021 10:03:21 -0400 Received: from eggs.gnu.org ([209.51.188.92]:39520) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m2wWm-0004Ay-F7 for 49261@debbugs.gnu.org; Mon, 12 Jul 2021 10:03:21 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:54026) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m2wWg-0006Tt-Sr; Mon, 12 Jul 2021 10:03:14 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:4810 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m2wWg-0000Of-EP; Mon, 12 Jul 2021 10:03:14 -0400 Date: Mon, 12 Jul 2021 17:03:06 +0300 Message-Id: <83sg0jaaud.fsf@gnu.org> From: Eli Zaretskii To: Michael Albinus In-Reply-To: <87im1fd4fr.fsf@gmx.de> (message from Michael Albinus on Mon, 12 Jul 2021 15:53:12 +0200) Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: <87o8bn7bie.fsf@gnus.org> <87zgv6vuon.fsf@gmx.de> <837di9lwbm.fsf@gnu.org> <87a6n5vuu4.fsf@gnus.org> <8735sqnmei.fsf@gnus.org> <87zguyf4ht.fsf@gmx.de> <87pmvum54p.fsf@gnus.org> <87v95mf2lj.fsf@gmx.de> <87pmvt3ob1.fsf@gnus.org> <87fswpgacv.fsf@gmx.de> <87bl7dfikj.fsf@gmx.de> <8735sofuqj.fsf@gmx.de> <83sg0oc83l.fsf@gnu.org> <87v95jevrm.fsf@gmx.de> <83lf6fdav4.fsf@gnu.org> <87r1g7eoor.fsf@gmx.de> <87im1jphyy.fsf@gnus.org> <87im1fd4fr.fsf@gmx.de> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49261 Cc: larsi@gnus.org, ncaprisunfan@gmail.com, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Michael Albinus > Cc: Eli Zaretskii , ncaprisunfan@gmail.com, > 49261@debbugs.gnu.org > Date: Mon, 12 Jul 2021 15:53:12 +0200 > > Lars Ingebrigtsen writes: > > >> Until now, there are no file locks for remote files at all. I thought > >> disabling it for remote files would be requested by some users for > >> backward compatibility. > > > > Yeah, I think it's a good idea, and allowing REPLACEMENT to be nil seems > > like the natural way to implement it. > > And now? You and Eli disagree in this point, and I don't know what to do. Which disagreement between us leaves you at an impasse? If there is indeed such a disagreement, maybe we could find a compromise which will allow some way forward. From debbugs-submit-bounces@debbugs.gnu.org Mon Jul 12 10:37:56 2021 Received: (at 49261) by debbugs.gnu.org; 12 Jul 2021 14:37:56 +0000 Received: from localhost ([127.0.0.1]:38620 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m2x4G-0004y7-Ii for submit@debbugs.gnu.org; Mon, 12 Jul 2021 10:37:56 -0400 Received: from mout.gmx.net ([212.227.15.15]:34769) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m2x4E-0004xu-GQ for 49261@debbugs.gnu.org; Mon, 12 Jul 2021 10:37:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1626100668; bh=I3cQfLsDUKelMp6MNceqDGegZBV7rmGPCMVLGo4LNkw=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=FEQT73C74FlrsJVvwnQUfXgGeKvdEnkmvrnZ1o7UHGGch2Mye4z17o2XgAr84yovZ iIjqVK6CLWQGdIxPw4v8B7zFXVo89P43Kipa5Q86syWRIk0mgKYmfFgZy/WgZVfMX8 c+qq+uCR8lzvJ2L3aaFPGmPfB49Qjtg0jfaMGQXQ= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from gandalf.gmx.de ([213.220.146.224]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1N9Mta-1l6kGN2EeS-015Jsp; Mon, 12 Jul 2021 16:37:47 +0200 From: Michael Albinus To: Eli Zaretskii Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: <87o8bn7bie.fsf@gnus.org> <87zgv6vuon.fsf@gmx.de> <837di9lwbm.fsf@gnu.org> <87a6n5vuu4.fsf@gnus.org> <8735sqnmei.fsf@gnus.org> <87zguyf4ht.fsf@gmx.de> <87pmvum54p.fsf@gnus.org> <87v95mf2lj.fsf@gmx.de> <87pmvt3ob1.fsf@gnus.org> <87fswpgacv.fsf@gmx.de> <87bl7dfikj.fsf@gmx.de> <8735sofuqj.fsf@gmx.de> <83sg0oc83l.fsf@gnu.org> <87v95jevrm.fsf@gmx.de> <83lf6fdav4.fsf@gnu.org> <87r1g7eoor.fsf@gmx.de> <87im1jphyy.fsf@gnus.org> <87im1fd4fr.fsf@gmx.de> <83sg0jaaud.fsf@gnu.org> Date: Mon, 12 Jul 2021 16:37:45 +0200 In-Reply-To: <83sg0jaaud.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 12 Jul 2021 17:03:06 +0300") Message-ID: <87a6mrd2di.fsf@gmx.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:as5RFJ1W3LNJdkcJo0goVSvI0cSy8e/pETNLdoIhjEczNyRc86x 1Ry7uRmji7CubvoAQoJooDUhILrB1IJ5JVOrYaka9jxYfiDiKTHOLoWFGmg8xemlaXFlfy2 9JElK7C7dHRvnrpmEMdxYL+CZ2+jtOXzKydxhu58eUb1gXvU6bWr6FJuTdY1qbFNWt3/BQd yD0yU007Cee976WtaGtRg== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:Nkq/Q/g/Txc=:ovEfTYXhRaK11hq0UXvbQM ksVHh+n9wfNOCUJ2IlsHbvVsKVrQxqH3hEvtj/k+8FSdQmVzoq7aRSuqvqvpV9dMRQPKFmiX8 sHNAEZ8J2trRtLBwIgdlwHStKVMyZkMinZNHu4O1WLjvPGMSvhO1H4Wu9IefNjzK8cOQzhTna ed072IVTwsCzdnjjKVFMoePWgNlwiZwkeXu7AIe02z+NASG1V0mfVk/eNwuC2Y3AVta9IrFUK NQ8mCnStNDwM9HEaNsY1sRw4jXVpohqgZJiLjB8bmdahpT8iReEZDk3MTkFA99LocmXSA6gLa yokayBCYO3rJioDLJdSDRflbjSq304oEOJf3oYdwAGGpgTSf7UxsUbo7n4He8TwF+5PDGLbIT YV6uil238/nuJSod68zYLgddHCa6IkdKkIA48CeTS7wdgGGHSnkmeYNd8TjwWRdUysymM/asj LvZQFkJiIQ9r4uFZ4Y38gSLw42zd1NHB+8qsCMrMQdM/gHSKc0uNfuN5KR/x5RB9m13XwI2w1 m7iHdLc3+BR50poZ7akLE/pCmiKBXLMFjJBnJd8XXm6ElA+tVUGNtX5iZZODLJPpDiNuW81wM +t91o8mWd3mdiXSmIHgukOB/fnEfWGliY1anxVu2YVLikpSM41s1afHVvRLurQLTKuYfI8ewe 7LKy9xj6oMPV2aZ2xniRBd3bcGjkKRQH47tE1gYeLF7eqKpYHRo7mN2lGM0YvBQswAp2D9cgs ZxS5NKP4DJvpyru3J6Sz3nU3TS2icRjuBKUVlq5OlL8bZ+6AHGoYuFuztTEmCxeS4YYqszgRn UUyl1n0myxviEO/pW34IZ2X9y8KSenajGbzYRRQQb4cajeuZse73xTDHSPUalsx5iOv7Jo5kR mOnYg1IqRZxJ4kwPAj5FaBFNh37Y81vrSBdKz50SE8TNvf5h8E0j5DruhYUa/w0M8I6OZjkS4 cEkmpsybJeuaLT+cG82STN+6ey86AD34pZ37TdRzAcYdvf2EbXy1d12dwl6jqXDuA4treMVjM bjeOWQO+se+UDsiRGNUsnayL/iWFjDz8ZxddUq994MGH4GD4pStqNsQFQ0wQh1Kc51+b2Wglc 4ktAtvpKn2IEF5zIMYallLDZtCHa68ywwcMAC2QBKkbAbvbrqkRQurUQQ== Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 49261 Cc: larsi@gnus.org, ncaprisunfan@gmail.com, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: Hi Eli, >> Lars Ingebrigtsen writes: >> >> >> Until now, there are no file locks for remote files at all. I though= t >> >> disabling it for remote files would be requested by some users for >> >> backward compatibility. >> > >> > Yeah, I think it's a good idea, and allowing REPLACEMENT to be nil se= ems >> > like the natural way to implement it. >> >> And now? You and Eli disagree in this point, and I don't know what to d= o. > > Which disagreement between us leaves you at an impasse? If there is > indeed such a disagreement, maybe we could find a compromise which > will allow some way forward. Lars agrees my proposal to use lock-file-name-transforms for disabling file locks. You did argue against. Best regards, Michael. From debbugs-submit-bounces@debbugs.gnu.org Mon Jul 12 10:50:51 2021 Received: (at 49261) by debbugs.gnu.org; 12 Jul 2021 14:50:51 +0000 Received: from localhost ([127.0.0.1]:38628 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m2xGl-0005GZ-6B for submit@debbugs.gnu.org; Mon, 12 Jul 2021 10:50:51 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:59858) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m2xGj-0005GN-Lk for 49261@debbugs.gnu.org; Mon, 12 Jul 2021 10:50:49 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id BD0A3160060; Mon, 12 Jul 2021 07:50:43 -0700 (PDT) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id Y_oCt-xX9isy; Mon, 12 Jul 2021 07:50:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 22A89160064; Mon, 12 Jul 2021 07:50:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id J6yPDOGOuOYt; Mon, 12 Jul 2021 07:50:43 -0700 (PDT) Received: from [192.168.1.9] (cpe-172-91-119-151.socal.res.rr.com [172.91.119.151]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id F09DC160060; Mon, 12 Jul 2021 07:50:42 -0700 (PDT) Subject: Re: bug#49261: Segfault during loadup To: Eli Zaretskii References: <87o8bn7bie.fsf@gnus.org> <87zgv6vuon.fsf@gmx.de> <837di9lwbm.fsf@gnu.org> <87a6n5vuu4.fsf@gnus.org> <8735sqnmei.fsf@gnus.org> <87zguyf4ht.fsf@gmx.de> <87pmvum54p.fsf@gnus.org> <87v95mf2lj.fsf@gmx.de> <87pmvt3ob1.fsf@gnus.org> <83r1g9evoy.fsf@gnu.org> <83pmvtevgg.fsf@gnu.org> <87czrt3mj4.fsf@gnus.org> <878s2h3m1d.fsf@gnus.org> <874kd53lnl.fsf@gnus.org> <87zgux26ab.fsf@gnus.org> <87pmvt25uq.fsf@gnus.org> <87lf6h2294.fsf@gnus.org> <87h7h51x9y.fsf_-_@gnus.org> <83bl79b17n.fsf@gnu.org> <835yxgc1pm.fsf@gnu.org> <83wnpvag6z.fsf@gnu.org> From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: <5608bf0a-7211-73a9-690f-c869a1cb3c9d@cs.ucla.edu> Date: Mon, 12 Jul 2021 07:50:41 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <83wnpvag6z.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -3.8 (---) X-Debbugs-Envelope-To: 49261 Cc: larsi@gnus.org, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.8 (----) On 7/12/21 5:07 AM, Eli Zaretskii wrote: >> Yes that GCC warning was bogus, and your pacification of GCC is valid > > Hmm... is it really a bogus warning? VALMASK is a 64-bit value, and > uintptr_t is 32-bit wide. It's bogus in the sense that 'uintptr_t mask = VALMASK;' has well-defined behavior in C; there is no undefined behavior there, since VALMASK is an integer and uintptr_t is unsigned. And truncation is what is wanted here, so the warning is bogus. From debbugs-submit-bounces@debbugs.gnu.org Mon Jul 12 10:56:23 2021 Received: (at 49261) by debbugs.gnu.org; 12 Jul 2021 14:56:24 +0000 Received: from localhost ([127.0.0.1]:38632 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m2xM7-0005OU-Ph for submit@debbugs.gnu.org; Mon, 12 Jul 2021 10:56:23 -0400 Received: from mail-out.m-online.net ([212.18.0.10]:41334) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m2xM5-0005OL-UV for 49261@debbugs.gnu.org; Mon, 12 Jul 2021 10:56:22 -0400 Received: from frontend01.mail.m-online.net (unknown [192.168.8.182]) by mail-out.m-online.net (Postfix) with ESMTP id 4GNn041s15z1sGfB; Mon, 12 Jul 2021 16:56:19 +0200 (CEST) Received: from localhost (dynscan1.mnet-online.de [192.168.6.70]) by mail.m-online.net (Postfix) with ESMTP id 4GNn032StPz1r6PF; Mon, 12 Jul 2021 16:56:19 +0200 (CEST) X-Virus-Scanned: amavisd-new at mnet-online.de Received: from mail.mnet-online.de ([192.168.8.182]) by localhost (dynscan1.mail.m-online.net [192.168.6.70]) (amavisd-new, port 10024) with ESMTP id orLSF4u0tfzC; Mon, 12 Jul 2021 16:56:18 +0200 (CEST) X-Auth-Info: gJaBmyQNa3HfOZk3gi3Awz8MTJkUpAWOl1SC5LyfOi18KpgdqOpIv/p3daZxt4wu Received: from igel.home (ppp-46-244-167-56.dynamic.mnet-online.de [46.244.167.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.mnet-online.de (Postfix) with ESMTPSA; Mon, 12 Jul 2021 16:56:18 +0200 (CEST) Received: by igel.home (Postfix, from userid 1000) id 234792C0797; Mon, 12 Jul 2021 16:56:18 +0200 (CEST) From: Andreas Schwab To: Paul Eggert Subject: Re: bug#49261: Segfault during loadup References: <8735sqnmei.fsf@gnus.org> <87zguyf4ht.fsf@gmx.de> <87pmvum54p.fsf@gnus.org> <87v95mf2lj.fsf@gmx.de> <87pmvt3ob1.fsf@gnus.org> <83r1g9evoy.fsf@gnu.org> <83pmvtevgg.fsf@gnu.org> <87czrt3mj4.fsf@gnus.org> <878s2h3m1d.fsf@gnus.org> <874kd53lnl.fsf@gnus.org> <87zgux26ab.fsf@gnus.org> <87pmvt25uq.fsf@gnus.org> <87lf6h2294.fsf@gnus.org> <87h7h51x9y.fsf_-_@gnus.org> <83bl79b17n.fsf@gnu.org> <835yxgc1pm.fsf@gnu.org> <83wnpvag6z.fsf@gnu.org> <5608bf0a-7211-73a9-690f-c869a1cb3c9d@cs.ucla.edu> X-Yow: .. my NOSE is NUMB! Date: Mon, 12 Jul 2021 16:56:18 +0200 In-Reply-To: <5608bf0a-7211-73a9-690f-c869a1cb3c9d@cs.ucla.edu> (Paul Eggert's message of "Mon, 12 Jul 2021 07:50:41 -0700") Message-ID: <87im1fmvhp.fsf@igel.home> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.5 (/) X-Debbugs-Envelope-To: 49261 Cc: Eli Zaretskii , larsi@gnus.org, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.4 (-) The warning isn't bogus. It points out a potential bug. That's what warnings are all about. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different." From debbugs-submit-bounces@debbugs.gnu.org Mon Jul 12 11:54:43 2021 Received: (at 49261) by debbugs.gnu.org; 12 Jul 2021 15:54:43 +0000 Received: from localhost ([127.0.0.1]:38715 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m2yGZ-0000bU-HL for submit@debbugs.gnu.org; Mon, 12 Jul 2021 11:54:43 -0400 Received: from eggs.gnu.org ([209.51.188.92]:36514) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m2yGX-0000bH-F3 for 49261@debbugs.gnu.org; Mon, 12 Jul 2021 11:54:42 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:56676) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m2yGR-00039F-Ck; Mon, 12 Jul 2021 11:54:35 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3621 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m2yGN-00035n-GS; Mon, 12 Jul 2021 11:54:35 -0400 Date: Mon, 12 Jul 2021 18:54:23 +0300 Message-Id: <83o8b7a5ow.fsf@gnu.org> From: Eli Zaretskii To: Paul Eggert In-Reply-To: <5608bf0a-7211-73a9-690f-c869a1cb3c9d@cs.ucla.edu> (message from Paul Eggert on Mon, 12 Jul 2021 07:50:41 -0700) Subject: Re: bug#49261: Segfault during loadup References: <87o8bn7bie.fsf@gnus.org> <87zgv6vuon.fsf@gmx.de> <837di9lwbm.fsf@gnu.org> <87a6n5vuu4.fsf@gnus.org> <8735sqnmei.fsf@gnus.org> <87zguyf4ht.fsf@gmx.de> <87pmvum54p.fsf@gnus.org> <87v95mf2lj.fsf@gmx.de> <87pmvt3ob1.fsf@gnus.org> <83r1g9evoy.fsf@gnu.org> <83pmvtevgg.fsf@gnu.org> <87czrt3mj4.fsf@gnus.org> <878s2h3m1d.fsf@gnus.org> <874kd53lnl.fsf@gnus.org> <87zgux26ab.fsf@gnus.org> <87pmvt25uq.fsf@gnus.org> <87lf6h2294.fsf@gnus.org> <87h7h51x9y.fsf_-_@gnus.org> <83bl79b17n.fsf@gnu.org> <835yxgc1pm.fsf@gnu.org> <83wnpvag6z.fsf@gnu.org> <5608bf0a-7211-73a9-690f-c869a1cb3c9d@cs.ucla.edu> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49261 Cc: larsi@gnus.org, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: larsi@gnus.org, 49261@debbugs.gnu.org > From: Paul Eggert > Date: Mon, 12 Jul 2021 07:50:41 -0700 > > On 7/12/21 5:07 AM, Eli Zaretskii wrote: > > >> Yes that GCC warning was bogus, and your pacification of GCC is valid > > > > Hmm... is it really a bogus warning? VALMASK is a 64-bit value, and > > uintptr_t is 32-bit wide. > > It's bogus in the sense that 'uintptr_t mask = VALMASK;' has > well-defined behavior in C; there is no undefined behavior there, since > VALMASK is an integer and uintptr_t is unsigned. And truncation is what > is wanted here, so the warning is bogus. Then what is the -Woverflow option for? Can you show an example of code which -Woverflow would flag that doesn't produce a bogus warning? From debbugs-submit-bounces@debbugs.gnu.org Mon Jul 12 13:30:34 2021 Received: (at 49261) by debbugs.gnu.org; 12 Jul 2021 17:30:34 +0000 Received: from localhost ([127.0.0.1]:38788 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m2zlK-00036o-EY for submit@debbugs.gnu.org; Mon, 12 Jul 2021 13:30:34 -0400 Received: from eggs.gnu.org ([209.51.188.92]:55316) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m2zlI-00036a-Es for 49261@debbugs.gnu.org; Mon, 12 Jul 2021 13:30:32 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:58922) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m2zlD-00070u-1J; Mon, 12 Jul 2021 13:30:27 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:1569 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m2zlC-00080u-Kt; Mon, 12 Jul 2021 13:30:26 -0400 Date: Mon, 12 Jul 2021 20:30:21 +0300 Message-Id: <838s2ba18y.fsf@gnu.org> From: Eli Zaretskii To: Michael Albinus In-Reply-To: <87a6mrd2di.fsf@gmx.de> (message from Michael Albinus on Mon, 12 Jul 2021 16:37:45 +0200) Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: <87o8bn7bie.fsf@gnus.org> <87zgv6vuon.fsf@gmx.de> <837di9lwbm.fsf@gnu.org> <87a6n5vuu4.fsf@gnus.org> <8735sqnmei.fsf@gnus.org> <87zguyf4ht.fsf@gmx.de> <87pmvum54p.fsf@gnus.org> <87v95mf2lj.fsf@gmx.de> <87pmvt3ob1.fsf@gnus.org> <87fswpgacv.fsf@gmx.de> <87bl7dfikj.fsf@gmx.de> <8735sofuqj.fsf@gmx.de> <83sg0oc83l.fsf@gnu.org> <87v95jevrm.fsf@gmx.de> <83lf6fdav4.fsf@gnu.org> <87r1g7eoor.fsf@gmx.de> <87im1jphyy.fsf@gnus.org> <87im1fd4fr.fsf@gmx.de> <83sg0jaaud.fsf@gnu.org> <87a6mrd2di.fsf@gmx.de> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49261 Cc: larsi@gnus.org, ncaprisunfan@gmail.com, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Michael Albinus > Cc: larsi@gnus.org, ncaprisunfan@gmail.com, 49261@debbugs.gnu.org > Date: Mon, 12 Jul 2021 16:37:45 +0200 > > Eli Zaretskii writes: > > Hi Eli, > > >> Lars Ingebrigtsen writes: > >> > >> >> Until now, there are no file locks for remote files at all. I thought > >> >> disabling it for remote files would be requested by some users for > >> >> backward compatibility. > >> > > >> > Yeah, I think it's a good idea, and allowing REPLACEMENT to be nil seems > >> > like the natural way to implement it. > >> > >> And now? You and Eli disagree in this point, and I don't know what to do. > > > > Which disagreement between us leaves you at an impasse? If there is > > indeed such a disagreement, maybe we could find a compromise which > > will allow some way forward. > > Lars agrees my proposal to use lock-file-name-transforms for disabling > file locks. You did argue against. Are we talking about disabling remote locks by default? If so, how about disabling them via a more user-friendly option? It strikes me as weird and un-intuitive to _disable_ something via a "transform" function. And it will definitely be more complex to set up such a "transform" function than just use a boolean flag. From debbugs-submit-bounces@debbugs.gnu.org Mon Jul 12 13:35:53 2021 Received: (at 49261) by debbugs.gnu.org; 12 Jul 2021 17:35:53 +0000 Received: from localhost ([127.0.0.1]:38800 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m2zqT-0003Er-GI for submit@debbugs.gnu.org; Mon, 12 Jul 2021 13:35:53 -0400 Received: from quimby.gnus.org ([95.216.78.240]:50676) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m2zqS-0003Ef-2J for 49261@debbugs.gnu.org; Mon, 12 Jul 2021 13:35:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=71CW29Vt8wtYvlew/yQQqJ6JUiftRVDIxR5FRYLXGmE=; b=iU2abJTi9+FVNiwYLVal2E7CK2 vY74aPVmzHlKt1lfp3VUxclsQAFD6eCB3x68HufTIwGCFAuW0tb9XuVd10DXZwxubFZ9r70BwpjjM 0/tqhpT2sFMpm6I2La8uBF+ELSVrckF+mvXAFwIY5+x/WXsaL9WrQ+w3qZBtfIE2hRlA=; Received: from cm-84.212.220.105.getinternet.no ([84.212.220.105] helo=elva) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m2zqG-0008VC-AZ; Mon, 12 Jul 2021 19:35:43 +0200 From: Lars Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: <87zgv6vuon.fsf@gmx.de> <837di9lwbm.fsf@gnu.org> <87a6n5vuu4.fsf@gnus.org> <8735sqnmei.fsf@gnus.org> <87zguyf4ht.fsf@gmx.de> <87pmvum54p.fsf@gnus.org> <87v95mf2lj.fsf@gmx.de> <87pmvt3ob1.fsf@gnus.org> <87fswpgacv.fsf@gmx.de> <87bl7dfikj.fsf@gmx.de> <8735sofuqj.fsf@gmx.de> <83sg0oc83l.fsf@gnu.org> <87v95jevrm.fsf@gmx.de> <83lf6fdav4.fsf@gnu.org> <87r1g7eoor.fsf@gmx.de> <87im1jphyy.fsf@gnus.org> <87im1fd4fr.fsf@gmx.de> <83sg0jaaud.fsf@gnu.org> <87a6mrd2di.fsf@gmx.de> <838s2ba18y.fsf@gnu.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAKlBMVEUBAQEQDw6jmo/G vrSEem+RhnpvZl1VTUcYFhQwLCgiHhxJQjxCPDf////q0X7LAAAAAWJLR0QN9rRh9QAAAAd0SU1F B+UHDBEgKbh5NrAAAAFLSURBVDjL5ZKxTsMwEIadrWSyEYKsBJUHgDeIiNijJmJFCs6MhOKBDmRL M7GVa7KwJX4BVKV7VcFD9a6uVEqTGSR+ydLJn+9899uM9enYdd0L9/wQnIQorwOcStJ9dym3q9SZ Ij12ZFyjru4OwRGQXtkflCW+hZxvQyFyEjHLoSgTwuwbUtQvg9wcQXFMNaDQusZV7AOxAUBwB5hw dEO2NOVkYw/McmoA78P96lOp8RSWaPQCic4JFFC1KpUyTkspk+cVgK4zbNlC8JFKbxiMnsIIwSzj ZiCRF02l4sAdemE0f+dmSrZty5lM4yi9VKr9wlpQIxDMyhvAYn54M5J4l5rXglHGpFRj0LBMfS+4 BY2OsM0cRZ0Zz+yHVCYL6jUjsJPtQ9uuCKCPe0ByhyxAW8Teo9gJ35r98yONe57Rhj7w1gMG2W99 uf+nNeLHjdnh0E8LAAAAJXRFWHRkYXRlOmNyZWF0ZQAyMDIxLTA3LTEyVDE3OjMyOjQxKzAwOjAw DtozBQAAACV0RVh0ZGF0ZTptb2RpZnkAMjAyMS0wNy0xMlQxNzozMjo0MSswMDowMH+Hi7kAAAAA SUVORK5CYII= X-Now-Playing: SUV's _Through the Eyes. Presented by Krust (1)_: "Parklands" Date: Mon, 12 Jul 2021 19:35:38 +0200 In-Reply-To: <838s2ba18y.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 12 Jul 2021 20:30:21 +0300") Message-ID: <87pmvnsadx.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Eli Zaretskii writes: > Are we talking about disabling remote locks by default? If so, how > about disabling them via a more user-friendly option? It strikes me > as weird and un-intuitive to _disable_ something via a "tra [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49261 Cc: Michael Albinus , ncaprisunfan@gmail.com, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: > Are we talking about disabling remote locks by default? If so, how > about disabling them via a more user-friendly option? It strikes me > as weird and un-intuitive to _disable_ something via a "transform" > function. And it will definitely be more complex to set up such a > "transform" function than just use a boolean flag. The thing is: In Emacs 27, we didn't have file locking for Tramp files. This has now been introduced, and we're discussing how to disable them (and only them) in Emacs 28. Doing that as a transform seems natural, since that's very parallel to what we're doing in `auto-save-file-name-transforms' (where Tramp file names are made local). -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Mon Jul 12 13:38:38 2021 Received: (at 49261) by debbugs.gnu.org; 12 Jul 2021 17:38:38 +0000 Received: from localhost ([127.0.0.1]:38804 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m2zt7-0003J7-U3 for submit@debbugs.gnu.org; Mon, 12 Jul 2021 13:38:38 -0400 Received: from eggs.gnu.org ([209.51.188.92]:56788) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m2zt6-0003Iu-AT for 49261@debbugs.gnu.org; Mon, 12 Jul 2021 13:38:36 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:59072) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m2zt0-0003yZ-QT; Mon, 12 Jul 2021 13:38:30 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2077 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m2zt0-0006NB-9j; Mon, 12 Jul 2021 13:38:30 -0400 Date: Mon, 12 Jul 2021 20:38:25 +0300 Message-Id: <837dhva0vi.fsf@gnu.org> From: Eli Zaretskii To: Lars Ingebrigtsen In-Reply-To: <87pmvnsadx.fsf@gnus.org> (message from Lars Ingebrigtsen on Mon, 12 Jul 2021 19:35:38 +0200) Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: <87zgv6vuon.fsf@gmx.de> <837di9lwbm.fsf@gnu.org> <87a6n5vuu4.fsf@gnus.org> <8735sqnmei.fsf@gnus.org> <87zguyf4ht.fsf@gmx.de> <87pmvum54p.fsf@gnus.org> <87v95mf2lj.fsf@gmx.de> <87pmvt3ob1.fsf@gnus.org> <87fswpgacv.fsf@gmx.de> <87bl7dfikj.fsf@gmx.de> <8735sofuqj.fsf@gmx.de> <83sg0oc83l.fsf@gnu.org> <87v95jevrm.fsf@gmx.de> <83lf6fdav4.fsf@gnu.org> <87r1g7eoor.fsf@gmx.de> <87im1jphyy.fsf@gnus.org> <87im1fd4fr.fsf@gmx.de> <83sg0jaaud.fsf@gnu.org> <87a6mrd2di.fsf@gmx.de> <838s2ba18y.fsf@gnu.org> <87pmvnsadx.fsf@gnus.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49261 Cc: michael.albinus@gmx.de, ncaprisunfan@gmail.com, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Lars Ingebrigtsen > Cc: Michael Albinus , ncaprisunfan@gmail.com, > 49261@debbugs.gnu.org > Date: Mon, 12 Jul 2021 19:35:38 +0200 > > Eli Zaretskii writes: > > > Are we talking about disabling remote locks by default? If so, how > > about disabling them via a more user-friendly option? It strikes me > > as weird and un-intuitive to _disable_ something via a "transform" > > function. And it will definitely be more complex to set up such a > > "transform" function than just use a boolean flag. > > The thing is: In Emacs 27, we didn't have file locking for Tramp files. > This has now been introduced, and we're discussing how to disable them > (and only them) in Emacs 28. > > Doing that as a transform seems natural, since that's very parallel to > what we're doing in `auto-save-file-name-transforms' (where Tramp file > names are made local). I suggested a compromise: disable it by default, but not via the transform function. I think it's more natural, but even if you disagree, would it do as a compromise? From debbugs-submit-bounces@debbugs.gnu.org Mon Jul 12 14:00:46 2021 Received: (at 49261) by debbugs.gnu.org; 12 Jul 2021 18:00:46 +0000 Received: from localhost ([127.0.0.1]:38848 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m30EY-00063p-Ih for submit@debbugs.gnu.org; Mon, 12 Jul 2021 14:00:46 -0400 Received: from mout.gmx.net ([212.227.17.21]:52395) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m30EW-00063b-4l for 49261@debbugs.gnu.org; Mon, 12 Jul 2021 14:00:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1626112836; bh=mf2U43yjlC8lN4tXV93Frw5F5TmK+dn6PfX9hBZH4I8=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=CUn9W6CguHXNsEhqQXLZypljnjPBF7xzdtWNli95OQIedANrPrgxtktq5Z4nFgM4P 1sEY0p8SonTKnmpitnHyZztnQJcIXFgSdN1eza8kdW1CVdpkjD3UBm+cnWgi2tVyC6 EKA2T8ZVz/rYp5s2yWtZNcBukpu1vG049LLyXYRk= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from gandalf.gmx.de ([213.220.146.224]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MK3Rm-1lijWc12UA-00LT8j; Mon, 12 Jul 2021 20:00:36 +0200 From: Michael Albinus To: Eli Zaretskii Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: <87a6n5vuu4.fsf@gnus.org> <8735sqnmei.fsf@gnus.org> <87zguyf4ht.fsf@gmx.de> <87pmvum54p.fsf@gnus.org> <87v95mf2lj.fsf@gmx.de> <87pmvt3ob1.fsf@gnus.org> <87fswpgacv.fsf@gmx.de> <87bl7dfikj.fsf@gmx.de> <8735sofuqj.fsf@gmx.de> <83sg0oc83l.fsf@gnu.org> <87v95jevrm.fsf@gmx.de> <83lf6fdav4.fsf@gnu.org> <87r1g7eoor.fsf@gmx.de> <87im1jphyy.fsf@gnus.org> <87im1fd4fr.fsf@gmx.de> <83sg0jaaud.fsf@gnu.org> <87a6mrd2di.fsf@gmx.de> <838s2ba18y.fsf@gnu.org> <87pmvnsadx.fsf@gnus.org> <837dhva0vi.fsf@gnu.org> Date: Mon, 12 Jul 2021 20:00:34 +0200 In-Reply-To: <837dhva0vi.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 12 Jul 2021 20:38:25 +0300") Message-ID: <871r83cszh.fsf@gmx.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:Vuc3WWMHSsIENpbIlKr7i3FuAW6HibqNyC0STAU5YZp1fPTMJpe xpMOVyqtxh1GIBbaihQFn8bzQ+wYIDJgtVitFM2V3wbJA19aryVXg5Vh6PzxYrBjevHLxkk LFUzSyzzrRfhsGJJ5KBBLUD7GypMR6cRXO9ZHVg8p1S0Y82LdVBzwZJ8nFapC9g1iOKZUqk UVn4/8dUnLKbNYfVz7AvA== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:9fsvrTV7Mj8=:tso2SCgycb6HTwoA1XTK62 OcrmC9FmlAFCmpbDF1zL4OidjxgGZsLB09oXxJKDt4laYEgL1LfXB/zPd+37tWdjz8WDAY28T iaS+/A9N2d/cHZ06iuWLU5fs+QU8GYDU7u/3JpqIo5hbkXj4ZS9AfQ7UnAjGnSU6uDiJ/6oQY nnRVh8I7bhOqNDerdajG2erlqzMODaJWtdh1nN3nfGFIiaiJQz7W6v8KuZaRlWlJBmIjcnd+W umL7kRFsje9BBM0JTfiIiJ+4No51+3wHgc9CDG9uj+f2RedBlTnWqh183bbry5/JnfE9UWOVH f7Qzb2elEZ/Hv96lU/mqQ4NQ9fdiDVCguusiSPHMiyl8D97iUoi6HL2BjPUgL4cjx2H5MO6ZY 5bltP71KIpdOaweEcznHOEH9nx3LbtAbkAIvnjHjc6iTjbMtHTFuenVe7pTzr2CDAPK6mDlz4 7QMsV0asYt4F+sGV0wz73ZLZILOtj6I0tc4iaEkMAEczt5KZM2D8PNyhEXuQepXnY/MBtFKhf POL9AT8pUGxm3CtILiCaE7N+tjM/qezVTIDZqZ27tx/KjfN1F1UBFj7P5JnQEx77MACXbaOzZ HfEq+fXLaN6wL8uZi8StTEA/SDz/qZiiw4ERxQ869DYlRYgyiR+ni7T9CigU4K9l9ZMqFXaOe rIVe7WuV38pvkUhlvH/bmiA/FCILZF99657shGMrbYhE72NnWNrW+CAhoFm4IZ7lxofIrDEoi L9Z3HHihSf9HprPv9W4Nn/ophRtiLa/Zb79Z2/7j2aD4On88+KC1ZlmGI6YknQBV2nW+Kh7T2 kb8/JWbLmbDu0mTIEk9AlOGH9I02EkoUJKoRbxEeUJPAAHIC1ZnTqT1ur4HQWvw6PS/iB8uKz fmemj4e0XGzKyaw/4TIRQRwa8jw8Voe7wh472e/4OkGOIZ61zGP/8Q1i79bezZjDJhWTksbci Ygzyx8k2xQhVbjffSSBYLiG1EvJpFr+1QHw4a3Nh1mMkYfZhaYAJPuPISd62u/tJV2A0UH2KS ZC88w5V387pMYVjD1zbC6d5BghWvTP7YgG75R9ixuCIYTJfOLWofyy4HKLP26OsVF/t7VtOTU FjMdztEiBUW9enWurQD2WMpQr6xAcpQYq4mvq5zq9e6C8KblwjDAkznLw== X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 49261 Cc: Lars Ingebrigtsen , ncaprisunfan@gmail.com, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: > I suggested a compromise: disable it by default, but not via the > transform function. I think it's more natural, but even if you > disagree, would it do as a compromise? I'm OK with another user option to disable it, it doesn't matter too much. But I'm not sure whether we shall disable it by default: nobody(*) will enable it ever, and all the effort would be wasted. (*): except me, of course :-) Best regards, Michael. From debbugs-submit-bounces@debbugs.gnu.org Mon Jul 12 14:25:55 2021 Received: (at 49261) by debbugs.gnu.org; 12 Jul 2021 18:25:55 +0000 Received: from localhost ([127.0.0.1]:38865 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m30cs-0006gq-QZ for submit@debbugs.gnu.org; Mon, 12 Jul 2021 14:25:55 -0400 Received: from eggs.gnu.org ([209.51.188.92]:36786) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m30cq-0006ge-Vb for 49261@debbugs.gnu.org; Mon, 12 Jul 2021 14:25:53 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:59784) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m30cl-0004ja-Da; Mon, 12 Jul 2021 14:25:47 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:4977 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m30cj-0007eM-JU; Mon, 12 Jul 2021 14:25:46 -0400 Date: Mon, 12 Jul 2021 21:25:37 +0300 Message-Id: <834kcz9you.fsf@gnu.org> From: Eli Zaretskii To: Michael Albinus In-Reply-To: <871r83cszh.fsf@gmx.de> (message from Michael Albinus on Mon, 12 Jul 2021 20:00:34 +0200) Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: <87a6n5vuu4.fsf@gnus.org> <8735sqnmei.fsf@gnus.org> <87zguyf4ht.fsf@gmx.de> <87pmvum54p.fsf@gnus.org> <87v95mf2lj.fsf@gmx.de> <87pmvt3ob1.fsf@gnus.org> <87fswpgacv.fsf@gmx.de> <87bl7dfikj.fsf@gmx.de> <8735sofuqj.fsf@gmx.de> <83sg0oc83l.fsf@gnu.org> <87v95jevrm.fsf@gmx.de> <83lf6fdav4.fsf@gnu.org> <87r1g7eoor.fsf@gmx.de> <87im1jphyy.fsf@gnus.org> <87im1fd4fr.fsf@gmx.de> <83sg0jaaud.fsf@gnu.org> <87a6mrd2di.fsf@gmx.de> <838s2ba18y.fsf@gnu.org> <87pmvnsadx.fsf@gnus.org> <837dhva0vi.fsf@gnu.org> <871r83cszh.fsf@gmx.de> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49261 Cc: larsi@gnus.org, ncaprisunfan@gmail.com, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Michael Albinus > Cc: Lars Ingebrigtsen , ncaprisunfan@gmail.com, > 49261@debbugs.gnu.org > Date: Mon, 12 Jul 2021 20:00:34 +0200 > > Eli Zaretskii writes: > > > I suggested a compromise: disable it by default, but not via the > > transform function. I think it's more natural, but even if you > > disagree, would it do as a compromise? > > I'm OK with another user option to disable it, it doesn't matter too > much. But I'm not sure whether we shall disable it by default: nobody(*) > will enable it ever, and all the effort would be wasted. Now _I_ am confused: didn't you say that we _should_ disable it by default for remote files, because that was how Emacs worked until now? Or what did I miss? From debbugs-submit-bounces@debbugs.gnu.org Mon Jul 12 14:47:08 2021 Received: (at 49261) by debbugs.gnu.org; 12 Jul 2021 18:47:08 +0000 Received: from localhost ([127.0.0.1]:38875 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m30xQ-0007CQ-26 for submit@debbugs.gnu.org; Mon, 12 Jul 2021 14:47:08 -0400 Received: from mout.gmx.net ([212.227.15.19]:49603) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m30xO-0007Bx-KC for 49261@debbugs.gnu.org; Mon, 12 Jul 2021 14:47:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1626115620; bh=KKxIvgXgM95dvdCKRMYmmmrkbWp0Rg6DXVHiAS55Peg=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=a7F8D/2Q4tx3dOBCLkk7v5/GGOo8DdIZ07zx1Z5RkC5pRBEJP++6h2Fk8KPpWI9l0 XrIzTB4qcZqj3VJTY2IEmi3MzBpSIo4PU36TiQ2YMO7iqzlTJ0TkTBQ/sqBMmjNZx0 ilwPZIsYZ0DL/gbttPZoLDnQmKcvmHt+L5BHPIp0= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from gandalf.gmx.de ([213.220.146.224]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MtOGa-1l9Nvx39mY-00umby; Mon, 12 Jul 2021 20:47:00 +0200 From: Michael Albinus To: Eli Zaretskii Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: <87zguyf4ht.fsf@gmx.de> <87pmvum54p.fsf@gnus.org> <87v95mf2lj.fsf@gmx.de> <87pmvt3ob1.fsf@gnus.org> <87fswpgacv.fsf@gmx.de> <87bl7dfikj.fsf@gmx.de> <8735sofuqj.fsf@gmx.de> <83sg0oc83l.fsf@gnu.org> <87v95jevrm.fsf@gmx.de> <83lf6fdav4.fsf@gnu.org> <87r1g7eoor.fsf@gmx.de> <87im1jphyy.fsf@gnus.org> <87im1fd4fr.fsf@gmx.de> <83sg0jaaud.fsf@gnu.org> <87a6mrd2di.fsf@gmx.de> <838s2ba18y.fsf@gnu.org> <87pmvnsadx.fsf@gnus.org> <837dhva0vi.fsf@gnu.org> <871r83cszh.fsf@gmx.de> <834kcz9you.fsf@gnu.org> Date: Mon, 12 Jul 2021 20:46:57 +0200 In-Reply-To: <834kcz9you.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 12 Jul 2021 21:25:37 +0300") Message-ID: <87wnpvbc9q.fsf@gmx.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:R2dm5y3wzBT2Sj41m27fFiFpq12JZrQLwENVLy/ACczWZ7vcDJC yBcCAgRMPyNKrFLXK9i6XhCP1wvmqwLESGcpunWok/smEQUGczn+P5htTpbSdEynrWlC3zL 0uMCKuk/B0IHQ3wexNtMZFyHrNdLP4Vreh+2RTUAyjfMFKRQMeghx7ZXcq3usis55S9yiVm Fl0f1nEySXU1h0ZSIM2gg== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:BQ198h7y+u8=:LXUru2DhK6pzKLz9qeFlm+ QH4hwcKSQQTUnc79jYbujlWPt4lH1dE1APc194JyuKwknAwZK+iezlOLDb2LrwvbcojQ3m/HQ fiOanPZpNmkHcYE9EZD7PwyBbOh3k5boOwspKXbeBHjHYqWYKn7GJ65KVNpZi+2xhBPlkit7g Gwky33BmMQDJLrGIw+oHqre802ye02df78iIG3dEXK+0OjSu6OLD6+cGbM7haN7lujJuKe3XO e1SnFCcoz7aqW3+T/6S3ktv53DI5lMb9BxqNcmbyzZb6mJXPMR+YEJV2qO+2t9nat3T4WWJ7b TKAGq8/1bcDtcNwT1G+twrZ48Y0zT/P2Nl7IJXlQFlm/YkerhQiuQz6q2BP/2xe5iAeKOD9N2 AKojBCkwhaXCCxu7axEzDl48DlDRe+MY/1TtwDulPYk0BoUdIc5545Kq08hwLG0m9ENAJ3x3Q XBBMHmXoGV/m1UQbyPiGDHVALfI2BWLIlS6/ofVPKqK1X/UaRHk1+2fnO4u+93T13mQejDNdc 0JaxoFIpssblu/XJulvfMHJI3fgVSmTPQLKN2sS9G5ZwbuzQpc20ksIuzRBrlEt1EIIYnfR/E RQ7klsRn1M0NDVHC3fJBs10zyZ+q5p6MA04euM/YN1Ptz2SMn/zFjluuf+oZWspdOpvRJaVq3 S+/SLahVqkYIfQaa/qvsutUn251kBi02ij6Xv2ni+TMMu3ppJDlXQN/tfxy2tYD1EZVmJbQHL Vl9ml2IWRqLUSJAVpmo9w3IYl9Ey05veIQ7CZmHOqVtgC61QVf81Q9I6OO0/OiVtNb9Jk+Li1 GahrSwR8rrGj72kTKU19XzBNBe+kNKgF6mk47GQ5qkYfuVp+88tC6lJCZ9IUysn93+lkI8Td9 FFDubRf1V8ArWLwyS4hu4L6iFjM9InN1OjQrqHLJcJlKVSdiOseJ1N1j7mLh2yeLSBDsd92es BJwGaayxPuvstBgfr2HhxQVJ6qPYBj22a8Mop6uqCMLgXX4xrLyY1fecP9VCNw1bVG4HimVsd XQdOIgVUfiQdCKmNGIXjBR0gAiriLzyRw9LkTejDxeYIackc+huXAHMlhVVyjI932hvsrDsQm XSFA237HFvuBfQmQYylbyqzOvzmN2fJqgI26fb6mk4iecy6T6w/2y0WPA== Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 49261 Cc: larsi@gnus.org, ncaprisunfan@gmail.com, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Eli Zaretskii writes: >> > I suggested a compromise: disable it by default, but not via the >> > transform function. I think it's more natural, but even if you >> > disagree, would it do as a compromise? >> >> I'm OK with another user option to disable it, it doesn't matter too >> much. But I'm not sure whether we shall disable it by default: nobody(*= ) >> will enable it ever, and all the effort would be wasted. > > Now _I_ am confused: didn't you say that we _should_ disable it by > default for remote files, because that was how Emacs worked until now? > Or what did I miss? No. I meant we shall provide the *possibility* to disable it, because it didn't exist before. If I have written something which reads different, it is because of my limited English. Best regards, Michael. From debbugs-submit-bounces@debbugs.gnu.org Mon Jul 12 15:04:41 2021 Received: (at 49261) by debbugs.gnu.org; 12 Jul 2021 19:04:41 +0000 Received: from localhost ([127.0.0.1]:38888 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m31EP-0007b9-7L for submit@debbugs.gnu.org; Mon, 12 Jul 2021 15:04:41 -0400 Received: from eggs.gnu.org ([209.51.188.92]:45130) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m31EM-0007aw-Hx for 49261@debbugs.gnu.org; Mon, 12 Jul 2021 15:04:39 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:33168) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m31EG-0000aT-V7; Mon, 12 Jul 2021 15:04:32 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3612 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m31EG-000383-Au; Mon, 12 Jul 2021 15:04:32 -0400 Date: Mon, 12 Jul 2021 22:04:24 +0300 Message-Id: <8335sj9ww7.fsf@gnu.org> From: Eli Zaretskii To: Michael Albinus In-Reply-To: <87wnpvbc9q.fsf@gmx.de> (message from Michael Albinus on Mon, 12 Jul 2021 20:46:57 +0200) Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: <87zguyf4ht.fsf@gmx.de> <87pmvum54p.fsf@gnus.org> <87v95mf2lj.fsf@gmx.de> <87pmvt3ob1.fsf@gnus.org> <87fswpgacv.fsf@gmx.de> <87bl7dfikj.fsf@gmx.de> <8735sofuqj.fsf@gmx.de> <83sg0oc83l.fsf@gnu.org> <87v95jevrm.fsf@gmx.de> <83lf6fdav4.fsf@gnu.org> <87r1g7eoor.fsf@gmx.de> <87im1jphyy.fsf@gnus.org> <87im1fd4fr.fsf@gmx.de> <83sg0jaaud.fsf@gnu.org> <87a6mrd2di.fsf@gmx.de> <838s2ba18y.fsf@gnu.org> <87pmvnsadx.fsf@gnus.org> <837dhva0vi.fsf@gnu.org> <871r83cszh.fsf@gmx.de> <834kcz9you.fsf@gnu.org> <87wnpvbc9q.fsf@gmx.de> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49261 Cc: larsi@gnus.org, ncaprisunfan@gmail.com, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Michael Albinus > Cc: larsi@gnus.org, ncaprisunfan@gmail.com, 49261@debbugs.gnu.org > Date: Mon, 12 Jul 2021 20:46:57 +0200 > > Eli Zaretskii writes: > > >> > I suggested a compromise: disable it by default, but not via the > >> > transform function. I think it's more natural, but even if you > >> > disagree, would it do as a compromise? > >> > >> I'm OK with another user option to disable it, it doesn't matter too > >> much. But I'm not sure whether we shall disable it by default: nobody(*) > >> will enable it ever, and all the effort would be wasted. > > > > Now _I_ am confused: didn't you say that we _should_ disable it by > > default for remote files, because that was how Emacs worked until now? > > Or what did I miss? > > No. I meant we shall provide the *possibility* to disable it, because it > didn't exist before. Ah, okay. I only said it should be disabled by default because I thought that was what you suggested. I have no problem whatsoever to have remote locking enabled by default. From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 13 12:31:11 2021 Received: (at 49261) by debbugs.gnu.org; 13 Jul 2021 16:31:11 +0000 Received: from localhost ([127.0.0.1]:41653 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m3LJP-0004UL-7b for submit@debbugs.gnu.org; Tue, 13 Jul 2021 12:31:11 -0400 Received: from quimby.gnus.org ([95.216.78.240]:60730) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m3LJL-0004Mm-Sd for 49261@debbugs.gnu.org; Tue, 13 Jul 2021 12:31:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=POyNGbfodteyrLlECSP2xPt8Gi+xnuh/+05qQLTXW/g=; b=n52CVbBTm+lMExKfCj1aJ7aDOZ H+4f8YM3Cny8wmpOBsAvzK6rWTSLcjxcp/orkkawAyp739uFltSFqaY8/tfTPyl24/RMjZaRpQ1N8 XJ07HjFrtNXie520zkQd5BAeLyPwC9oae5N2/NRuLe691ubzHG5S0CoF0HqXeuBYftMs=; Received: from cm-84.212.220.105.getinternet.no ([84.212.220.105] helo=elva) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m3LJD-0002GC-3A; Tue, 13 Jul 2021 18:31:01 +0200 From: Lars Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: <87a6n5vuu4.fsf@gnus.org> <8735sqnmei.fsf@gnus.org> <87zguyf4ht.fsf@gmx.de> <87pmvum54p.fsf@gnus.org> <87v95mf2lj.fsf@gmx.de> <87pmvt3ob1.fsf@gnus.org> <87fswpgacv.fsf@gmx.de> <87bl7dfikj.fsf@gmx.de> <8735sofuqj.fsf@gmx.de> <83sg0oc83l.fsf@gnu.org> <87v95jevrm.fsf@gmx.de> <83lf6fdav4.fsf@gnu.org> <87r1g7eoor.fsf@gmx.de> <87im1jphyy.fsf@gnus.org> <87im1fd4fr.fsf@gmx.de> <83sg0jaaud.fsf@gnu.org> <87a6mrd2di.fsf@gmx.de> <838s2ba18y.fsf@gnu.org> <87pmvnsadx.fsf@gnus.org> <837dhva0vi.fsf@gnu.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAD1BMVEXLXGbbf4i2QUyg HCX///919J2+AAAAAWJLR0QEj2jZUQAAAAd0SU1FB+UHDRAbO84MpZIAAAGjSURBVDjLbZQBksMg CEVRL6DmAgYu4ML977YfdJukG6YzTXnCByQlerXUafw94yG1up4byQapppbO1tpysxiNmpK7yT81 ItisONgZRs4RLAbrRhy/MmdlzzpYVTQ3gHUuIyIRVyZmmZyNlJy03FIFQyiz5wJoHbKtNi4C1/I6 MAinLQlTMd2AqLpb3UVkrOyHlGyEG5pqCPVkjDOIUGUumg2iTDnSuBAJwMi2PGofo2P92OLs1aJD gH4dQqoSUxDFrJJnGFmgJBTAO5xG5xpBABb/Yp4yhSYir35DZqBoIe3PclRtyBqJt5c//qbRh5Al +OXK1A4M1mYh+7l5YafYWbwqm4d92ewYBGbVv4F27dBw9bsVQ1nKAOfz+GF6HgG+1L2VHkDLN7HE Dl6MXoGPR/N7xAb6Qm6p5D9QjWt4AFkAmzRK7NxVGBZvxg5lQdBFaA5OVRTeuPblHbgj3Xt/k8Dl sm/xOnXPr6M20n3dehNQf8eUdwsAvMper+WnN48QX7f9l3D1GhsN2/8Un8xqDz/puM3nlinE/+Yz nuCqMrQ3+QWE36RlCJfPOQAAACV0RVh0ZGF0ZTpjcmVhdGUAMjAyMS0wNy0xM1QxNjoyNzo1OSsw MDowMKXGIWwAAAAldEVYdGRhdGU6bW9kaWZ5ADIwMjEtMDctMTNUMTY6Mjc6NTkrMDA6MDDUm5nQ AAAAAElFTkSuQmCC X-Now-Playing: King Crimson's _The Complete 1969 Recordings (17): Sessions 5_: "Epitaph Takes 5 to 11" Date: Tue, 13 Jul 2021 18:30:58 +0200 In-Reply-To: <837dhva0vi.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 12 Jul 2021 20:38:25 +0300") Message-ID: <878s2arxa5.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Eli Zaretskii writes: > I suggested a compromise: disable it by default, but not via the > transform function. I think it's more natural, but even if you > disagree, would it do as a compromise? Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49261 Cc: michael.albinus@gmx.de, ncaprisunfan@gmail.com, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: > I suggested a compromise: disable it by default, but not via the > transform function. I think it's more natural, but even if you > disagree, would it do as a compromise? I don't mind adding a special Tramp variable here (perhaps there should be one for auto save file names, too, for symmetry)? But I do think allowing people to inhibit locks/auto save files on a path name basis is good functionality in general, Tramp no Tramp. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 13 12:32:02 2021 Received: (at 49261) by debbugs.gnu.org; 13 Jul 2021 16:32:02 +0000 Received: from localhost ([127.0.0.1]:41656 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m3LKD-00058l-My for submit@debbugs.gnu.org; Tue, 13 Jul 2021 12:32:02 -0400 Received: from quimby.gnus.org ([95.216.78.240]:60748) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m3LKC-00052x-54 for 49261@debbugs.gnu.org; Tue, 13 Jul 2021 12:32:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=wrV/gTe622GUvGxTZWyYPcQwZPPrPc9/7qtvAnfxlbE=; b=QVL00OMXdDYNMC7emayyjbQ0dD QsrMK55RAsdTCegkvh5eHnycC2PGgAWB/UdeZuoSR8EIEaEuC+BuzN10uAQKYO5Ahgqzkyh8NoPwF bh5VSA9C+Mt0WQex/IZk6riUVZPjSyd6rL/kZDQNV174sgGkISnI6jDEd5XIkZncTTgU=; Received: from cm-84.212.220.105.getinternet.no ([84.212.220.105] helo=elva) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m3LK3-0002GY-HA; Tue, 13 Jul 2021 18:31:54 +0200 From: Lars Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: <8735sqnmei.fsf@gnus.org> <87zguyf4ht.fsf@gmx.de> <87pmvum54p.fsf@gnus.org> <87v95mf2lj.fsf@gmx.de> <87pmvt3ob1.fsf@gnus.org> <87fswpgacv.fsf@gmx.de> <87bl7dfikj.fsf@gmx.de> <8735sofuqj.fsf@gmx.de> <83sg0oc83l.fsf@gnu.org> <87v95jevrm.fsf@gmx.de> <83lf6fdav4.fsf@gnu.org> <87r1g7eoor.fsf@gmx.de> <87im1jphyy.fsf@gnus.org> <87im1fd4fr.fsf@gmx.de> <83sg0jaaud.fsf@gnu.org> <87a6mrd2di.fsf@gmx.de> <838s2ba18y.fsf@gnu.org> <87pmvnsadx.fsf@gnus.org> <837dhva0vi.fsf@gnu.org> <878s2arxa5.fsf@gnus.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAD1BMVEXLXGbbf4i2QUyg HCX///919J2+AAAAAWJLR0QEj2jZUQAAAAd0SU1FB+UHDRAbO84MpZIAAAGjSURBVDjLbZQBksMg CEVRL6DmAgYu4ML977YfdJukG6YzTXnCByQlerXUafw94yG1up4byQapppbO1tpysxiNmpK7yT81 ItisONgZRs4RLAbrRhy/MmdlzzpYVTQ3gHUuIyIRVyZmmZyNlJy03FIFQyiz5wJoHbKtNi4C1/I6 MAinLQlTMd2AqLpb3UVkrOyHlGyEG5pqCPVkjDOIUGUumg2iTDnSuBAJwMi2PGofo2P92OLs1aJD gH4dQqoSUxDFrJJnGFmgJBTAO5xG5xpBABb/Yp4yhSYir35DZqBoIe3PclRtyBqJt5c//qbRh5Al +OXK1A4M1mYh+7l5YafYWbwqm4d92ewYBGbVv4F27dBw9bsVQ1nKAOfz+GF6HgG+1L2VHkDLN7HE Dl6MXoGPR/N7xAb6Qm6p5D9QjWt4AFkAmzRK7NxVGBZvxg5lQdBFaA5OVRTeuPblHbgj3Xt/k8Dl sm/xOnXPr6M20n3dehNQf8eUdwsAvMper+WnN48QX7f9l3D1GhsN2/8Un8xqDz/puM3nlinE/+Yz nuCqMrQ3+QWE36RlCJfPOQAAACV0RVh0ZGF0ZTpjcmVhdGUAMjAyMS0wNy0xM1QxNjoyNzo1OSsw MDowMKXGIWwAAAAldEVYdGRhdGU6bW9kaWZ5ADIwMjEtMDctMTNUMTY6Mjc6NTkrMDA6MDDUm5nQ AAAAAElFTkSuQmCC X-Now-Playing: King Crimson's _The Complete 1969 Recordings (17): Sessions 5_: "Epitaph Takes 5 to 11" Date: Tue, 13 Jul 2021 18:31:50 +0200 In-Reply-To: <878s2arxa5.fsf@gnus.org> (Lars Ingebrigtsen's message of "Tue, 13 Jul 2021 18:30:58 +0200") Message-ID: <874kcyrx8p.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Lars Ingebrigtsen writes: > But I do think allowing people to inhibit locks/auto save files on a > path name basis is good functionality in general, Tramp no Tramp. (The last bit should be "Tramp or no Tramp".) Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49261 Cc: michael.albinus@gmx.de, ncaprisunfan@gmail.com, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Lars Ingebrigtsen writes: > But I do think allowing people to inhibit locks/auto save files on a > path name basis is good functionality in general, Tramp no Tramp. (The last bit should be "Tramp or no Tramp".) -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 13 12:41:18 2021 Received: (at 49261) by debbugs.gnu.org; 13 Jul 2021 16:41:18 +0000 Received: from localhost ([127.0.0.1]:41681 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m3LTC-0005uQ-Ap for submit@debbugs.gnu.org; Tue, 13 Jul 2021 12:41:18 -0400 Received: from eggs.gnu.org ([209.51.188.92]:42962) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m3LTA-0005uB-3B for 49261@debbugs.gnu.org; Tue, 13 Jul 2021 12:41:17 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:37904) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m3LT4-0004hs-Qg; Tue, 13 Jul 2021 12:41:10 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3535 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m3LT4-0006zn-FH; Tue, 13 Jul 2021 12:41:10 -0400 Date: Tue, 13 Jul 2021 19:41:05 +0300 Message-Id: <83o8b688v2.fsf@gnu.org> From: Eli Zaretskii To: Lars Ingebrigtsen In-Reply-To: <878s2arxa5.fsf@gnus.org> (message from Lars Ingebrigtsen on Tue, 13 Jul 2021 18:30:58 +0200) Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: <87a6n5vuu4.fsf@gnus.org> <8735sqnmei.fsf@gnus.org> <87zguyf4ht.fsf@gmx.de> <87pmvum54p.fsf@gnus.org> <87v95mf2lj.fsf@gmx.de> <87pmvt3ob1.fsf@gnus.org> <87fswpgacv.fsf@gmx.de> <87bl7dfikj.fsf@gmx.de> <8735sofuqj.fsf@gmx.de> <83sg0oc83l.fsf@gnu.org> <87v95jevrm.fsf@gmx.de> <83lf6fdav4.fsf@gnu.org> <87r1g7eoor.fsf@gmx.de> <87im1jphyy.fsf@gnus.org> <87im1fd4fr.fsf@gmx.de> <83sg0jaaud.fsf@gnu.org> <87a6mrd2di.fsf@gmx.de> <838s2ba18y.fsf@gnu.org> <87pmvnsadx.fsf@gnus.org> <837dhva0vi.fsf@gnu.org> <878s2arxa5.fsf@gnus.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49261 Cc: michael.albinus@gmx.de, ncaprisunfan@gmail.com, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Lars Ingebrigtsen > Cc: michael.albinus@gmx.de, ncaprisunfan@gmail.com, 49261@debbugs.gnu.org > Date: Tue, 13 Jul 2021 18:30:58 +0200 > > But I do think allowing people to inhibit locks/auto save files on a > path name basis is good functionality in general, Tramp no Tramp. What would a lock-file-name-transforms look like that inhibits file locking? And apart of remote file names, what other practical use cases can you think of where disabling locking selectively based on the file name would make sense? From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 13 13:53:35 2021 Received: (at 49261) by debbugs.gnu.org; 13 Jul 2021 17:53:35 +0000 Received: from localhost ([127.0.0.1]:41859 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m3Mb8-0003jk-S1 for submit@debbugs.gnu.org; Tue, 13 Jul 2021 13:53:35 -0400 Received: from mout.gmx.net ([212.227.17.21]:45409) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m3Mb7-0003jV-8E for 49261@debbugs.gnu.org; Tue, 13 Jul 2021 13:53:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1626198806; bh=mx/SthyR7pF33jgDJrPlu9jtYj0E9NFvaJzx56oPWqI=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=l7sMRNOyclmCedCgwZzGYEkLHKIqiP2l32WS9wUFmht3Yz6PmoMjmKzo4W134daDI bN1EOUPcWv4kkmoOQoR5yCh5FmVswm8wlDLl2+10K2N/KKTWsMx70oj9W05LvOMaEX FMIHVday2e9K6I8w1ECxIyFig1XkW2I8fikkmpho= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from gandalf.gmx.de ([213.220.146.224]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1Mq2jC-1lQC602Che-00nCRp; Tue, 13 Jul 2021 19:53:26 +0200 From: Michael Albinus To: Eli Zaretskii Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: <87v95mf2lj.fsf@gmx.de> <87pmvt3ob1.fsf@gnus.org> <87fswpgacv.fsf@gmx.de> <87bl7dfikj.fsf@gmx.de> <8735sofuqj.fsf@gmx.de> <83sg0oc83l.fsf@gnu.org> <87v95jevrm.fsf@gmx.de> <83lf6fdav4.fsf@gnu.org> <87r1g7eoor.fsf@gmx.de> <87im1jphyy.fsf@gnus.org> <87im1fd4fr.fsf@gmx.de> <83sg0jaaud.fsf@gnu.org> <87a6mrd2di.fsf@gmx.de> <838s2ba18y.fsf@gnu.org> <87pmvnsadx.fsf@gnus.org> <837dhva0vi.fsf@gnu.org> <871r83cszh.fsf@gmx.de> <834kcz9you.fsf@gnu.org> <87wnpvbc9q.fsf@gmx.de> <8335sj9ww7.fsf@gnu.org> Date: Tue, 13 Jul 2021 19:53:24 +0200 In-Reply-To: <8335sj9ww7.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 12 Jul 2021 22:04:24 +0300") Message-ID: <87h7gyaynf.fsf@gmx.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:CyID+tGlnaeyJ1AHrUY2juhbXxpd8qr9sUGM+PZzgPm3/rb+wkP IPesmTtbELa+P6VDQg2QT6dp49zCpp9tO9cqV52wp04JTis9hpiiKEwEfhqiiXC/dNWaCkB 6vs7w7GyGMiGu30NhCN6KX1lzFrKvk7Fjuo/U8e1bPC/w+CU8TTH+XcbMgwL/b5OMw50RIz ZkXMBtdWeiaxnCvC8zVKg== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:MZBt4jG7oLo=:X3lg1329VokOhBULZ+iqZH nnxbIa8SHpveVw07HZEG3ElW/Tz+WmoHXd3BABd/LHxvHcMOfwbNfr+Diz5vtcS8gCrXtR12Z knK4qk/YlGe3VriC1qnm3rrswwbXdRi1ptUEiSpoNhwlvpoF6ay+Y0UiGz0NwPNddxc7VJjJ4 67FJUuowQY756uh+IuHhHyDrWDiQQa1+wc5W4KLCIDmU6RS1/bXuCgurbE6Mb4DKcLpFbAxRQ XMhes9q2zVff4w1TILHqTRXKAGboXPSoy34dqU3uO5q1AQZvr1jBJJMfreN5iAW1Yf8BdnH88 NyL6esfvJAAQ+kUvSMcUyYZPPKQ+XrpRuSGt9polw19icn4Z+AEd/jGYFoN9F+mWSozR2lvN4 1TNzOEazPWNwG3RBk3Vk97p/p4OuK6O/3X8jrlqftO8NdQYc1hASH2uuZpfFiCD6ew0juhAEw 9vt2lUEPc1czZKwwAQZZNDlphPKRQrNfIw88vurvJYZsPeWZuPQr5CdSh1CJJ2fKD9kfzuZAU WtMMbESaZi/5Jgw2OYHUKDF1sFPdODJR7t9GXonfUTDY7YB0bqS7HRZejq2DF7/1jfQAxjtbI xIHZnSTcxKnrrGDIc4fokiKx6Y8p8UikdmP8DS7ONG3XKnDGPaY2nlhIf9LZsDHIjFmMS42FC sIetgKpfbQZJPce47H8asTZFcoFk75W3Qjp5FHeOexZgegUq1apUFZgCiRhBc5niRpCQVg/2K Z7Iir4AMFg2Ls2XCZNCBY3+v6WVdIviJ/ghy1AytbsM9iC5n6jNut9Y+GoIGwsXAyQV9g/wTq 238jbVGhrWm+ZS10To9INdrq0CmOrrgpoNDzbsLiLuJ4paDCw5axT+WPyEUbJqQmjQCSK9Poe 94LAwStg+z8YmH1M+RDXdW/RUffFGyUOwuAfavdbjVqKhapSnlrMlR+dJZVuCZYwIwVtljvMc PSWmMmYCU4uoMTYm2sxatpGmN6IOnN7/f5X88s84oVrGotLtqufgw+ssTy8Si7cNKkkW+TivL FlrVAbDj/g6StXWXtyvUOOOvtK0N4bX5qeW7R+5OKdvgsevlohFwXu2WG+ynUpn25HlQKSmPU gjQc+HJciZ999nLdVLyK+dNQjsLswsiuReC8a+X7dHF3HNS9FTMbFH2eQ== Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 49261 Cc: larsi@gnus.org, ncaprisunfan@gmail.com, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: Hi Eli, >> >> I'm OK with another user option to disable it, it doesn't matter too >> >> much. But I'm not sure whether we shall disable it by default: nobod= y(*) >> >> will enable it ever, and all the effort would be wasted. >> > >> > Now _I_ am confused: didn't you say that we _should_ disable it by >> > default for remote files, because that was how Emacs worked until now= ? >> > Or what did I miss? >> >> No. I meant we shall provide the *possibility* to disable it, because i= t >> didn't exist before. > > Ah, okay. I only said it should be disabled by default because I > thought that was what you suggested. I have no problem whatsoever to > have remote locking enabled by default. Finally, I've added `remote-file-name-inhibit-locks'. The name shall look similar to the existing `remote-file-name-inhibit-cache'. Best regards, Michael. From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 13 13:56:08 2021 Received: (at 49261) by debbugs.gnu.org; 13 Jul 2021 17:56:08 +0000 Received: from localhost ([127.0.0.1]:41873 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m3Mdc-0003pL-KI for submit@debbugs.gnu.org; Tue, 13 Jul 2021 13:56:08 -0400 Received: from mout.gmx.net ([212.227.15.18]:37481) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m3Mda-0003op-Dm for 49261@debbugs.gnu.org; Tue, 13 Jul 2021 13:56:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1626198960; bh=a5letF7EFTeIXWiyduK2lW8RPiRoRdhkiWPuxOCBSZM=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=UDtbxkgg/Pute5TLmSmsc2sFBNZxauyOyZQTJf8arNRHqpCprEWSZGxHTMYTPXm1w 3hFUBKIyG0VIcuTMNa+SH7KQn1+VNnS9XMz69D5BjQo9P3kWJtFysRJbezzJDYKFoT 6duE/WC7hDTKF9OhkhvTpZt5Hnr7AML51fThSIv8= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from gandalf.gmx.de ([213.220.146.224]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1N4z6k-1l2V4N2t0O-010saR; Tue, 13 Jul 2021 19:55:59 +0200 From: Michael Albinus To: Lars Ingebrigtsen Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: <8735sqnmei.fsf@gnus.org> <87zguyf4ht.fsf@gmx.de> <87pmvum54p.fsf@gnus.org> <87v95mf2lj.fsf@gmx.de> <87pmvt3ob1.fsf@gnus.org> <87fswpgacv.fsf@gmx.de> <87bl7dfikj.fsf@gmx.de> <8735sofuqj.fsf@gmx.de> <83sg0oc83l.fsf@gnu.org> <87v95jevrm.fsf@gmx.de> <83lf6fdav4.fsf@gnu.org> <87r1g7eoor.fsf@gmx.de> <87im1jphyy.fsf@gnus.org> <87im1fd4fr.fsf@gmx.de> <83sg0jaaud.fsf@gnu.org> <87a6mrd2di.fsf@gmx.de> <838s2ba18y.fsf@gnu.org> <87pmvnsadx.fsf@gnus.org> <837dhva0vi.fsf@gnu.org> <878s2arxa5.fsf@gnus.org> Date: Tue, 13 Jul 2021 19:55:58 +0200 In-Reply-To: <878s2arxa5.fsf@gnus.org> (Lars Ingebrigtsen's message of "Tue, 13 Jul 2021 18:30:58 +0200") Message-ID: <87czrmayj5.fsf@gmx.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:tWaTjVQTXsGlPbTG1tybrPMyffwOnLRO9B17g9n4Ilp0QQhiEO4 i1iSMRvbVmt/SVCdHRq3Ep0zCSd2sH7DiU9VOOQuvh+A09N6uNoGqmzZEN+R1PGvr3xCQwe rrXs/SlRD33yDvh5sLqBmmYn5gagbePKzC7z21dAjKxUZvdXBNC3vY/ydb32bZxbAwieRFH xPRSqzUjN1C+vR8GxvwwQ== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:WOPOQb7sbP8=:sIbgFQih0mRHSyhJDiQb1g RHcq49uk697Fge3Xk36VRJF2NdH+gkX4y9eWi4YYFq+zb3P/5Im5KM0cN5S//ITHWMb+m86W9 D8pq+sJoAvgwadYCF85+yDiAL49gMC0FJphQyDQYOW9Cide0Kx78suW3pKlY1zkaz7qtlAIP8 47wwocm9sP/ecT2LF5Gm7i/GoIB6FQnhLKmvdqBSbU/b8txFfvKSzIKm3Oe4El8NFg9jeSgrA TRPAF2Fw0xMC44OdeTjVD1kg6Z4+sTLbp+ytuW0a5nadP8zkhW+x5Lz1gKHB0Jg0YbrLCi8B0 p+mDYr593KINaf2dEYVwUlX8IkKfcBHkHrHO9NnG74uHTcN4RpoikGhjozbaWo5EKTQrdWuPt hbJH0gN2qYx9bjmGtAYtYJZlr/snNp3q1uLXBVAU6ufq6/BPgneB1wuPz5Tq13z+Q4USdx28w 9Md+16x9XDRBCYMYNQtUNCuaMRGT2Q/jlvqKUzEIcNxQg+Admq86BxbQdjC6BoAA7wxoQbY4s QjJZmubkMG3cYkr5wC80sVyY9ksPbpkk7eamxiIbU8abbDOIWbn2aSfkVkt5AcRUBmugTPwPK dwu7EOqL+c6kfizi2lkLBHxje7kK8Et4EszLlmyLBLRFdFrIcIHa3dwsnaDnetdPRSawctQRu +oWMeMYGGHnglZjPShsSpRrogr3uy2QeW/kFa6aUh9P9wxWtInQhrldNi9iDxv4j7tLwoGcYW xa0nMqr1Ez67CkDkvQ8U/l7/t3jjC8xRs6n7nn+D1G56HMm3R+CnKDACzrt14DObgDp0jRFMN 9WKu4hjTQQ9ez9mISdWPipzJwsULctY3ualo9ITYcmKUnJZ942/Tz4cbhCwQUHFnlHn5Ehgc+ XxRlTvJLkluQHkZb6ToBLKuF8UYJpAHMrt8JeR9lTumAhKIqh1+T/hqxtlxNOjw3UFmX6ieti h3cHNsdb2ToxjTtIvGxO2oVKsOj0tAw5RhG0UAvy0My60LvfUMMR5HKGnFVZPAJ+wmRDVmLkB gt1BkAMPe4e0tjiAp81NsFaR7WWRLgb2jSvcaMz8eTj+hJjHdBvhrhPZI5w5nWXJ2eoGuuXHk S/ClYnjqpbeIBPssef2ZSbDO/BRFRWUMGFMae0/959VS26ISSAhZZaRlQ== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 49261 Cc: Eli Zaretskii , ncaprisunfan@gmail.com, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Lars Ingebrigtsen writes: >> I suggested a compromise: disable it by default, but not via the >> transform function. I think it's more natural, but even if you >> disagree, would it do as a compromise? > > I don't mind adding a special Tramp variable here (perhaps there should > be one for auto save file names, too, for symmetry)? > > But I do think allowing people to inhibit locks/auto save files on a > path name basis is good functionality in general, Tramp no Tramp. Well, there is auto-save-mode, which works over the current buffer. Maybe we could use something similar for file locks? Best regards, Michael. From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 13 13:59:21 2021 Received: (at 49261) by debbugs.gnu.org; 13 Jul 2021 17:59:21 +0000 Received: from localhost ([127.0.0.1]:41892 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m3Mgj-0003vr-CI for submit@debbugs.gnu.org; Tue, 13 Jul 2021 13:59:21 -0400 Received: from mout.gmx.net ([212.227.15.18]:35613) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m3Mgh-0003vb-Lt for 49261@debbugs.gnu.org; Tue, 13 Jul 2021 13:59:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1626199153; bh=MObJhkAMgxgYSxqTAOxB/3U+q/yUnd3zBpaLlND2gkk=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=A0wqRZDClMfD9qjDWryqfqdVa8ucOILqSAoibwtlJ2Qavzy074Xw1r76hrNkQ54dv I8VLwp1PYe6cHTV8GfrTPPlL3nuyaVGrT4GDljyRWzMDOYosRkaPwerYhxdzY499na Pk4zAEWmy5gu84AggVAVH0cD7UnBugF7K+ZRz+gI= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from gandalf.gmx.de ([213.220.146.224]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MPGRz-1lmVgq1phl-00PhsX; Tue, 13 Jul 2021 19:59:13 +0200 From: Michael Albinus To: Eli Zaretskii Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: <87zguyf4ht.fsf@gmx.de> <87pmvum54p.fsf@gnus.org> <87v95mf2lj.fsf@gmx.de> <87pmvt3ob1.fsf@gnus.org> <87fswpgacv.fsf@gmx.de> <87bl7dfikj.fsf@gmx.de> <8735sofuqj.fsf@gmx.de> <83sg0oc83l.fsf@gnu.org> <87v95jevrm.fsf@gmx.de> <83lf6fdav4.fsf@gnu.org> <87r1g7eoor.fsf@gmx.de> <87im1jphyy.fsf@gnus.org> <87im1fd4fr.fsf@gmx.de> <83sg0jaaud.fsf@gnu.org> <87a6mrd2di.fsf@gmx.de> <838s2ba18y.fsf@gnu.org> <87pmvnsadx.fsf@gnus.org> <837dhva0vi.fsf@gnu.org> <878s2arxa5.fsf@gnus.org> <83o8b688v2.fsf@gnu.org> Date: Tue, 13 Jul 2021 19:59:12 +0200 In-Reply-To: <83o8b688v2.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 13 Jul 2021 19:41:05 +0300") Message-ID: <877dhuaydr.fsf@gmx.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:wIXwbJFCK5CckKn7+lRghxhDp+AoqcYvI2Oc2bvqtYgyMLQKoGt j5XR1i/sRbSvbgda6wRSdyyIbwOVAWggKZImmBkqRgxDuJkhZXuiB3vhuaj+1c1f1UBtGud l9J+nNwalP90vmS1fEa6/ZgPKVWu9871Nd2PcsW4NQ7zSqui0weu0wXaU+4Ph/3c+luuzkP V9UrzU9dkmrD5+O6ZqV+g== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:Bz5yh8STsik=:GiGpy1x8Q90m8bSLSvHXFh JrJJKJfBynZP0+LWzuaIsDSxi1PkvDUDRVQjd5cV94uHtqovaphlPMCSO02o1M2uvEQdNYDRC 6O9HLTvSSjo2mRN8G7O6SWF8vbz+h/p8kFyGi3upJ+QX/x57NgWiKISpK66SdSNdnPWdoi65S kcGE4Txh/DE3r5mmuxst4MKJdUacW+O2rEcyU0FrwQhba2bcYbLI3E3aEiLbg+p9FO0gEuLEG UO+FXJQQsqpu7IB5iNEiIaFCu5qcw/4G4pmogXCLY+1AuPkd89wPsqCqf3NJtIeliTZQapMQe LQmlPOiHFKZhifUVIC7xOuJGl+MZYlaKt8XVfYA/30+qnqgPLRG64jUU1tAEPq7sOFQUeF6wi Gk/i3KWKL+ttv+4NKlVHtKTpQ2T/cXHlgJQYN+QU71RmHvS3ssbIH9LZqve7XTRt2ZhSc+tG/ xYmyLz45x35cM/CHeXRpGpBcIBLRL5zxJ8s6X0A3taqhMLxktrLGWVmIOyKF1nuBVFzPrnr2F ygTrFMR8O+4RapHcd2WFRbjmT58kp7njE3Dc/4zJORcKT9aIslciOj1GbFT2pJAsbgMTNHPpw qamX1wBEAp0MdwHQkazCDx+LS44N47UXMYaBGUVEuQ2Gz94zuX1gLyhPIXm526JoUAsoJmUOi i1RKrYmWgiIqCwvG4s33bodJJ978s5Acyuwma6muROYGJ/UhGnp/xi9hOzemNqqbZGKn1+Fqc e6SSJnX5yei92eQKENMOu+HkAVSuzuVYuDv3EHy1z1I1JbKDyI+uZ8zFr9d+JPAL1mUDgacZN JpFa+2Qe68XeQgOYDA82u9MmQFQmh2OX0M2UALppA5FnW4Wz/w/LJX01Jfa8WlqAOWQnsickx zhv52CcGzc33+Fkf0P97Wg51xNTRc6Q9A75wvUKVB5VNs/ub+LhKe1ruoUbtLZ9wv0OVDWjVT xMCxSgS2FBndgWYHerixVbHI1xIsiQyPhulHLYXjiXEDMj22kOgqJi8nikCfoF8e0QV3TaB7p V4JDYK1N7ACImH1Q9IOTY7ErFODwiTypb4b0Yrw8+jQKM2QlX4k/FXZawQs6+sQSHNc1vhaJl 14z+/Zq5rFO/Pkc01iTiB0DzBPXR0rLkFlSsTYsrsTZ3tuHOg7+w4MsPg== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 49261 Cc: Lars Ingebrigtsen , ncaprisunfan@gmail.com, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Eli Zaretskii writes: Hi Eli, > And apart of remote file names, what other practical use cases can you > think of where disabling locking selectively based on the file name > would make sense? All file names which match `mounted-file-systems'. Best regards, Michael. From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 13 15:00:41 2021 Received: (at 49261) by debbugs.gnu.org; 13 Jul 2021 19:00:41 +0000 Received: from localhost ([127.0.0.1]:42036 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m3Ne5-0003oN-IO for submit@debbugs.gnu.org; Tue, 13 Jul 2021 15:00:41 -0400 Received: from eggs.gnu.org ([209.51.188.92]:48634) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m3Ne0-0003o3-Hs for 49261@debbugs.gnu.org; Tue, 13 Jul 2021 15:00:39 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:42004) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m3Ndu-0003Y2-HC; Tue, 13 Jul 2021 15:00:30 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:4301 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m3Ndt-00089k-GE; Tue, 13 Jul 2021 15:00:30 -0400 Date: Tue, 13 Jul 2021 22:00:23 +0300 Message-Id: <83mtqq82ew.fsf@gnu.org> From: Eli Zaretskii To: Michael Albinus In-Reply-To: <877dhuaydr.fsf@gmx.de> (message from Michael Albinus on Tue, 13 Jul 2021 19:59:12 +0200) Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: <87zguyf4ht.fsf@gmx.de> <87pmvum54p.fsf@gnus.org> <87v95mf2lj.fsf@gmx.de> <87pmvt3ob1.fsf@gnus.org> <87fswpgacv.fsf@gmx.de> <87bl7dfikj.fsf@gmx.de> <8735sofuqj.fsf@gmx.de> <83sg0oc83l.fsf@gnu.org> <87v95jevrm.fsf@gmx.de> <83lf6fdav4.fsf@gnu.org> <87r1g7eoor.fsf@gmx.de> <87im1jphyy.fsf@gnus.org> <87im1fd4fr.fsf@gmx.de> <83sg0jaaud.fsf@gnu.org> <87a6mrd2di.fsf@gmx.de> <838s2ba18y.fsf@gnu.org> <87pmvnsadx.fsf@gnus.org> <837dhva0vi.fsf@gnu.org> <878s2arxa5.fsf@gnus.org> <83o8b688v2.fsf@gnu.org> <877dhuaydr.fsf@gmx.de> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49261 Cc: larsi@gnus.org, ncaprisunfan@gmail.com, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Michael Albinus > Cc: Lars Ingebrigtsen , ncaprisunfan@gmail.com, > 49261@debbugs.gnu.org > Date: Tue, 13 Jul 2021 19:59:12 +0200 > > > And apart of remote file names, what other practical use cases can you > > think of where disabling locking selectively based on the file name > > would make sense? > > All file names which match `mounted-file-systems'. Shouldn't file locking be disabled there by default, and never enabled? From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 13 15:05:15 2021 Received: (at 49261) by debbugs.gnu.org; 13 Jul 2021 19:05:15 +0000 Received: from localhost ([127.0.0.1]:42041 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m3NiV-0003v4-3q for submit@debbugs.gnu.org; Tue, 13 Jul 2021 15:05:15 -0400 Received: from quimby.gnus.org ([95.216.78.240]:34096) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m3NiS-0003un-E6 for 49261@debbugs.gnu.org; Tue, 13 Jul 2021 15:05:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=4CoQoo6PH/v9OkYkvSVU/ZiDYolfW8qrisQNTL+VAZI=; b=Bc+PqUWhYotdZju4ZYgqFM46wh 0PNM5cjTcfGlmeixBRT8x5YLfEsZ0cHsJjaFcAHZKRLP03lYMSdL6DR7XnNAoxs4Y4UlUQYnldifd Vc5TTZsOHAD5m+xvLY8pb6FTLxc1xO6J6a8MyKe8qNJp1pxJq0FvsAWXO/FSfXs10sgI=; Received: from cm-84.212.220.105.getinternet.no ([84.212.220.105] helo=elva) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m3NiJ-0003as-CB; Tue, 13 Jul 2021 21:05:05 +0200 From: Lars Ingebrigtsen To: Michael Albinus Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: <87zguyf4ht.fsf@gmx.de> <87pmvum54p.fsf@gnus.org> <87v95mf2lj.fsf@gmx.de> <87pmvt3ob1.fsf@gnus.org> <87fswpgacv.fsf@gmx.de> <87bl7dfikj.fsf@gmx.de> <8735sofuqj.fsf@gmx.de> <83sg0oc83l.fsf@gnu.org> <87v95jevrm.fsf@gmx.de> <83lf6fdav4.fsf@gnu.org> <87r1g7eoor.fsf@gmx.de> <87im1jphyy.fsf@gnus.org> <87im1fd4fr.fsf@gmx.de> <83sg0jaaud.fsf@gnu.org> <87a6mrd2di.fsf@gmx.de> <838s2ba18y.fsf@gnu.org> <87pmvnsadx.fsf@gnus.org> <837dhva0vi.fsf@gnu.org> <878s2arxa5.fsf@gnus.org> <87czrmayj5.fsf@gmx.de> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwAgMAAAAqbBEUAAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAACVBMVEUpIRC+rE3///8D 5IVeAAAAAWJLR0QCZgt8ZAAAAAlwSFlzAAALEgAACxIB0t1+/AAAAAd0SU1FB+UHDRMEImV7vZUA AAC3SURBVCjPlZJBDgMhCEUhkf0syn0k6eydxH//q1TRUZpJF2VheH6FT5Tod7CIKR2JmP4Nzm0Z FxUXytxlBRS15wIDyovgOTJQFe0WwwELzqigg5eaQBsybVg+cPd2ePjMHNRK40Cv2kp7wdvOApvW nspvsCIbaDj3lubHrtG2geIs6TakeEM8O5ofSbBbackVp/iaq+40cYAax/dR04KygA9/nAklQg4w YoNY+CQyXkItb6CuV6EPMAY6nV361zgAAABaZVhJZk1NACoAAAAIAAUBEgADAAAAAQABAAABGgAF AAAAAQAAAEoBGwAFAAAAAQAAAFIBKAADAAAAAQACAAACEwADAAAAAQABAAAAAAAAAAAASAAAAAEA AABIAAAAAR9S9zQAAAAldEVYdGRhdGU6Y3JlYXRlADIwMjEtMDctMTNUMTk6MDQ6MzMrMDA6MDBT 8qBSAAAAJXRFWHRkYXRlOm1vZGlmeQAyMDIxLTA3LTEzVDE5OjA0OjMzKzAwOjAwIq8Y7gAAABd0 RVh0ZXhpZjpZQ2JDclBvc2l0aW9uaW5nADGsD4BjAAAAAElFTkSuQmCC X-Now-Playing: Steven Brown's _Live in Tilburg_: "A Quoi Ca Sert L'Amour" Date: Tue, 13 Jul 2021 21:05:02 +0200 In-Reply-To: <87czrmayj5.fsf@gmx.de> (Michael Albinus's message of "Tue, 13 Jul 2021 19:55:58 +0200") Message-ID: <87k0luox0h.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Michael Albinus writes: > Well, there is auto-save-mode, which works over the current buffer. Maybe > we could use something similar for file locks? Yeah, I think that's a good idea (but in addition to disabling based on file name regexps). Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49261 Cc: Eli Zaretskii , ncaprisunfan@gmail.com, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Michael Albinus writes: > Well, there is auto-save-mode, which works over the current buffer. Maybe > we could use something similar for file locks? Yeah, I think that's a good idea (but in addition to disabling based on file name regexps). -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 13 15:09:14 2021 Received: (at 49261) by debbugs.gnu.org; 13 Jul 2021 19:09:14 +0000 Received: from localhost ([127.0.0.1]:42046 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m3NmM-00040b-Kn for submit@debbugs.gnu.org; Tue, 13 Jul 2021 15:09:14 -0400 Received: from quimby.gnus.org ([95.216.78.240]:34190) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m3NmL-00040Q-IM for 49261@debbugs.gnu.org; Tue, 13 Jul 2021 15:09:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=p1PRIlF7H+qoO+jC6LMyi7dTeUSnWpFZxnwsiFOyn1E=; b=pcD057tHO7wXDv6028eEV+dP5l x/Q3V48Etu/omhP3L49kNWS0YCe4L/UVvMgtGxolqdlTKdQKCjMUnAITuQ4jrcrNG/evYyIWYycbm ML+FBYcuYEdNeV0MUMVS61tGW4ZjnB+ryYiTqUMO40mK7Rj+2+vyrbLkKwGOTzKFLvik=; Received: from cm-84.212.220.105.getinternet.no ([84.212.220.105] helo=elva) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m3NmC-0003cq-U7; Tue, 13 Jul 2021 21:09:07 +0200 From: Lars Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: <87v95mf2lj.fsf@gmx.de> <87pmvt3ob1.fsf@gnus.org> <87fswpgacv.fsf@gmx.de> <87bl7dfikj.fsf@gmx.de> <8735sofuqj.fsf@gmx.de> <83sg0oc83l.fsf@gnu.org> <87v95jevrm.fsf@gmx.de> <83lf6fdav4.fsf@gnu.org> <87r1g7eoor.fsf@gmx.de> <87im1jphyy.fsf@gnus.org> <87im1fd4fr.fsf@gmx.de> <83sg0jaaud.fsf@gnu.org> <87a6mrd2di.fsf@gmx.de> <838s2ba18y.fsf@gnu.org> <87pmvnsadx.fsf@gnus.org> <837dhva0vi.fsf@gnu.org> <878s2arxa5.fsf@gnus.org> <83o8b688v2.fsf@gnu.org> <877dhuaydr.fsf@gmx.de> <83mtqq82ew.fsf@gnu.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwAgMAAAAqbBEUAAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAACVBMVEUpIRC+rE3///8D 5IVeAAAAAWJLR0QCZgt8ZAAAAAlwSFlzAAALEgAACxIB0t1+/AAAAAd0SU1FB+UHDRMEImV7vZUA AAC3SURBVCjPlZJBDgMhCEUhkf0syn0k6eydxH//q1TRUZpJF2VheH6FT5Tod7CIKR2JmP4Nzm0Z FxUXytxlBRS15wIDyovgOTJQFe0WwwELzqigg5eaQBsybVg+cPd2ePjMHNRK40Cv2kp7wdvOApvW nspvsCIbaDj3lubHrtG2geIs6TakeEM8O5ofSbBbackVp/iaq+40cYAax/dR04KygA9/nAklQg4w YoNY+CQyXkItb6CuV6EPMAY6nV361zgAAABaZVhJZk1NACoAAAAIAAUBEgADAAAAAQABAAABGgAF AAAAAQAAAEoBGwAFAAAAAQAAAFIBKAADAAAAAQACAAACEwADAAAAAQABAAAAAAAAAAAASAAAAAEA AABIAAAAAR9S9zQAAAAldEVYdGRhdGU6Y3JlYXRlADIwMjEtMDctMTNUMTk6MDQ6MzMrMDA6MDBT 8qBSAAAAJXRFWHRkYXRlOm1vZGlmeQAyMDIxLTA3LTEzVDE5OjA0OjMzKzAwOjAwIq8Y7gAAABd0 RVh0ZXhpZjpZQ2JDclBvc2l0aW9uaW5nADGsD4BjAAAAAElFTkSuQmCC X-Now-Playing: Steven Brown's _Live in Tilburg_: "A Quoi Ca Sert L'Amour" Date: Tue, 13 Jul 2021 21:09:03 +0200 In-Reply-To: <83mtqq82ew.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 13 Jul 2021 22:00:23 +0300") Message-ID: <87fswiowts.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Eli Zaretskii writes: >> > And apart of remote file names, what other practical use cases can you >> > think of where disabling locking selectively based on the file name >> > would make sense? >> >> All file names which m [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49261 Cc: Michael Albinus , ncaprisunfan@gmail.com, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: >> > And apart of remote file names, what other practical use cases can you >> > think of where disabling locking selectively based on the file name >> > would make sense? >> >> All file names which match `mounted-file-systems'. > > Shouldn't file locking be disabled there by default, and never > enabled? Disabling file locking there (and backup files too, perhaps?) would make sense, but the user should be able to override it. (They may have directories called "/media" that's not a mounted file system.) As for other use cases -- I have, for instance, some automated processes on several systems that write to the same file, and file locking of that file has tripped me up before. I've now rewritten those processes to work differently, but if `lock-file-name-transforms' had existed before (and allowed disabling locking based on regexps) I would have used that instead. I'm sure there's as many use cases for disabling auto-save/locking based on regexps as there are for transforming the file names. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 13 15:36:53 2021 Received: (at 49261) by debbugs.gnu.org; 13 Jul 2021 19:36:53 +0000 Received: from localhost ([127.0.0.1]:42072 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m3OD6-0006rJ-VX for submit@debbugs.gnu.org; Tue, 13 Jul 2021 15:36:53 -0400 Received: from mout.gmx.net ([212.227.15.18]:33615) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m3OD5-0006qt-6x for 49261@debbugs.gnu.org; Tue, 13 Jul 2021 15:36:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1626205004; bh=qFMKbR8sVvErLOpqsKu1tHqeL6j/oOrcMq21N2e7E10=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=fouMLBT736uM0NETtJmVmbhI33/s2e20jL8j9sBA7MAui0xhCj812f6lgIfoKu2Ej UEQgsVlOjGfqVke6rgiVPQU6wMKzgIyJJ/mUM14GQYH8jsrDSfGGwCFXVyDZVoNQTh Nrv0+e9RokMoXR8Sbn0Ar37FWdozfwQfUWSEL/2c= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from gandalf.gmx.de ([213.220.146.224]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1McH9i-1lQkbI1frQ-00cedw; Tue, 13 Jul 2021 21:36:44 +0200 From: Michael Albinus To: Eli Zaretskii Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: <87v95mf2lj.fsf@gmx.de> <87pmvt3ob1.fsf@gnus.org> <87fswpgacv.fsf@gmx.de> <87bl7dfikj.fsf@gmx.de> <8735sofuqj.fsf@gmx.de> <83sg0oc83l.fsf@gnu.org> <87v95jevrm.fsf@gmx.de> <83lf6fdav4.fsf@gnu.org> <87r1g7eoor.fsf@gmx.de> <87im1jphyy.fsf@gnus.org> <87im1fd4fr.fsf@gmx.de> <83sg0jaaud.fsf@gnu.org> <87a6mrd2di.fsf@gmx.de> <838s2ba18y.fsf@gnu.org> <87pmvnsadx.fsf@gnus.org> <837dhva0vi.fsf@gnu.org> <878s2arxa5.fsf@gnus.org> <83o8b688v2.fsf@gnu.org> <877dhuaydr.fsf@gmx.de> <83mtqq82ew.fsf@gnu.org> Date: Tue, 13 Jul 2021 21:36:42 +0200 In-Reply-To: <83mtqq82ew.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 13 Jul 2021 22:00:23 +0300") Message-ID: <8735siatv9.fsf@gmx.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:pZXbeFzVX2VAjVsOE8PkYMYPskGadTMmcrD4umtuMTnMnDMyCd9 rdGmGzGMU4ILgTqqCst1KKEhojnPzLvKtfUQM0r9eX8Ph9DuDYw/ZLow4WPg+nOUN4+WL40 LZoy+3mDGXvKWJfKTllj0PorJn/yrGfE+WkzCiIeI2k/YWPNsi/qvEQcTmQa06j3lBwRt3l d6H6DB8T3fh6nORoZRNQQ== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:OUf8d1eJzSQ=:o4wxbzhPHvfGz9NGrWjAQO ReUi00aAJLIdNEK6ETaaOe6YciIuKt1m26pSPOGZC5YDundi+eBmrQZMsmyqnFPJ7J66f1+NA M5aJA55YJXubZS996AQ/e6doRrbTx2/yBc3LRIfZg8lYAT+EoYUohmLIJ4UKQ6BX2MOBN6zvi G9298I8c5ncSnPtBMLMzr/P2fByJeoAFOghFFuw/iVjNzk9O+DsJR2cli4H7CZJZRYCPqhXgE jqc6h/TcCKgu9BqN4L7I5wscenJyu8R3EOaT1gk/ll8dYVqxCVAehvcL9EOpj6sNtJJsgMbZ8 sey9MFz8VFGW8R4BCdjTEcTdCysRQUIDUgFtWOV+Mh2IG5krnCKEAnEU4LH7itSFOoVwm3JQg hYKY4V07ynnmgJAaLRis/idXPCgumG0otArq0jw99Z8cd0zUXTjK1Vuz8DsvcqTRycqnxKT6b QNL3xz4Lr1DLw02sIDNoo7Bf5kBORQo+7qO0vcv364cxZgsBfIpsLPdhDs9ir3JDpyA9kJmBo Q7Gy/ZnBSXXFdlQMGKkDdZkQxfB5QJ2SS6UFdAmCvELRqxtB2hgEIpQOkmZWEcI1h9L85lMoW gUfHl31VADGRL37tiCJwgqWt+2jaigg9Tzzw50eA1ascSHZ5/PxT4d+qNDfQf45SNUpxFvqXx m5RmbYWcbo5bA40yRcqg/tOox8Wn3xkpoghzsUW/wWajzJ3PpNnXGjeYYUQ0tprVGTdk00Mxc b7qB4EtqecfHegZDx96mLALXHdqPsaIKSvsgW4h2OGQ2LYzoK2bFcODjSPjdMrG+hP2FsJUaP qvPP0i07FG0/h5eJ9X9PfnsuS435JtmMIZdhOIA6At+r/nn9+okoyP5D4eGSd6gsWBgNuE3fa hXHf/gx5/EDjkytkna0exAI6KS/qrDw+KCNhehZo+Qg6EQ1HSzhqG4COFPQfAbZ9766x6pOzI GL0k4HSwln9OOexx44dL2/t/mz1pshW30vSM1OU/JOm81uRUQXYcV7F6QgVp0fMvCw99MdD9v LBwWmGlpCvCdvI/XeUTKrwP0iwpQ8+HnmPWl0nFfJBJ+m69Cf34++KFvp8rRKJvV3SjqJe/H2 dcf6QTZAoMSnZuevqsKitTlgH57Va8qQxz+KWD23PjNsYBaplw6DT45Cg== Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 49261 Cc: larsi@gnus.org, ncaprisunfan@gmail.com, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Eli Zaretskii writes: >> > And apart of remote file names, what other practical use cases can yo= u >> > think of where disabling locking selectively based on the file name >> > would make sense? >> >> All file names which match `mounted-file-systems'. > > Shouldn't file locking be disabled there by default, and never > enabled? Don't know. At least now, it isn't disabled, and people do not protest. Best regards, Michael. From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 13 19:12:09 2021 Received: (at 49261) by debbugs.gnu.org; 13 Jul 2021 23:12:09 +0000 Received: from localhost ([127.0.0.1]:42413 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m3RZQ-0008Md-UP for submit@debbugs.gnu.org; Tue, 13 Jul 2021 19:12:09 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:60988) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m3RZP-0008MR-P9 for 49261@debbugs.gnu.org; Tue, 13 Jul 2021 19:12:08 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 5D5301600EF; Tue, 13 Jul 2021 16:12:02 -0700 (PDT) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id ADTQaidYxoW9; Tue, 13 Jul 2021 16:12:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id AA2D61600F1; Tue, 13 Jul 2021 16:12:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ykgbgCA_f1Sn; Tue, 13 Jul 2021 16:12:01 -0700 (PDT) Received: from [192.168.0.205] (ip72-206-1-93.fv.ks.cox.net [72.206.1.93]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 4FD1D16006C; Tue, 13 Jul 2021 16:12:01 -0700 (PDT) Subject: Re: bug#49261: Segfault during loadup To: Eli Zaretskii References: <87o8bn7bie.fsf@gnus.org> <87zgv6vuon.fsf@gmx.de> <837di9lwbm.fsf@gnu.org> <87a6n5vuu4.fsf@gnus.org> <8735sqnmei.fsf@gnus.org> <87zguyf4ht.fsf@gmx.de> <87pmvum54p.fsf@gnus.org> <87v95mf2lj.fsf@gmx.de> <87pmvt3ob1.fsf@gnus.org> <83r1g9evoy.fsf@gnu.org> <83pmvtevgg.fsf@gnu.org> <87czrt3mj4.fsf@gnus.org> <878s2h3m1d.fsf@gnus.org> <874kd53lnl.fsf@gnus.org> <87zgux26ab.fsf@gnus.org> <87pmvt25uq.fsf@gnus.org> <87lf6h2294.fsf@gnus.org> <87h7h51x9y.fsf_-_@gnus.org> <83bl79b17n.fsf@gnu.org> <835yxgc1pm.fsf@gnu.org> <83wnpvag6z.fsf@gnu.org> <5608bf0a-7211-73a9-690f-c869a1cb3c9d@cs.ucla.edu> <83o8b7a5ow.fsf@gnu.org> From: Paul Eggert Message-ID: Date: Tue, 13 Jul 2021 18:12:00 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <83o8b7a5ow.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Spam-Score: -2.7 (--) X-Debbugs-Envelope-To: 49261 Cc: larsi@gnus.org, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.7 (---) On 7/12/21 10:54 AM, Eli Zaretskii wrote: > Then what is the -Woverflow option for? Can you show an example of > code which -Woverflow would flag that doesn't produce a bogus warning? Sure: the GCC documentation says -Woverflow is supposed to warn about "compile-time overflow in constant expressions". So GCC should (and does) warn about this top-level declaration: int x = INT_MAX + 1; However, there is no overflow here: unsigned a = -1, b = INT_MIN, c = LLONG_MAX; and these declarations have well-defined behavior in C, so -Woverflow should not issue warnings for them even though they are unsigned conversions that change numeric values. It might be useful to some programmers to generate warnings about these unsigned conversions, but this should be a separate -W option not -Woverflow. There's no overflow here. From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 14 03:43:00 2021 Received: (at 49261) by debbugs.gnu.org; 14 Jul 2021 07:43:00 +0000 Received: from localhost ([127.0.0.1]:42753 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m3ZXo-0005ql-GD for submit@debbugs.gnu.org; Wed, 14 Jul 2021 03:43:00 -0400 Received: from mail-out.m-online.net ([212.18.0.10]:37008) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m3ZXm-0005qc-7C for 49261@debbugs.gnu.org; Wed, 14 Jul 2021 03:42:58 -0400 Received: from frontend01.mail.m-online.net (unknown [192.168.8.182]) by mail-out.m-online.net (Postfix) with ESMTP id 4GPqH41LkCz1sCwg; Wed, 14 Jul 2021 09:42:55 +0200 (CEST) Received: from localhost (dynscan1.mnet-online.de [192.168.6.70]) by mail.m-online.net (Postfix) with ESMTP id 4GPqH333ZJz1qtH6; Wed, 14 Jul 2021 09:42:55 +0200 (CEST) X-Virus-Scanned: amavisd-new at mnet-online.de Received: from mail.mnet-online.de ([192.168.8.182]) by localhost (dynscan1.mail.m-online.net [192.168.6.70]) (amavisd-new, port 10024) with ESMTP id 1Y7_Htlo9htZ; Wed, 14 Jul 2021 09:42:54 +0200 (CEST) X-Auth-Info: CFakBnF4/YvEs7Uhan6xIdFRp3hJ/6UKYYgbStA4twu+30/rmJocarUmwyvssPiG Received: from igel.home (ppp-46-244-191-35.dynamic.mnet-online.de [46.244.191.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.mnet-online.de (Postfix) with ESMTPSA; Wed, 14 Jul 2021 09:42:54 +0200 (CEST) Received: by igel.home (Postfix, from userid 1000) id 040522C0EBE; Wed, 14 Jul 2021 09:42:53 +0200 (CEST) From: Andreas Schwab To: Paul Eggert Subject: Re: bug#49261: Segfault during loadup References: <87pmvum54p.fsf@gnus.org> <87v95mf2lj.fsf@gmx.de> <87pmvt3ob1.fsf@gnus.org> <83r1g9evoy.fsf@gnu.org> <83pmvtevgg.fsf@gnu.org> <87czrt3mj4.fsf@gnus.org> <878s2h3m1d.fsf@gnus.org> <874kd53lnl.fsf@gnus.org> <87zgux26ab.fsf@gnus.org> <87pmvt25uq.fsf@gnus.org> <87lf6h2294.fsf@gnus.org> <87h7h51x9y.fsf_-_@gnus.org> <83bl79b17n.fsf@gnu.org> <835yxgc1pm.fsf@gnu.org> <83wnpvag6z.fsf@gnu.org> <5608bf0a-7211-73a9-690f-c869a1cb3c9d@cs.ucla.edu> <83o8b7a5ow.fsf@gnu.org> X-Yow: The PINK SOCKS were ORIGINALLY from 1952!! But they went to MARS around 1953!! Date: Wed, 14 Jul 2021 09:42:53 +0200 In-Reply-To: (Paul Eggert's message of "Tue, 13 Jul 2021 18:12:00 -0500") Message-ID: <87lf69e3ya.fsf@igel.home> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.5 (/) X-Debbugs-Envelope-To: 49261 Cc: Eli Zaretskii , larsi@gnus.org, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.4 (-) On Jul 13 2021, Paul Eggert wrote: > However, there is no overflow here: > > unsigned a = -1, b = INT_MIN, c = LLONG_MAX; > > and these declarations have well-defined behavior in C, This is a bogus argument. You can write total bullshit by using only well-defined C. And assinging a wider constant to a narrow object, losing bits, is likely hiding a bug. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different." From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 14 08:36:52 2021 Received: (at 49261) by debbugs.gnu.org; 14 Jul 2021 12:36:52 +0000 Received: from localhost ([127.0.0.1]:43285 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m3e8C-0005lK-Kl for submit@debbugs.gnu.org; Wed, 14 Jul 2021 08:36:52 -0400 Received: from eggs.gnu.org ([209.51.188.92]:46664) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m3e8A-0005l1-LU for 49261@debbugs.gnu.org; Wed, 14 Jul 2021 08:36:51 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:38136) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m3e82-0000OX-Oo; Wed, 14 Jul 2021 08:36:43 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:1084 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m3e7Z-0002wb-RF; Wed, 14 Jul 2021 08:36:21 -0400 Date: Wed, 14 Jul 2021 15:36:11 +0300 Message-Id: <83eec1843o.fsf@gnu.org> From: Eli Zaretskii To: Paul Eggert In-Reply-To: (message from Paul Eggert on Tue, 13 Jul 2021 18:12:00 -0500) Subject: Re: bug#49261: Segfault during loadup References: <87o8bn7bie.fsf@gnus.org> <87zgv6vuon.fsf@gmx.de> <837di9lwbm.fsf@gnu.org> <87a6n5vuu4.fsf@gnus.org> <8735sqnmei.fsf@gnus.org> <87zguyf4ht.fsf@gmx.de> <87pmvum54p.fsf@gnus.org> <87v95mf2lj.fsf@gmx.de> <87pmvt3ob1.fsf@gnus.org> <83r1g9evoy.fsf@gnu.org> <83pmvtevgg.fsf@gnu.org> <87czrt3mj4.fsf@gnus.org> <878s2h3m1d.fsf@gnus.org> <874kd53lnl.fsf@gnus.org> <87zgux26ab.fsf@gnus.org> <87pmvt25uq.fsf@gnus.org> <87lf6h2294.fsf@gnus.org> <87h7h51x9y.fsf_-_@gnus.org> <83bl79b17n.fsf@gnu.org> <835yxgc1pm.fsf@gnu.org> <83wnpvag6z.fsf@gnu.org> <5608bf0a-7211-73a9-690f-c869a1cb3c9d@cs.ucla.edu> <83o8b7a5ow.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49261 Cc: larsi@gnus.org, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: larsi@gnus.org, 49261@debbugs.gnu.org > From: Paul Eggert > Date: Tue, 13 Jul 2021 18:12:00 -0500 > > On 7/12/21 10:54 AM, Eli Zaretskii wrote: > > Then what is the -Woverflow option for? Can you show an example of > > code which -Woverflow would flag that doesn't produce a bogus warning? > > Sure: the GCC documentation says -Woverflow is supposed to warn about > "compile-time overflow in constant expressions". So GCC should (and > does) warn about this top-level declaration: > > int x = INT_MAX + 1; > > However, there is no overflow here: > > unsigned a = -1, b = INT_MIN, c = LLONG_MAX; You are saying that there's some fundamental difference between INT_MAX + 1 and (USE_LSB_TAG ? - (1 << GCTYPEBITS) : VAL_MAX) ? Or between an expression 'x = FOO' and 'mask = BAR'? I don't see any fundamental difference. IMO, the warning was valid, as the assignment loses significant bits. From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 14 18:04:45 2021 Received: (at 49261) by debbugs.gnu.org; 14 Jul 2021 22:04:45 +0000 Received: from localhost ([127.0.0.1]:46046 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m3mzl-00070F-Eu for submit@debbugs.gnu.org; Wed, 14 Jul 2021 18:04:45 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:49608) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m3mzj-000700-3F for 49261@debbugs.gnu.org; Wed, 14 Jul 2021 18:04:43 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 906451600B2; Wed, 14 Jul 2021 15:04:37 -0700 (PDT) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id RSOyX0JJ_nDT; Wed, 14 Jul 2021 15:04:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 864621600B7; Wed, 14 Jul 2021 15:04:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 8qhsaBGpYUtS; Wed, 14 Jul 2021 15:04:36 -0700 (PDT) Received: from [192.168.0.205] (ip72-206-1-93.fv.ks.cox.net [72.206.1.93]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 16EEF1600B2; Wed, 14 Jul 2021 15:04:36 -0700 (PDT) Subject: Re: bug#49261: Segfault during loadup To: Andreas Schwab References: <87pmvum54p.fsf@gnus.org> <87v95mf2lj.fsf@gmx.de> <87pmvt3ob1.fsf@gnus.org> <83r1g9evoy.fsf@gnu.org> <83pmvtevgg.fsf@gnu.org> <87czrt3mj4.fsf@gnus.org> <878s2h3m1d.fsf@gnus.org> <874kd53lnl.fsf@gnus.org> <87zgux26ab.fsf@gnus.org> <87pmvt25uq.fsf@gnus.org> <87lf6h2294.fsf@gnus.org> <87h7h51x9y.fsf_-_@gnus.org> <83bl79b17n.fsf@gnu.org> <835yxgc1pm.fsf@gnu.org> <83wnpvag6z.fsf@gnu.org> <5608bf0a-7211-73a9-690f-c869a1cb3c9d@cs.ucla.edu> <83o8b7a5ow.fsf@gnu.org> <87lf69e3ya.fsf@igel.home> From: Paul Eggert Message-ID: Date: Wed, 14 Jul 2021 17:04:35 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <87lf69e3ya.fsf@igel.home> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49261 Cc: Eli Zaretskii , larsi@gnus.org, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) On 7/14/21 2:42 AM, Andreas Schwab wrote: > On Jul 13 2021, Paul Eggert wrote: > >> However, there is no overflow here: >> >> unsigned a = -1, b = INT_MIN, c = LLONG_MAX; >> >> and these declarations have well-defined behavior in C, > This is a bogus argument. It's not bogus. I quoted the GCC documentation and noted that GCC's behavior does not match its documentation. At the very least -- even if you like GCC's behavior, which I don't -- the documentation should match the behavior. > assinging a wider constant to a narrow object, > losing bits, is likely hiding a bug. If that's what you think -Woverflow should do, then GCC doesn't do that either. For example: unsigned char a = -1, b = 255; This generates no warning with -Woverflow, even though A's initialization assigns a wider constant to a narrow object, losing bits. Without looking at GCC's source code, it's not clear what -Woverflow actually does. It is a bit of a mess. Certainly -Woverflow does not do what it's documented to do. From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 14 18:10:50 2021 Received: (at 49261) by debbugs.gnu.org; 14 Jul 2021 22:10:50 +0000 Received: from localhost ([127.0.0.1]:46050 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m3n5e-00079v-3s for submit@debbugs.gnu.org; Wed, 14 Jul 2021 18:10:50 -0400 Received: from mail-out.m-online.net ([212.18.0.10]:52634) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m3n5c-00079m-HL for 49261@debbugs.gnu.org; Wed, 14 Jul 2021 18:10:49 -0400 Received: from frontend01.mail.m-online.net (unknown [192.168.8.182]) by mail-out.m-online.net (Postfix) with ESMTP id 4GQBXQ4XDKz1s9Qv; Thu, 15 Jul 2021 00:10:45 +0200 (CEST) Received: from localhost (dynscan1.mnet-online.de [192.168.6.70]) by mail.m-online.net (Postfix) with ESMTP id 4GQBXP4QnNz1qtHD; Thu, 15 Jul 2021 00:10:45 +0200 (CEST) X-Virus-Scanned: amavisd-new at mnet-online.de Received: from mail.mnet-online.de ([192.168.8.182]) by localhost (dynscan1.mail.m-online.net [192.168.6.70]) (amavisd-new, port 10024) with ESMTP id 0tPjA7fs5Jnv; Thu, 15 Jul 2021 00:10:44 +0200 (CEST) X-Auth-Info: yn1YupjMOObsRL8DbH5w1fbeAlT/1kDVdOypzRMMq76oUv0Kde/EPEoXIUDBWnjR Received: from igel.home (ppp-46-244-191-35.dynamic.mnet-online.de [46.244.191.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.mnet-online.de (Postfix) with ESMTPSA; Thu, 15 Jul 2021 00:10:44 +0200 (CEST) Received: by igel.home (Postfix, from userid 1000) id 5E8D72C2599; Thu, 15 Jul 2021 00:10:44 +0200 (CEST) From: Andreas Schwab To: Paul Eggert Subject: Re: bug#49261: Segfault during loadup References: <87pmvt3ob1.fsf@gnus.org> <83r1g9evoy.fsf@gnu.org> <83pmvtevgg.fsf@gnu.org> <87czrt3mj4.fsf@gnus.org> <878s2h3m1d.fsf@gnus.org> <874kd53lnl.fsf@gnus.org> <87zgux26ab.fsf@gnus.org> <87pmvt25uq.fsf@gnus.org> <87lf6h2294.fsf@gnus.org> <87h7h51x9y.fsf_-_@gnus.org> <83bl79b17n.fsf@gnu.org> <835yxgc1pm.fsf@gnu.org> <83wnpvag6z.fsf@gnu.org> <5608bf0a-7211-73a9-690f-c869a1cb3c9d@cs.ucla.edu> <83o8b7a5ow.fsf@gnu.org> <87lf69e3ya.fsf@igel.home> X-Yow: Is there something I should be DOING with a GLAZED DONUT?? Date: Thu, 15 Jul 2021 00:10:44 +0200 In-Reply-To: (Paul Eggert's message of "Wed, 14 Jul 2021 17:04:35 -0500") Message-ID: <871r80eecb.fsf@igel.home> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.4 (/) X-Debbugs-Envelope-To: 49261 Cc: Eli Zaretskii , larsi@gnus.org, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.4 (-) On Jul 14 2021, Paul Eggert wrote: > This generates no warning with -Woverflow, even though A's initialization > assigns a wider constant to a narrow object, losing bits. This is always safe. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different." From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 14 18:24:46 2021 Received: (at 49261) by debbugs.gnu.org; 14 Jul 2021 22:24:47 +0000 Received: from localhost ([127.0.0.1]:46076 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m3nJ8-0007XV-LK for submit@debbugs.gnu.org; Wed, 14 Jul 2021 18:24:46 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:52554) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m3nJ7-0007XG-7o for 49261@debbugs.gnu.org; Wed, 14 Jul 2021 18:24:46 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 5ACE31600B2; Wed, 14 Jul 2021 15:24:39 -0700 (PDT) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id qtKkR--N47eU; Wed, 14 Jul 2021 15:24:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 7AC131600BB; Wed, 14 Jul 2021 15:24:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id UqQByrT1OQyk; Wed, 14 Jul 2021 15:24:38 -0700 (PDT) Received: from [192.168.0.205] (ip72-206-1-93.fv.ks.cox.net [72.206.1.93]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 18AF61600B2; Wed, 14 Jul 2021 15:24:38 -0700 (PDT) Subject: Re: bug#49261: Segfault during loadup To: Eli Zaretskii References: <87o8bn7bie.fsf@gnus.org> <87zgv6vuon.fsf@gmx.de> <837di9lwbm.fsf@gnu.org> <87a6n5vuu4.fsf@gnus.org> <8735sqnmei.fsf@gnus.org> <87zguyf4ht.fsf@gmx.de> <87pmvum54p.fsf@gnus.org> <87v95mf2lj.fsf@gmx.de> <87pmvt3ob1.fsf@gnus.org> <83r1g9evoy.fsf@gnu.org> <83pmvtevgg.fsf@gnu.org> <87czrt3mj4.fsf@gnus.org> <878s2h3m1d.fsf@gnus.org> <874kd53lnl.fsf@gnus.org> <87zgux26ab.fsf@gnus.org> <87pmvt25uq.fsf@gnus.org> <87lf6h2294.fsf@gnus.org> <87h7h51x9y.fsf_-_@gnus.org> <83bl79b17n.fsf@gnu.org> <835yxgc1pm.fsf@gnu.org> <83wnpvag6z.fsf@gnu.org> <5608bf0a-7211-73a9-690f-c869a1cb3c9d@cs.ucla.edu> <83o8b7a5ow.fsf@gnu.org> <83eec1843o.fsf@gnu.org> From: Paul Eggert Message-ID: <33801f54-3794-d98c-54c3-c67ce53ec6c0@cs.ucla.edu> Date: Wed, 14 Jul 2021 17:24:37 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <83eec1843o.fsf@gnu.org> Content-Type: multipart/mixed; boundary="------------6132E8812C143D05C8BD6D80" Content-Language: en-US X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49261 Cc: larsi@gnus.org, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) This is a multi-part message in MIME format. --------------6132E8812C143D05C8BD6D80 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 7/14/21 7:36 AM, Eli Zaretskii wrote: > You are saying that there's some fundamental difference between > > INT_MAX + 1 > > and > > (USE_LSB_TAG ? - (1 << GCTYPEBITS) : VAL_MAX) Yes there's a fundamental difference. INT_MAX + 1 has a signed integer overflow that violates the C standard. Obviously GCC should diagnose it. The other expression conforms to the C standard and there is no error or overflow there. There's no reason -Woverflow should provoke a diagnostic for it. > Or between an expression 'x = FOO' and 'mask = BAR'? I don't know what x, mask, FOO, and BAR refer to. > the warning was valid, as the > assignment loses significant bits. I originally wrote it as "uintptr_t mask = VALMASK;" because I would rather avoid C casts when possible (they're too powerful and allow too many bugs to go undetected). I dislike the workaround that I installed because of (a) its unnecessary cast and (b) the lack of clarity that it's intended that we want to discard any bits outside UINTPTR_MAX ((b) was a problem with my original code too). To try to fix both (a) and (b) I installed the attached further patch. It is a bit more verbose than what C requires, but the verbosity should help explain that masking with UINTPTR_MAX is intended, and the verbosity shouldn't hurt efficiency. --------------6132E8812C143D05C8BD6D80 Content-Type: text/x-patch; charset=UTF-8; name="0001-Pacify-gcc-Woverflow-more-clearly.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="0001-Pacify-gcc-Woverflow-more-clearly.patch" >From 0afbde4e68c1161a54f9593ecb5b66fe42aa0de4 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Wed, 14 Jul 2021 17:10:06 -0500 Subject: [PATCH] Pacify gcc -Woverflow more clearly * src/alloc.c (mark_maybe_pointer): Make it clearer that ANDing with UINTPTR_MAX is intended. Omit a now-unnecessary cast. --- src/alloc.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/alloc.c b/src/alloc.c index ee3fd64a00..8edcd06c84 100644 --- a/src/alloc.c +++ b/src/alloc.c @@ -4764,7 +4764,9 @@ mark_maybe_pointer (void *p, bool symbol_only) from Emacs source code, it can occur in some cases. To fix this problem, the pdumper code should grok non-initial addresses, as the non-pdumper code does. */ - void *po = (void *) ((uintptr_t) p & (uintptr_t) VALMASK); + uintptr_t mask = VALMASK & UINTPTR_MAX; + uintptr_t masked_p = (uintptr_t) p & mask; + void *po = (void *) masked_p; char *cp = p; char *cpo = po; /* Don't use pdumper_object_p_precise here! It doesn't check the -- 2.25.1 --------------6132E8812C143D05C8BD6D80-- From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 15 02:14:24 2021 Received: (at 49261) by debbugs.gnu.org; 15 Jul 2021 06:14:24 +0000 Received: from localhost ([127.0.0.1]:46494 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m3udc-0004Yn-JW for submit@debbugs.gnu.org; Thu, 15 Jul 2021 02:14:24 -0400 Received: from eggs.gnu.org ([209.51.188.92]:55970) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m3udZ-0004YZ-PS for 49261@debbugs.gnu.org; Thu, 15 Jul 2021 02:14:22 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:38034) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m3udT-0000zj-OH; Thu, 15 Jul 2021 02:14:15 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2418 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m3udT-0007s0-Bt; Thu, 15 Jul 2021 02:14:15 -0400 Date: Thu, 15 Jul 2021 09:13:59 +0300 Message-Id: <83mtqo6r4o.fsf@gnu.org> From: Eli Zaretskii To: Paul Eggert In-Reply-To: <33801f54-3794-d98c-54c3-c67ce53ec6c0@cs.ucla.edu> (message from Paul Eggert on Wed, 14 Jul 2021 17:24:37 -0500) Subject: Re: bug#49261: Segfault during loadup References: <87o8bn7bie.fsf@gnus.org> <87zgv6vuon.fsf@gmx.de> <837di9lwbm.fsf@gnu.org> <87a6n5vuu4.fsf@gnus.org> <8735sqnmei.fsf@gnus.org> <87zguyf4ht.fsf@gmx.de> <87pmvum54p.fsf@gnus.org> <87v95mf2lj.fsf@gmx.de> <87pmvt3ob1.fsf@gnus.org> <83r1g9evoy.fsf@gnu.org> <83pmvtevgg.fsf@gnu.org> <87czrt3mj4.fsf@gnus.org> <878s2h3m1d.fsf@gnus.org> <874kd53lnl.fsf@gnus.org> <87zgux26ab.fsf@gnus.org> <87pmvt25uq.fsf@gnus.org> <87lf6h2294.fsf@gnus.org> <87h7h51x9y.fsf_-_@gnus.org> <83bl79b17n.fsf@gnu.org> <835yxgc1pm.fsf@gnu.org> <83wnpvag6z.fsf@gnu.org> <5608bf0a-7211-73a9-690f-c869a1cb3c9d@cs.ucla.edu> <83o8b7a5ow.fsf@gnu.org> <83eec1843o.fsf@gnu.org> <33801f54-3794-d98c-54c3-c67ce53ec6c0@cs.ucla.edu> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49261 Cc: larsi@gnus.org, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: larsi@gnus.org, 49261@debbugs.gnu.org > From: Paul Eggert > Date: Wed, 14 Jul 2021 17:24:37 -0500 > > I originally wrote it as "uintptr_t mask = VALMASK;" because I would > rather avoid C casts when possible (they're too powerful and allow too > many bugs to go undetected). I dislike the workaround that I installed > because of (a) its unnecessary cast and (b) the lack of clarity that > it's intended that we want to discard any bits outside UINTPTR_MAX ((b) > was a problem with my original code too). > > To try to fix both (a) and (b) I installed the attached further patch. > It is a bit more verbose than what C requires, but the verbosity should > help explain that masking with UINTPTR_MAX is intended, and the > verbosity shouldn't hurt efficiency. Thanks, I think this new code is much cleaner and less mysterious. From debbugs-submit-bounces@debbugs.gnu.org Fri Jul 16 12:16:07 2021 Received: (at 49261) by debbugs.gnu.org; 16 Jul 2021 16:16:07 +0000 Received: from localhost ([127.0.0.1]:52225 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m4QVT-0003cj-2P for submit@debbugs.gnu.org; Fri, 16 Jul 2021 12:16:07 -0400 Received: from mout.gmx.net ([212.227.15.19]:56505) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m4QVP-0003c3-Sd for 49261@debbugs.gnu.org; Fri, 16 Jul 2021 12:16:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1626452157; bh=pScOSR0qzzuIrN7bwWUmk5Bs66LklS7ufwTqiHee2Y8=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=Q8JpI5bo0/VDyjAywJhXk4UbGn6dcA5Jdb6sN29fTI8Se8IwwEgsBuSXNNvHJDAga WUF8HxR+TcdaopY2xwsSLmuSne2xtG9r0tI5m954gpjLDhmEM8lCY3lCc02JuH2POY AnUTQPwwpNbyWz2iAofwB8zLJGZetpkE8Dv84OGY= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from gandalf.gmx.de ([79.140.112.249]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MnaoZ-1lN5Sb3ME1-00jbaa; Fri, 16 Jul 2021 18:15:56 +0200 From: Michael Albinus To: Lars Ingebrigtsen Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: <87pmvum54p.fsf@gnus.org> <87v95mf2lj.fsf@gmx.de> <87pmvt3ob1.fsf@gnus.org> <87fswpgacv.fsf@gmx.de> <87bl7dfikj.fsf@gmx.de> <8735sofuqj.fsf@gmx.de> <83sg0oc83l.fsf@gnu.org> <87v95jevrm.fsf@gmx.de> <83lf6fdav4.fsf@gnu.org> <87r1g7eoor.fsf@gmx.de> <87im1jphyy.fsf@gnus.org> <87im1fd4fr.fsf@gmx.de> <83sg0jaaud.fsf@gnu.org> <87a6mrd2di.fsf@gmx.de> <838s2ba18y.fsf@gnu.org> <87pmvnsadx.fsf@gnus.org> <837dhva0vi.fsf@gnu.org> <878s2arxa5.fsf@gnus.org> <87czrmayj5.fsf@gmx.de> <87k0luox0h.fsf@gnus.org> Date: Fri, 16 Jul 2021 18:15:55 +0200 In-Reply-To: <87k0luox0h.fsf@gnus.org> (Lars Ingebrigtsen's message of "Tue, 13 Jul 2021 21:05:02 +0200") Message-ID: <87eeby2q10.fsf@gmx.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:FN8xCmOkR9PCWYDiQcf6TiufyfosHSxZNeI8/HW7ev8deUBRNl0 GgP8I5rKi3Ai//Gq1yLSGTBORbay+tVgs/XeNYipxvlOIXinlAJ9c1L6LtmZgRP/xpVUFch 7bMg/JfaevJE1z1n2XDd7LHMptmZOKn9jPeY/ZezuiQW4m7X33MnMS7pP96vmro6k7F7h28 5o4MK1MrLwHcGewZwx2Yg== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:DNW+hgZa390=:WEP/OMnLPZtuvBjHPzKjeX Wx2GMZaWBeiIcblPP7IWtP5iuIocGfqUrQd+JR1Yn/w5ZYECpEN+wYjGk2g6eI4eqFLdUB6q5 QJXbopK1eruzKhosI6rx88uwPzwYZJp3hPpDh4b0f7WuTZ6Pu60O5OpHh9uYuwPNuADuvzuH+ 70t2OECiX+1K5OLuG7nqIwqh4p1do6U7PAsngKzvcKUj07QKr6sNrKGiSppETqi1/e0nZNeV2 gYy+NZOlJbq3m+rfdVPSrwRJDUOd+d7VgimV6BkiOTTglqfW0++++6OfAr34XKbuq+eI3yE9S ea07t2XSrsyWOe9hNTk0D9OKyyAAfrwSUm2Ku4exIx2n2pxAup4WkVQrLqI1KRYyo42vtPpit sErrk9Bt3dOccDs08x3zCq2O/tFSrHA2Lrs9bK+MX36b6xbufbcBoyFRlxk6t8HzG2/xI/q+H m3aRm9twtoYi3oaBnbRExY4yAWQEjVplG/0jNPXw8YRWeOg/jZBsX4WRjWhmA7dvvxdcOk+Oz 0NQksO7mgo3rGwoUf5NsiBrWAAtfa+q8vwa437oMja7oE/xGs1vul3cjC9YrFE4ozqGDc15LS 6Aa7/qHvZRkMqVqKgmnTQjsWivlEIlA0Wy+L5FEPFuVWcKMp6UWD6voSlknxJdYhKPGPt37H+ OmDFJAa5LIsQv9809nb9+kIEHAfS5LIFf2Knuo6T+IGa0kI48TW0LIoLxZShhngpBybm3eDX8 4lbcknCi+kLklZy6ccUa01vfJB6I+uM+Szo+VtPk1RfK/TzY5LVGdMD0869eDBCCDNSxC34o6 kJ0KLTrF/qyXfzwINin25GPBIiQxXqP1ac2LD0OOjRfu/u7NAfYE8pFMzCHxW+oFVynznkn8z YEVYFELvcNZCkMYwQ7PH25fvvvDzydgCjE4fqvgPJLc8F3RroMgMMIajPa9vVZ2EJ+8bLhJgd QrZoLvybUe9lbdhyJcrGIxmFZReVZ6tOQomcqlv0yUtjqWSqA7i54Tl6VW710a7mv9cfXo9NY U1HWjKCdpf1yxMoWyTCLewJBbQibdI8coOg4mVwmQ42XmrbefXt7v32gB4qSii1gN3gbdLpyN JebQvBnJZxc3mtkF4CYbjQ5J0B/Oe60Bu3X7B4K3+JlxpE6efb1mEFZUg== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 49261 Cc: Eli Zaretskii , ncaprisunfan@gmail.com, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Lars Ingebrigtsen writes: Hi Lars, >> Well, there is auto-save-mode, which works over the current buffer. Maybe >> we could use something similar for file locks? > > Yeah, I think that's a good idea (but in addition to disabling based on > file name regexps). I've pushed this to master. Best regards, Michael. From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 17 10:06:15 2021 Received: (at 49261) by debbugs.gnu.org; 17 Jul 2021 14:06:15 +0000 Received: from localhost ([127.0.0.1]:54404 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m4kxL-0001ij-5c for submit@debbugs.gnu.org; Sat, 17 Jul 2021 10:06:15 -0400 Received: from quimby.gnus.org ([95.216.78.240]:51726) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m4kxJ-0001iR-3X for 49261@debbugs.gnu.org; Sat, 17 Jul 2021 10:06:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=gueM9Y8HOHNdHJ9TFn5N0RUhxTvsCYBeT1Skl2FngJg=; b=sbhWfP1Jf+yYk5QbiN1lh4AyBc ihNy3mLU+ysmunx9X+eX81+dTTa8BGgW470B3XzxmLvlgpNNKcQqycjBdIv7tzDCNq6AKLKBLdRU3 ilNGbIlG1q3Nj9ZuCm0fWOJMa3G6ISRNUmQTmKyxYtYAYswixlBK0jj0jzvtO3fvpPFs=; Received: from cm-84.212.220.105.getinternet.no ([84.212.220.105] helo=elva) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m4kxA-0007oG-RC; Sat, 17 Jul 2021 16:06:07 +0200 From: Lars Ingebrigtsen To: Michael Albinus Subject: Re: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains References: <87v95mf2lj.fsf@gmx.de> <87pmvt3ob1.fsf@gnus.org> <87fswpgacv.fsf@gmx.de> <87bl7dfikj.fsf@gmx.de> <8735sofuqj.fsf@gmx.de> <83sg0oc83l.fsf@gnu.org> <87v95jevrm.fsf@gmx.de> <83lf6fdav4.fsf@gnu.org> <87r1g7eoor.fsf@gmx.de> <87im1jphyy.fsf@gnus.org> <87im1fd4fr.fsf@gmx.de> <83sg0jaaud.fsf@gnu.org> <87a6mrd2di.fsf@gmx.de> <838s2ba18y.fsf@gnu.org> <87pmvnsadx.fsf@gnus.org> <837dhva0vi.fsf@gnu.org> <878s2arxa5.fsf@gnus.org> <87czrmayj5.fsf@gmx.de> <87k0luox0h.fsf@gnus.org> <87eeby2q10.fsf@gmx.de> X-Now-Playing: SOPHIE's _OIL OF EVERY PEARL'S UN-INSIDES_: "Whole New World-Pretend World" Date: Sat, 17 Jul 2021 16:06:04 +0200 In-Reply-To: <87eeby2q10.fsf@gmx.de> (Michael Albinus's message of "Fri, 16 Jul 2021 18:15:55 +0200") Message-ID: <87wnpp592r.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Michael Albinus writes: > I've pushed this to master. Great! I think we've covered this bug report, then, and I'm closing it. Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49261 Cc: Eli Zaretskii , ncaprisunfan@gmail.com, 49261@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Michael Albinus writes: > I've pushed this to master. Great! I think we've covered this bug report, then, and I'm closing it. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 17 10:06:24 2021 Received: (at control) by debbugs.gnu.org; 17 Jul 2021 14:06:24 +0000 Received: from localhost ([127.0.0.1]:54407 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m4kxU-0001j6-Bk for submit@debbugs.gnu.org; Sat, 17 Jul 2021 10:06:24 -0400 Received: from quimby.gnus.org ([95.216.78.240]:51744) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m4kxS-0001ir-3u for control@debbugs.gnu.org; Sat, 17 Jul 2021 10:06:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Subject:From:To:Message-Id:Date:Sender:Reply-To:Cc: MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=6E2qYa9qkauYh7TsmaYFSRCisQ8iWfHB6Ii+nNU0smo=; b=KAFYZNBVa54ST35x1hdv2GHNgl gT183WMEhqcI7YE2EmYeEmyTfKPqnWxSkJMhJdnAR/jmHG85Nz8GDqHFFNUhZqR2fQHjuKYZeJvHD z34luOAeGT1Sk2jMATgpzqHsBndNQCyry2NUxK5bfsYmdhQ6o85+tkMH5HmyH4rNr0Gk=; Received: from cm-84.212.220.105.getinternet.no ([84.212.220.105] helo=elva) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m4kxK-0007oX-J7 for control@debbugs.gnu.org; Sat, 17 Jul 2021 16:06:16 +0200 Date: Sat, 17 Jul 2021 16:06:14 +0200 Message-Id: <87v959592h.fsf@gnus.org> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #49261 X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: close 49261 28.1 quit Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) close 49261 28.1 quit From unknown Mon Jun 16 23:47:11 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sun, 15 Aug 2021 11:24:05 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator