From: Skip M. <sk...@po...> - 2002-01-18 22:39:02
|
Here's the result of an experiment with the dreaded "file changed" error. I have a quick question which will serve as the executive summary: * well well synchronized are the clocks on your local and remote machines? My setup is local machine: XEmacs 21.4.4, Mandrake 8.1, Perl 5.6.1 remote machine: Mandrake 8.1, Perl 5.6.1 There are 11 hops over the net beween the local and remote machines. My immediate link to the net is over a cable modem (fast downloads, uploads about 10x slower). Thinking this would be easy to track down, I initially just tried some "cvs up -D" runs, with makes to see how things stood. I was originally having all sorts of problems with versions dating from around 2002-01-02. I went off and did some other stuff for awhile, and tried again. This time I was having some trouble with even earlier versions (sometimes the 2001-12-31). Then I double-checked my NTP setup. Turns out I had deleted then reinstalled ntp several days ago. When I deleted it, rpm pushed /etc/ntp.conf out of the way (presumably to keep it from getting stomped on later on), so after I reinstalled it, even though I was running the ntp daemon, it was complaining (in /var/log/ messages) that it couldn't find /etc/ntp.conf. God only knows what it was syncing with... To make a long story short, I pushed /etc/ntp.conf back into place, sync'd the local and remote clocks (off by about 0.13 seconds), and restarted ntpd on the local machine. (The remote host is my ntp server.) Then I started playing again, but with a little more rigor. I added this macro definition to my ~/.xemacs/init.el file: (defalias 'ff (read-kbd-macro "C-x C-f /[manatee.mojam.com]tmp/trash RET SPC <backspace> C-x C-s SPC")) (define-key global-map [(shift f7)] 'ff) Then I went through the following progression: 1. Run "cvs up -D somedate" (or "cvs up -A" for the last trial). 2. Run "make EMACS=xemacs". 3. Start XEmacs & execute the above macro three times, deleting the file's buffer between each macro invocation. Exit XEmacs. 4. Repeat step 3. Here's what I came up with. In the table below, a dash means it was able to modify the file after saving it without the annoying prompt. An 'x' represents a failure. A vertical bar indicates stop/start of emacs. The dates are the value given to cvs up. 2001-12-25 ---|--- 2001-12-27 --x|--- 2001-12-31 ---|--- 2002-01-02 --x|--- 2002-01-04 ---|--- current CVS ---|--- Before I corrected my ntp problems, I was essentially unable to modify a file without getting the dreaded "file changed" message after saving it using anything later than the December 31st version. The fact that I still occasionally have trouble suggests to me that the modtime information is being compared with too fine a granularity. Looking at the perlfunc page for the stat and lstat functions it seems they should only be recording modtimes with a granularity of seconds though. I'm still mystified, though I am also in better shape tramp-wise than earlier today. I don't know if this will help you, Kai. The moral of the story for me is that I need to keep my clocks very well synchronized. -- Skip Montanaro (sk...@po... - http://www.mojam.com/) |
From: Kai.Grossjohann@CS.Uni-Dortmund.DE (K. ) - 2002-01-19 11:42:35
|
"Skip Montanaro" <sk...@po...> writes: > Before I corrected my ntp problems, I was essentially unable to modify a > file without getting the dreaded "file changed" message after saving it > using anything later than the December 31st version. The fact that I still > occasionally have trouble suggests to me that the modtime information is > being compared with too fine a granularity. Looking at the perlfunc page > for the stat and lstat functions it seems they should only be recording > modtimes with a granularity of seconds though. Well, Emacs itself allows a one second difference in the modtime, see the function verify-visited-file-modtime in src/fileio.c. Hm. I have now added something to clear-visited-file-modtime, but that should be important only for those who do not have Perl on the remote host. Please test. Skip, what is the value of the variable tramp-buffer-file-attributes in your buffers visiting Tramp files? I guess it should be nil, since you have Perl on the remote end. kai -- Simplification good! Oversimplification bad! (Larry Wall) |
From: Kai.Grossjohann@CS.Uni-Dortmund.DE (K. ) - 2002-01-19 12:16:02
|
Thank you for your hints. I've now found out that Emacs indeed compares the modtime of the file with the time on the local host. But I don't know when does that happen. Hm. In particular, where does the current time value come from? Does anyone have an idea? kai -- Simplification good! Oversimplification bad! (Larry Wall) |
From: Skip M. <sk...@po...> - 2002-01-19 14:33:01
|
I take back my suggestion that perhaps XEmacs's itimer-time-difference is broken. I started to file a bug report then realized that since it's a function internal to the itimer package the XEmacs authors are able to make any assumptions about the interface they want. As far as I could tell from a quick scan of itimer.el it's always called there with three-element lists. So, I think a change has to be made in tramp. Skip |
From: Skip M. <sk...@po...> - 2002-01-19 12:59:49
|
Kai> I have now added something to clear-visited-file-modtime, but that Kai> should be important only for those who do not have Perl on the Kai> remote host. Please test. This fails for me. Here's the backtrace: Signaling: (wrong-type-argument number-char-or-marker-p nil) signal(wrong-type-argument (number-char-or-marker-p nil)) byte-code("..." [buf data kill-buffer signal] 3) find-file-noselect("/[manatee.mojam.com]tmp/trash") find-file("/[manatee.mojam.com]tmp/trash" nil) call-interactively(find-file) I did a little digging. The problem is in itimer-time-difference. Here's the version I have in XEmacs: (defun itimer-time-difference (t1 t2) (let (usecs secs 65536-secs carry) (setq usecs (- (nth 2 t1) (nth 2 t2))) (if (< usecs 0) (setq carry 1 usecs (+ usecs 1000000)) (setq carry 0)) (setq secs (- (nth 1 t1) (nth 1 t2) carry)) (if (< secs 0) (setq carry 1 secs (+ secs 65536)) (setq carry 0)) (setq 65536-secs (- (nth 0 t1) (nth 0 t2) carry)) (+ (* 65536-secs 65536.0) secs (/ usecs 1000000.0)))) Your t1 and t2 are two-element lists, so (nth 2 t1) and (nth 2 t2) return nil, which causes the - function to barf. It would appear that either you should pad t1 and t2 with a 0 or compute the time difference in some other fashion. In the long run it looks like itimer-time-difference should change so that usecs is computed properly in the face of short times: (setq usecs (- (or (nth 2 t1) 0) (or (nth 2 t2) 0))) If I change the code in tramp-time-diff that calls itimer-time-difference to (floor (funcall (symbol-function 'itimer-time-difference) (append t1 '(0)) (append t2 '(0))))) the error disappears. Kai> what is the value of the variable tramp-buffer-file-attributes in Kai> your buffers visiting Tramp files? I guess it should be nil, since Kai> you have Perl on the remote end. Yup, it is. Skip |
From: Kai.Grossjohann@CS.Uni-Dortmund.DE (K. ) - 2002-01-19 19:23:23
|
"Skip Montanaro" <sk...@po...> writes: > If I change the code in tramp-time-diff that calls itimer-time-difference to > > (floor (funcall (symbol-function 'itimer-time-difference) > (append t1 '(0)) > (append t2 '(0))))) > > the error disappears. I made it check for the length of the list, first. I hope the new version works. kai -- Simplification good! Oversimplification bad! (Larry Wall) |
From: Kai.Grossjohann@CS.Uni-Dortmund.DE (K. ) - 2002-01-20 08:31:31
|
Thanks a lot, Skip. The key information was that the error happens when the time between local and remote host is off. It took quite a bit of searching, but I think I found the problem now. Has the bug been fixed? Please test. kai -- Simplification good! Oversimplification bad! (Larry Wall) |
From: <mon...@tt...> - 2002-01-22 09:03:45
|
Kai> The key information was that the error happens when the time Kai> between local and remote host is off. It took quite a bit of Kai> searching, but I think I found the problem now. Kai> Has the bug been fixed? Please test. Seems to be working. Skip |