* bug#7221: timestamp in cvs-quickdir on Win32 system
@ 2010-10-15 11:14 Rolf Unger
2020-08-20 14:07 ` Lars Ingebrigtsen
0 siblings, 1 reply; 8+ messages in thread
From: Rolf Unger @ 2010-10-15 11:14 UTC (permalink / raw)
To: 7221
I realized that the cvs-quickdir command always returned MODIFIED for the
state of the files under CVS when running this on MS Win2k. At some time
I was using cvs-quickdir on a Linux box and was suprised that the results
were correct on Linux.
I inspected this a bit closer and figured out that the problem is in the
pcvs-info.el:cvs-fileinfo-from-entries function. Comparing the file
attributes time with the timestamp from the CVS/Entries file seems to
compare two different formats.
(setq timestamp (format-time-string "%c" mtime 'utc))
seems to be the problem. I experimented a bit with the format-time-string
and found out that the "%c" format specifier is not robust on Win32
(insert (concat "\n" (format-time-string "%c" (current-time) t)))
gives me after:
(setq system-time-locale nil): 15.10.2010 10:45:44
(setq system-time-locale "C"): 10/15/10 10:44:52
The first one picks up my locale settings from the OS and is the common
german format. But only the second one is relevant for cvs-quickdir.
If I use a detailed format string "%a %b %e %H:%M:%S %Y" I get the date
string in a format that matches what is used in CVS/Entries.
I tested this on both systems Win32 (with GNU Emacs 22.3 and 23.2) and
Linux (only 22.2) ... can't say anything about Solaris, though.
For pcvs-info.el from GNU Emacs 23.2 I have
;; arch-tag: d85dde07-bdc2-400a-882f-92f398c7b0ba
at the end of the file. Can't find a cvs-version variable, though?
Rolf
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#7221: timestamp in cvs-quickdir on Win32 system
2010-10-15 11:14 bug#7221: timestamp in cvs-quickdir on Win32 system Rolf Unger
@ 2020-08-20 14:07 ` Lars Ingebrigtsen
2020-10-02 9:42 ` Stefan Kangas
0 siblings, 1 reply; 8+ messages in thread
From: Lars Ingebrigtsen @ 2020-08-20 14:07 UTC (permalink / raw)
To: Rolf Unger; +Cc: 7221
(I'm going through old bug reports that unfortunately got no attention
at the time.)
Rolf Unger <rz.unger@web.de> writes:
> I realized that the cvs-quickdir command always returned MODIFIED for the
> state of the files under CVS when running this on MS Win2k. At some time
> I was using cvs-quickdir on a Linux box and was suprised that the results
> were correct on Linux.
>
> I inspected this a bit closer and figured out that the problem is in the
> pcvs-info.el:cvs-fileinfo-from-entries function. Comparing the file
> attributes time with the timestamp from the CVS/Entries file seems to
> compare two different formats.
>
> (setq timestamp (format-time-string "%c" mtime 'utc))
>
> seems to be the problem. I experimented a bit with the format-time-string
> and found out that the "%c" format specifier is not robust on Win32
>
> (insert (concat "\n" (format-time-string "%c" (current-time) t)))
>
> gives me after:
>
> (setq system-time-locale nil): 15.10.2010 10:45:44
>
> (setq system-time-locale "C"): 10/15/10 10:44:52
>
> The first one picks up my locale settings from the OS and is the common
> german format. But only the second one is relevant for cvs-quickdir.
>
> If I use a detailed format string "%a %b %e %H:%M:%S %Y" I get the date
> string in a format that matches what is used in CVS/Entries.
So the suggestion is to do this:
diff --git a/lisp/vc/pcvs-info.el b/lisp/vc/pcvs-info.el
index 9f8a168a0a..5a607e337b 100644
--- a/lisp/vc/pcvs-info.el
+++ b/lisp/vc/pcvs-info.el
@@ -454,7 +454,8 @@ cvs-fileinfo-from-entries
((let ((mtime (file-attribute-modification-time
(file-attributes (concat dir f))))
(system-time-locale "C"))
- (setq timestamp (format-time-string "%c" mtime t))
+ (setq timestamp (format-time-string "%a %b %e %H:%M:%S %Y"
+ mtime t))
;; Solaris sometimes uses "Wed Sep 05", not "Wed Sep 5".
;; See "grep '[^a-z_]ctime' cvs/src/*.c" for reference.
(if (= (aref timestamp 8) ?0)
But I guess the assumption here is that cvs will output the date in the
locale's date format, which is why we're using %c here. If your cvs
outputs in ISO8601 no matter what your locale is, then you'll get a
mismatch here.
So I'm kinda leaning towards this not being a bug, but a cvs version
that doesn't behave correctly...
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply related [flat|nested] 8+ messages in thread
* bug#7221: timestamp in cvs-quickdir on Win32 system
2020-08-20 14:07 ` Lars Ingebrigtsen
@ 2020-10-02 9:42 ` Stefan Kangas
2020-10-02 10:30 ` Eli Zaretskii
0 siblings, 1 reply; 8+ messages in thread
From: Stefan Kangas @ 2020-10-02 9:42 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 7221, Rolf Unger
Lars Ingebrigtsen <larsi@gnus.org> writes:
> So I'm kinda leaning towards this not being a bug, but a cvs version
> that doesn't behave correctly...
Sounds reasonable.
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#7221: timestamp in cvs-quickdir on Win32 system
2020-10-02 9:42 ` Stefan Kangas
@ 2020-10-02 10:30 ` Eli Zaretskii
2021-08-26 18:07 ` Lars Ingebrigtsen
0 siblings, 1 reply; 8+ messages in thread
From: Eli Zaretskii @ 2020-10-02 10:30 UTC (permalink / raw)
To: Stefan Kangas; +Cc: larsi, rz.unger, 7221
> From: Stefan Kangas <stefan@marxist.se>
> Date: Fri, 2 Oct 2020 09:42:26 +0000
> Cc: 7221@debbugs.gnu.org, Rolf Unger <rz.unger@web.de>
>
> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
> > So I'm kinda leaning towards this not being a bug, but a cvs version
> > that doesn't behave correctly...
>
> Sounds reasonable.
I don't think I agree. My reading of the relevant CVS code is that
CVS uses either 'asctime' or 'ctime' to produce the time string for
"Entries", and 'asctime'/'ctime' always produce the standard format of
the time, not the locale-preferred format produced by %c. See
vers_ts.c:time_stamp in the CVS sources.
FWIW, I see the same problem on my MS-Windows machine.
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#7221: timestamp in cvs-quickdir on Win32 system
2020-10-02 10:30 ` Eli Zaretskii
@ 2021-08-26 18:07 ` Lars Ingebrigtsen
2021-08-26 23:06 ` Rolf Unger
0 siblings, 1 reply; 8+ messages in thread
From: Lars Ingebrigtsen @ 2021-08-26 18:07 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 7221, rz.unger, Stefan Kangas
Eli Zaretskii <eliz@gnu.org> writes:
> I don't think I agree. My reading of the relevant CVS code is that
> CVS uses either 'asctime' or 'ctime' to produce the time string for
> "Entries", and 'asctime'/'ctime' always produce the standard format of
> the time, not the locale-preferred format produced by %c. See
> vers_ts.c:time_stamp in the CVS sources.
>
> FWIW, I see the same problem on my MS-Windows machine.
Does the proposed patch fix the issue, then? It removes the "%c" and
uses a more standard date format:
diff --git a/lisp/vc/pcvs-info.el b/lisp/vc/pcvs-info.el
index 9f8a168a0a..5a607e337b 100644
--- a/lisp/vc/pcvs-info.el
+++ b/lisp/vc/pcvs-info.el
@@ -454,7 +454,8 @@ cvs-fileinfo-from-entries
((let ((mtime (file-attribute-modification-time
(file-attributes (concat dir f))))
(system-time-locale "C"))
- (setq timestamp (format-time-string "%c" mtime t))
+ (setq timestamp (format-time-string "%a %b %e %H:%M:%S %Y"
+ mtime t))
;; Solaris sometimes uses "Wed Sep 05", not "Wed Sep 5".
;; See "grep '[^a-z_]ctime' cvs/src/*.c" for reference.
(if (= (aref timestamp 8) ?0)
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply related [flat|nested] 8+ messages in thread
* bug#7221: timestamp in cvs-quickdir on Win32 system
2021-08-26 18:07 ` Lars Ingebrigtsen
@ 2021-08-26 23:06 ` Rolf Unger
2021-08-27 12:20 ` Eli Zaretskii
0 siblings, 1 reply; 8+ messages in thread
From: Rolf Unger @ 2021-08-26 23:06 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: Stefan Kangas, 7221
Hi Lars,
I gave it a go with your suggested patch, and it still marks some files as
modified that are not modified.
Maybe I should give some details to my constellation:
My working directory is on a win32 machine, but the repository is on a
Linux box and I use the pserver protocol to access the repository.
My Project resides all in one directory, it consists of two .c files, a
header file and some Windows resource script files .rc. Furthermore I have
a Makefile for MinGW gnu make and one .mak file for nmake.
The Makefile, the .mak and the .rc resource files are marked as modified
if I open the project directory with `csv-quickdir`. The .c files and the
header file are not shown (the rule for files that are up-to-date)
If I use cvs-status on this same directory all files are shown as
up-to-date (which is the same what I get if I run `cvs status` in a shell.
The interesting part is: If I open a file (the Makefile for example) with
`o` in the other window the *cvs* buffer will immediately show the file
that have just opened as `modidied`. But I haven't done any changes in
that opened file, only the active cursor is in that buffer.
If I hit `g` to refresh the *cvs* buffer with (cvs -f -n update -d -P)
the opened file that is said to be modified will transition to Up-To-Date
again.
I thought it could be related with the character encoding because the .rc
files are UTF-8 encded and theser .rc files are shown as modified.
But if it is a encoding issue it should not happen for the Makefile,
because this file as ASCII clean file.
If I execute `vc-dir` on my project only some unregistered files are
shown, because vc doesn't show files that are not modified.
So `vc` does show the status of the files correctly.
All this strange behaviour let's me guess, that the problem is not within
the elisp code and maybe wrong assumptions on the date format of cvs'
timestamp of the revision.
Rolf
On Thu, 26 Aug 2021 after 20 h, Lars Ingebrigtsen wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > I don't think I agree. My reading of the relevant CVS code is that
> > CVS uses either 'asctime' or 'ctime' to produce the time string for
> > "Entries", and 'asctime'/'ctime' always produce the standard format of
> > the time, not the locale-preferred format produced by %c. See
> > vers_ts.c:time_stamp in the CVS sources.
> >
> > FWIW, I see the same problem on my MS-Windows machine.
>
> Does the proposed patch fix the issue, then? It removes the "%c" and
> uses a more standard date format:
>
> diff --git a/lisp/vc/pcvs-info.el b/lisp/vc/pcvs-info.el
> index 9f8a168a0a..5a607e337b 100644
> --- a/lisp/vc/pcvs-info.el
> +++ b/lisp/vc/pcvs-info.el
> @@ -454,7 +454,8 @@ cvs-fileinfo-from-entries
> ((let ((mtime (file-attribute-modification-time
> (file-attributes (concat dir f))))
> (system-time-locale "C"))
> - (setq timestamp (format-time-string "%c" mtime t))
> + (setq timestamp (format-time-string "%a %b %e %H:%M:%S %Y"
> + mtime t))
> ;; Solaris sometimes uses "Wed Sep 05", not "Wed Sep 5".
> ;; See "grep '[^a-z_]ctime' cvs/src/*.c" for reference.
> (if (= (aref timestamp 8) ?0)
>
>
>
> --
> (domestic pets only, the antidote for overdose, milk.)
> bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#7221: timestamp in cvs-quickdir on Win32 system
2021-08-26 23:06 ` Rolf Unger
@ 2021-08-27 12:20 ` Eli Zaretskii
2021-09-25 2:38 ` Lars Ingebrigtsen
0 siblings, 1 reply; 8+ messages in thread
From: Eli Zaretskii @ 2021-08-27 12:20 UTC (permalink / raw)
To: Rolf Unger; +Cc: larsi, stefan, 7221
> Date: Fri, 27 Aug 2021 01:06:56 +0200
> From: Rolf Unger <rz.unger@web.de>
> Cc: Eli Zaretskii <eliz@gnu.org>, Stefan Kangas <stefan@marxist.se>,
> 7221@debbugs.gnu.org
>
> I gave it a go with your suggested patch, and it still marks some files as
> modified that are not modified.
>
> Maybe I should give some details to my constellation:
> My working directory is on a win32 machine, but the repository is on a
> Linux box and I use the pserver protocol to access the repository.
> My Project resides all in one directory, it consists of two .c files, a
> header file and some Windows resource script files .rc. Furthermore I have
> a Makefile for MinGW gnu make and one .mak file for nmake.
>
> The Makefile, the .mak and the .rc resource files are marked as modified
> if I open the project directory with `csv-quickdir`. The .c files and the
> header file are not shown (the rule for files that are up-to-date)
> If I use cvs-status on this same directory all files are shown as
> up-to-date (which is the same what I get if I run `cvs status` in a shell.
>
> The interesting part is: If I open a file (the Makefile for example) with
> `o` in the other window the *cvs* buffer will immediately show the file
> that have just opened as `modidied`. But I haven't done any changes in
> that opened file, only the active cursor is in that buffer.
> If I hit `g` to refresh the *cvs* buffer with (cvs -f -n update -d -P)
> the opened file that is said to be modified will transition to Up-To-Date
> again.
> I thought it could be related with the character encoding because the .rc
> files are UTF-8 encded and theser .rc files are shown as modified.
> But if it is a encoding issue it should not happen for the Makefile,
> because this file as ASCII clean file.
>
> If I execute `vc-dir` on my project only some unregistered files are
> shown, because vc doesn't show files that are not modified.
> So `vc` does show the status of the files correctly.
>
> All this strange behaviour let's me guess, that the problem is not within
> the elisp code and maybe wrong assumptions on the date format of cvs'
> timestamp of the revision.
Your setup is sufficiently complicated, even exotic, to be hard to
reproduce and to be able to produce problems due to quite a few
factors. Can you step through the Lisp code relevant to the issue,
and see what causes Emacs to decide the files are modified? If it's
the problem with time stamp mismatch, can you show an example of
timestamps that should match, but don't?
Thanks.
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#7221: timestamp in cvs-quickdir on Win32 system
2021-08-27 12:20 ` Eli Zaretskii
@ 2021-09-25 2:38 ` Lars Ingebrigtsen
0 siblings, 0 replies; 8+ messages in thread
From: Lars Ingebrigtsen @ 2021-09-25 2:38 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 7221, Rolf Unger, stefan
Eli Zaretskii <eliz@gnu.org> writes:
> Your setup is sufficiently complicated, even exotic, to be hard to
> reproduce and to be able to produce problems due to quite a few
> factors. Can you step through the Lisp code relevant to the issue,
> and see what causes Emacs to decide the files are modified? If it's
> the problem with time stamp mismatch, can you show an example of
> timestamps that should match, but don't?
More information was requested, but no response was given within a
month, so I'm closing this bug report. If progress can be made,
please respond to this email and we'll reopen the bug report.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2021-09-25 2:38 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-10-15 11:14 bug#7221: timestamp in cvs-quickdir on Win32 system Rolf Unger
2020-08-20 14:07 ` Lars Ingebrigtsen
2020-10-02 9:42 ` Stefan Kangas
2020-10-02 10:30 ` Eli Zaretskii
2021-08-26 18:07 ` Lars Ingebrigtsen
2021-08-26 23:06 ` Rolf Unger
2021-08-27 12:20 ` Eli Zaretskii
2021-09-25 2:38 ` Lars Ingebrigtsen
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).