From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: David Abrahams Newsgroups: gmane.emacs.devel Subject: Re: vc-mode permissions problems on NT Date: Wed, 10 Sep 2003 09:25:55 -0400 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <1063134029.541.18.camel@localhost> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1063200713 4715 80.91.224.253 (10 Sep 2003 13:31:53 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 10 Sep 2003 13:31:53 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Wed Sep 10 15:31:51 2003 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19x54Z-0007lj-00 for ; Wed, 10 Sep 2003 15:31:51 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 19x54x-0001VR-00 for ; Wed, 10 Sep 2003 15:32:15 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.22) id 19x50S-00073E-Ru for emacs-devel@quimby.gnus.org; Wed, 10 Sep 2003 09:27:36 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.22) id 19x4zx-0006sU-Or for emacs-devel@gnu.org; Wed, 10 Sep 2003 09:27:05 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.22) id 19x4zu-0006rK-85 for emacs-devel@gnu.org; Wed, 10 Sep 2003 09:27:03 -0400 Original-Received: from [207.172.4.61] (helo=smtp02.mrf.mail.rcn.net) by monty-python.gnu.org with esmtp (Exim 4.22) id 19x4zt-0006qg-4V; Wed, 10 Sep 2003 09:27:01 -0400 Original-Received: from 209-150-60-107.c3-0.smr-ubr2.sbo-smr.ma.cable.rcn.com ([209.150.60.107] helo=PENGUIN.boost-consulting.com) by smtp02.mrf.mail.rcn.net with esmtp (Exim 3.35 #4) id 19x4zo-0000Sz-00; Wed, 10 Sep 2003 09:26:56 -0400 Original-To: Andre Spiegel In-Reply-To: <1063134029.541.18.camel@localhost> (Andre Spiegel's message of "Tue, 09 Sep 2003 21:02:39 +0200") User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (windows-nt) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:16267 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:16267 Andre Spiegel writes: > On Tue, 2003-09-09 at 20:30, David Abrahams wrote: > >> Here's an example. CVS/Entries says: >> >> /convenience.cpp/1.2/Thu May 8 02:17:51 2003// >> >> and dired says: >> >> -r--r--r-- 1 dave root 1666 05-07 22:17 convenience.cpp >> >> What does that mean? > > This probably means that the timestamps agree (CVS always has it in UTC, > and your timezone appears to be 4 hours behind it). It's very strange > that VC would still consider the file to be "edited". Is it possible > for you to step through vc-cvs-state and vc-cvs-state-heuristic in the > debugger? In vc-cvs-state-heuristic, (file-attributes file) yields: (nil 1 5 5 (16223 9039) (15707 62723) (15938 41615) 199 "-r--r--r--" nil 17944 (48170 . 6007)) (equal checkout-time lastmod) yields: nil vc-cvs-state doesn't seem to be getting invoked. The backtrace leading here looks like: vc-cvs-state-heuristic("c:/boost/libs/python/todo.html") apply(vc-cvs-state-heuristic "c:/boost/libs/python/todo.html") vc-call-backend(CVS state-heuristic "c:/boost/libs/python/todo.html") vc-state("c:/boost/libs/python/todo.html") vc-default-mode-line-string(CVS "c:/boost/libs/python/todo.html") vc-cvs-mode-line-string("c:/boost/libs/python/todo.html") apply(vc-cvs-mode-line-string "c:/boost/libs/python/todo.html") vc-call-backend(CVS mode-line-string "c:/boost/libs/python/todo.html") vc-mode-line("c:/boost/libs/python/todo.html") vc-find-file-hook() run-hooks(find-file-hook) after-find-file(nil t) find-file-noselect-1(# "c:/boost/libs/python/todo.html" nil nil "c:/boost/libs/python/todo.html" (23121 (48170 . 6007))) find-file-noselect("c:/boost/libs/python/todo.html" nil nil t) ad-Orig-find-file("c:/boost/libs/python/todo.html" t) find-file("c:/boost/libs/python/todo.html" t) * call-interactively(find-file) recursive-edit() (lambda (buf) (view-buffer buf (lambda ... ...)) (recursive-edit) nil)(#) funcall((lambda (buf) (view-buffer buf (lambda ... ...)) (recursive-edit) nil) #) (if (funcall (aref def 0) elt) (setq actions (1+ actions)) (setq next (\` ...))) (cond ((eq def ...) (setq next ...)) ((eq def ...) (funcall actor elt) (setq actions ...)) ((eq def ...)) ((eq def ...) (funcall actor elt) (setq actions ... next ...)) ((eq def ...) (setq quit-flag t) (setq next ...)) ((eq def ...) (if ... ...) (while ... ...)) ((eq def ...) (with-output-to-temp-buffer "*Help*" ... ...) (setq next ...)) ((vectorp def) (if ... ... ...)) ((and ... ...) (setq delayed-switch-frame char) (setq next ...)) (t (message "Type %s for help." ...) (beep) (sit-for 1) (setq next ...))) (cond ((stringp prompt) (setq quit-flag nil) (if use-menus ... ... ...) (cond ... ... ... ... ... ... ... ... ... ...)) (prompt (funcall actor elt) (setq actions ...))) (while (funcall next) (setq prompt (funcall prompter elt)) (cond (... ... ... ...) (prompt ... ...))) (progn (if (stringp prompter) (setq prompter ...)) (while (funcall next) (setq prompt ...) (cond ... ...))) (unwind-protect (progn (if ... ...) (while ... ... ...)) (if delayed-switch-frame (setq unread-command-events ...))) (let* ((actions 0) user-keys mouse-event map prompt char elt tail def use-menus delayed-switch-frame (next ...)) (if (and ... use-dialog-box) (let ... ...) (setq user-keys ... map ...)) (unwind-protect (progn ... ...) (if delayed-switch-frame ...)) (let (...) (message "")) actions) map-y-or-n-p(#[(buffer) "\305!\205P > I'd have to know what these functions do when you open an > unmodified file. (They ought to realize that the timestamps agree, and > that the file is therefore not edited. I need to find out why this > isn't the case here.) Maybe the unexpected bytpass of vc-cvs-state is the problem? -- Dave Abrahams Boost Consulting www.boost-consulting.com