From: Max Nikulin <manikulin@gmail.com>
To: Paul Eggert <eggert@cs.ucla.edu>, Bastien <bzg@gnu.org>
Cc: emacs-orgmode <emacs-orgmode@gnu.org>, emacs-devel@gnu.org
Subject: [PATCH] org-macs.el: Do not compare wall time and file modification time
Date: Fri, 6 May 2022 23:56:08 +0700 [thread overview]
Message-ID: <c4e40362-86c5-2610-bfa1-bb2358ce1053@gmail.com> (raw)
In-Reply-To: <439411c0-7dae-9dfd-373a-c3779469003f@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2013 bytes --]
Mark Barton to emacs-orgmode, emacs-devel. master 4a1f69ebca 2/2: Use
(TICKS . HZ) for current-time etc. Tue, 26 Apr 2022 23:37:50 -0700.
https://list.orgmode.org/BF5B9308-3FEF-4DC6-98C9-BFF36F19D36C@gmail.com
>
> The change also breaks org-file-newer-than-p function that triggered the
> debugger while loading my init that uses org babel.
I think, it should be fixed in the bugfix Org branch. The attached
patch is a compromise to some degree, but I do not see a robust solution.
I do not consider current behavior as reliable, however if you would
prefer to keep it, the following patch may be used instead:
Paul Eggert to emacs-orgmode. Re: master 4a1f69ebca 2/2: Use (TICKS .
HZ) for current-time etc. Wed, 27 Apr 2022 00:39:01 -0700.
https://list.orgmode.org/f200c9ab-d1d4-d5a8-24cf-4e1082528fe7@cs.ucla.edu
The changes are not covered by unit tests at least when most babel
languages are disabled.
On 30/04/2022 17:56, Max Nikulin wrote:
>
> (and mtime (not (and time (time-less-p mtime time))))
Treating equality as "newer" would break `org-compile-file', so I
changed the condition. Previously it was not a case since file
modification time is usually in the past in comparison to current time.
> On 30/04/2022 01:10, Paul Eggert wrote:
>> + (when-let ((mtime (file-attribute-modification-time (file-attributes file))))
>> + (time-less-p time mtime)))
> `file-attribute-modification-time' makes code clearer, but it causes
> some complications. Formally compatibility with Emacs-25 (e.g.
> ubuntu-18.04 LTS bionic) is not required for the "main" branch. Emacs
> sources have the "bugfix" Org branch of the stable release though. The
> latter still supports Emacs-25, so either the Emacs source tree and the
> Org bugfix branch will diverge at this point or it is safer to avoid
> `file-attribute-modification-time' till the next major Org release.
> Maybe Org maintainers and developers will correct me.
I have found `file-attribute-modification-time' in org-compat.el.
[-- Attachment #2: 0001-org-macs.el-Do-not-compare-wall-time-and-file-modifi.patch --]
[-- Type: text/x-patch, Size: 3649 bytes --]
From d37b5bb295c69572d1615e7fb2c0bcce05cb2b58 Mon Sep 17 00:00:00 2001
From: Max Nikulin <manikulin@gmail.com>
Date: Fri, 6 May 2022 23:34:52 +0700
Subject: [PATCH] org-macs.el: Do not compare wall time and file modification
time
* lisp/org-macs.el (org-file-newer-than-p): Fix Emacs-29 problem with
changed representation of system clock timestamp. Recommend passing
file modification time and do not truncate its precision.
(org-compile-file): Store file modification time instead of system clock
for later comparison by `org-file-newer-than-p'.
It changes behavior of `org-babel-load-file' for the case of equal
modification time of source and tangled files that may happen on
filesystems with coarse timestamps, for example HFS+. The file will be
tangled again. Treating equal timestamps as up to date state would
break `org-compile-file' however. Anyway time comparison is not really
reliable since precision of filesystem timestamps is unknown and it
differs from system clock precision.
Reported by Mark Barton <mbarton98@gmail.com>
https://list.orgmode.org/BF5B9308-3FEF-4DC6-98C9-BFF36F19D36C@gmail.com
During discussion of the issue Paul Eggert <eggert@cs.ucla.edu>
suggested over variants of the changes in the same thread.
---
lisp/org-macs.el | 32 +++++++++++++++++++++-----------
1 file changed, 21 insertions(+), 11 deletions(-)
diff --git a/lisp/org-macs.el b/lisp/org-macs.el
index b10725bd5..556bf658d 100644
--- a/lisp/org-macs.el
+++ b/lisp/org-macs.el
@@ -256,16 +256,26 @@ ignored in this case."
;;; File
(defun org-file-newer-than-p (file time)
- "Non-nil if FILE is newer than TIME.
-FILE is a filename, as a string, TIME is a list of integers, as
-returned by, e.g., `current-time'."
- (and (file-exists-p file)
- ;; Only compare times up to whole seconds as some file-systems
- ;; (e.g. HFS+) do not retain any finer granularity. As
- ;; a consequence, make sure we return non-nil when the two
- ;; times are equal.
- (not (time-less-p (cl-subseq (nth 5 (file-attributes file)) 0 2)
- (cl-subseq time 0 2)))))
+ "Non-nil if FILE modification time is greater than TIME.
+TIME should be obtained earlier for the same FILE name using
+
+ (file-attribute-modification-time (file-attributes file))
+
+If TIME is nil (file did not exist) then any existing FILE
+is considered as a newer one. Some file systems have coarse
+timestamp resolution, for example 1 second on HFS+ or 2 seconds on FAT,
+so nil may be returned when file is updated twice within a short period
+of time. File timestamp and system clock `current-time' may have
+different resolution, so attempts to compare them may give unexpected
+results.
+
+Attempt to check whether a derived file has been updated in
+response to modification of its source file may give unreliable
+result. Equal timestamps in such case may mean that the derived
+file is up to date however this function returns nil assuming
+that the FILE is not modified."
+ (let ((mtime (file-attribute-modification-time (file-attributes file))))
+ (and mtime (or (not time) (time-less-p time mtime)))))
(defun org-compile-file (source process ext &optional err-msg log-buf spec)
"Compile a SOURCE file using PROCESS.
@@ -299,7 +309,7 @@ it for output."
(full-name (file-truename source))
(out-dir (or (file-name-directory source) "./"))
(output (expand-file-name (concat base-name "." ext) out-dir))
- (time (current-time))
+ (time (file-attribute-modification-time (file-attributes output)))
(err-msg (if (stringp err-msg) (concat ". " err-msg) "")))
(save-window-excursion
(pcase process
--
2.25.1
next prev parent reply other threads:[~2022-05-06 17:40 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-27 6:37 master 4a1f69ebca 2/2: Use (TICKS . HZ) for current-time etc Mark Barton
2022-04-27 7:20 ` Po Lu
2022-04-27 7:39 ` Paul Eggert
2022-04-27 16:55 ` Stefan Monnier
2022-04-28 22:27 ` Paul Eggert
2022-04-29 14:22 ` Max Nikulin
2022-04-29 18:10 ` Paul Eggert
2022-04-30 10:56 ` Max Nikulin
2022-05-06 16:56 ` Max Nikulin [this message]
2022-05-11 12:28 ` [PATCH] org-macs.el: Do not compare wall time and file modification time Max Nikulin
2022-05-11 16:24 ` Paul Eggert
2022-05-12 16:55 ` Max Nikulin
2022-05-12 22:52 ` Paul Eggert
2022-05-13 12:28 ` Max Nikulin
2022-05-13 18:00 ` Paul Eggert
2022-10-02 3:49 ` Ihor Radchenko
2022-10-09 8:18 ` [PATCH v2] " Max Nikulin
2022-10-21 3:27 ` Ihor Radchenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c4e40362-86c5-2610-bfa1-bb2358ce1053@gmail.com \
--to=manikulin@gmail.com \
--cc=bzg@gnu.org \
--cc=eggert@cs.ucla.edu \
--cc=emacs-devel@gnu.org \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).