[racket-dev] overwrite

From: Robby Findler (robby at eecs.northwestern.edu)
Date: Tue Mar 8 17:15:10 EST 2011

On Tue, Mar 8, 2011 at 3:59 PM, John Clements <clements at brinckerhoff.org> wrote:
>
> On Fri, Mar 4, 2011 at 3:24 PM, Jakub Piotr Cłapa <jpc-ml at zenburn.net>
> wrote:
>>
>> On 27.02.11 23:33, Eli Barzilay wrote:
>>>
>>> Two hours ago, John Clements wrote:
>>>>
>>>> Add'l data point: I tried messing up the clock manually, by turning
>>>> off NTP, but I was unable to duplicate the bug this way.
>>>
>>> NTP is unlikely to be the problem, since the times are saved on the
>>> filesystem, independently of the system time (or clock).  And since
>>> Robby says that DrR compares only the time value regardless of being
>>> in the future, then there shouldn't be any problem with that.
>>
>> If NTP or clock drift was the reason then makefiles would not work and vim
>> would also complain a lot (an this is not the case, at least for me).
>>
>> I do not use network mounts or git and I too get this message almost all
>> the time on OS X. I will try to track it down using the patches posted in
>> this thread.
>
> I got my first hit using these patches.  I tried to save the file, and was
> informed that it had changed on disk since my last save from DrRacket, and
> did I want to overwrite it.  Here's what I got
>
> last-saved-file-time: 1299611826
> file-modified-time: 1299611832
>
> These times are both quite close to when I tried to save.  In retrospect, I
> should have added the output of (current-seconds) to the log output.  I
> don't recall a six-second delay while trying to save.

Hm. Yeah, I'm not seeing any clues in those numbers.

How about also putting the filename into the log (the one that's being
passed to file-or-directory-modify-seconds) and recording if it is the
after-load-file or the after-save-file method that's updating the
last-saved-file-time field?

Robby



Posted on the dev mailing list.