<filename> changed on disk; really edit the buffer?

<filename> changed on disk; really edit the buffer?

[Stephan Lukits]

Hello,
every few minutes I get this annoying question:
<filename> changed on disk; really edit the buffer?

I'm absolutely sure that no other program is using
this file.

Emacs version:
GNU Emacs 22.1.1 (i386-mingw-nt5.1.2600) of 2007-06-02 on RELEASE

on a Windows-XP Box.

best regards
Stephan Lukits

Re: <filename> changed on disk; really edit the buffer?

[Eli Zaretskii]

> From: Stephan Lukits <stephan.lukits@FernUni-Hagen.de>
> Date: Tue, 30 Oct 2007 16:26:39 +0100
> Cc: 
> 
> Hello,
> every few minutes I get this annoying question:
> <filename> changed on disk; really edit the buffer?

Thank you for your report.

What file is that?  Or does this happen with any file that Emacs
visits?

Re: <filename> changed on disk; really edit the buffer?

[Jason Rumney]

Stephan Lukits wrote:
> Hello,
> every few minutes I get this annoying question:
> <filename> changed on disk; really edit the buffer?
>
> I'm absolutely sure that no other program is using
> this file.
Do you have TZ set in your environment? The timing of this problem makes
me wonder if it might be related to the end of Summer Time in Europe. If
you set a TZ environment variable in Windows, it assumes US changeover
dates, and this year the US dates differ from Europe. Windows itself
will not be using the TZ variable, and will have the correct changeover
dates if your OS patches are up to date.

Re: <filename> changed on disk; really edit the buffer?

[martin rudalics]

> every few minutes I get this annoying question:
> <filename> changed on disk; really edit the buffer?

This is from `ask-user-about-supersession-threat'.

> I'm absolutely sure that no other program is using
> this file.

Does this happen since the DST change (saturday/sunday) or did it
happen before?

Does it go away when you touch the file in question, that is, set
its modification time to now.

Re: <filename> changed on disk; really edit the buffer?

[Stephan Lukits]

Eli Zaretskii schrieb:
>> From: Stephan Lukits <stephan.lukits@FernUni-Hagen.de>
>> Date: Tue, 30 Oct 2007 16:26:39 +0100
>> Cc: 
>>
>> Hello,
>> every few minutes I get this annoying question:
>> <filename> changed on disk; really edit the buffer?
> 
> Thank you for your report.
> 
> What file is that?  Or does this happen with any file that Emacs
> visits?

It happens with any file that Emacs visits.

best regards
Stephan

Re: <filename> changed on disk; really edit the buffer?

[Eli Zaretskii]

> From: Stephan Lukits <stephan.lukits@FernUni-Hagen.de>
> Date: Wed, 31 Oct 2007 16:28:55 +0100
> Cc: 
> 
> >> every few minutes I get this annoying question:
> >> <filename> changed on disk; really edit the buffer?
> > 
> > Thank you for your report.
> > 
> > What file is that?  Or does this happen with any file that Emacs
> > visits?
> 
> It happens with any file that Emacs visits.

Can you please show the values computed by

   (file-attributes FILE)

and by

   (visited-file-modtime)

the latter in the buffer that visits FILE?

Please do this immediately after you visit the file with
"C-x C-f FILE RET".

Re: <filename> changed on disk; really edit the buffer?

[Stephan Lukits]

Eli Zaretskii schrieb:
>> From: Stephan Lukits <stephan.lukits@FernUni-Hagen.de>
>> Date: Wed, 31 Oct 2007 16:28:55 +0100
>> Cc: 
>>
>>>> every few minutes I get this annoying question:
>>>> <filename> changed on disk; really edit the buffer?
>>> Thank you for your report.
>>>
>>> What file is that?  Or does this happen with any file that Emacs
>>> visits?
>> It happens with any file that Emacs visits.
> 
> Can you please show the values computed by
> 
>    (file-attributes FILE)

Here we go.  The output of

"M-x eval-expression RET" and "(file-attributes "~/.emacs") RET"

is

(nil 1 5 5 (18224 33856) (18216 41981) (18206 2636) 3042 "-rw-rw-rw-"
  nil -16252 (6714 . 34723))

> 
> and by
> 
>    (visited-file-modtime)
> 
> the latter in the buffer that visits FILE?
> 
> Please do this immediately after you visit the file with
> "C-x C-f FILE RET".

The output of

"M-x eval-expression RET" and "(visited-file-modtime) RET"

is

(18216 41981)

immediately after

"C-x C-f ~/.emacs RET"


best regards
Stephan

Re: <filename> changed on disk; really edit the buffer?

[Eli Zaretskii]

> From: Stephan Lukits <stephan.lukits@FernUni-Hagen.de>
> Date: Tue, 06 Nov 2007 16:36:31 +0100
> Cc: 
> 
> "M-x eval-expression RET" and "(file-attributes "~/.emacs") RET"
> 
> is
> 
> (nil 1 5 5 (18224 33856) (18216 41981) (18206 2636) 3042 "-rw-rw-rw-"
>   nil -16252 (6714 . 34723))
> 
> > 
> > and by
> > 
> >    (visited-file-modtime)
> > 
> > the latter in the buffer that visits FILE?
> > 
> > Please do this immediately after you visit the file with
> > "C-x C-f FILE RET".
> 
> The output of
> 
> "M-x eval-expression RET" and "(visited-file-modtime) RET"
> 
> is
> 
> (18216 41981)
> 
> immediately after
> 
> "C-x C-f ~/.emacs RET"

I'm stumped: the times are identical -- (18216 41981) in both cases.

Didn't you say that Emacs bitches about file being modified
immediately after you "C-x C-f" the file?

If it takes some time for it to complain, please wait until it
complains and evaluate these two expression then.

Thanks.

Re: <filename> changed on disk; really edit the buffer?

[martin rudalics]

> Here we go.  The output of
> 
> "M-x eval-expression RET" and "(file-attributes "~/.emacs") RET"
> 
> is
> 
> (nil 1 5 5 (18224 33856) (18216 41981) (18206 2636) 3042 "-rw-rw-rw-"
>  nil -16252 (6714 . 34723))
> 
>>
>> and by
>>
>>    (visited-file-modtime)
>>
>> the latter in the buffer that visits FILE?
>>
>> Please do this immediately after you visit the file with
>> "C-x C-f FILE RET".
> 
> 
> The output of
> 
> "M-x eval-expression RET" and "(visited-file-modtime) RET"
> 
> is
> 
> (18216 41981)
> 
> immediately after
> 
> "C-x C-f ~/.emacs RET"

Just to make sure -  could you always additionally run

"M-x eval-expression RET" and "(verify-visited-file-modtime (current-buffer)) RET"

too.  After finding the file and after the error occurred.

Re: <filename> changed on disk; really edit the buffer?

[Stephan Lukits]

Eli Zaretskii schrieb:
>> From: Stephan Lukits <stephan.lukits@FernUni-Hagen.de>
>> Date: Tue, 06 Nov 2007 16:36:31 +0100
>> Cc: 
>>
>> "M-x eval-expression RET" and "(file-attributes "~/.emacs") RET"
>>
>> is
>>
>> (nil 1 5 5 (18224 33856) (18216 41981) (18206 2636) 3042 "-rw-rw-rw-"
>>   nil -16252 (6714 . 34723))
>>
>>> and by
>>>
>>>    (visited-file-modtime)
>>>
>>> the latter in the buffer that visits FILE?
>>>
>>> Please do this immediately after you visit the file with
>>> "C-x C-f FILE RET".
>> The output of
>>
>> "M-x eval-expression RET" and "(visited-file-modtime) RET"
>>
>> is
>>
>> (18216 41981)
>>
>> immediately after
>>
>> "C-x C-f ~/.emacs RET"
> 
> I'm stumped: the times are identical -- (18216 41981) in both cases.
> 
> Didn't you say that Emacs bitches about file being modified
> immediately after you "C-x C-f" the file?

I said in http://groups.google.de/group/gnu.emacs.bug/msg/7c8c4bd5e77eb306

   "every few minutes I get this annoying question:
    <filename> changed on disk; really edit the buffer?

    I'm absolutely sure that no other program is using
    this file."


> If it takes some time for it to complain, please wait until it
> complains and evaluate these two expression then.

O.k.
After opening the file I get the attributes

(nil 1 5 5 (18227 8016) (18227 8016) (18206 2636) 3066 "-rw-rw-rw-" nil 
-16252 (6714 . 34723))

and nothing else happens.  Then I write a few words, wait until Emacs
does "Auto-saving..." and with the next character I try to type I get
the loved question:
".emacs changed on disk; really edit the buffer? (y, n, r or C-h)"

visited-file-modtime gives me then:
(18227 8016)

until next Tuesday, best regards
Stephan

Re: <filename> changed on disk; really edit the buffer?

[Eli Zaretskii]

> From: Stephan Lukits <stephan.lukits@FernUni-Hagen.de>
> Date: Thu, 08 Nov 2007 16:01:36 +0100
> Cc: 
> 
> After opening the file I get the attributes
> 
> (nil 1 5 5 (18227 8016) (18227 8016) (18206 2636) 3066 "-rw-rw-rw-" nil 
> -16252 (6714 . 34723))
> 
> and nothing else happens.  Then I write a few words, wait until Emacs
> does "Auto-saving..." and with the next character I try to type I get
> the loved question:
> ".emacs changed on disk; really edit the buffer? (y, n, r or C-h)"
> 
> visited-file-modtime gives me then:
> (18227 8016)

I need the results of evaluating both expressions at the time when the
question is asked.  You've only shown one of them.

Re: <filename> changed on disk; really edit the buffer?

[Stephan Lukits]

Eli Zaretskii schrieb:
>> From: Stephan Lukits <stephan.lukits@FernUni-Hagen.de>
>> Date: Thu, 08 Nov 2007 16:01:36 +0100
>> Cc: 
>>
>> After opening the file I get the attributes
>>
>> (nil 1 5 5 (18227 8016) (18227 8016) (18206 2636) 3066 "-rw-rw-rw-" nil 
>> -16252 (6714 . 34723))
>>
>> and nothing else happens.  Then I write a few words, wait until Emacs
>> does "Auto-saving..." and with the next character I try to type I get
>> the loved question:
>> ".emacs changed on disk; really edit the buffer? (y, n, r or C-h)"
>>
>> visited-file-modtime gives me then:
>> (18227 8016)
> 
> I need the results of evaluating both expressions at the time when the
> question is asked.  You've only shown one of them.
> 


after I have answered 'y':
(file-attributes "~/.emacs"):
(nil 1 5 5 (18232 28429) (18232 28429) (18206 2636) 3080 "-rw-rw-rw-" 
nil -16252 (6714 . 34723))

(visited-file-modtime):
(18232 28366)

Re: <filename> changed on disk; really edit the buffer?

[Eli Zaretskii]

> From: Stephan Lukits <stephan.lukits@FernUni-Hagen.de>
> Date: Mon, 12 Nov 2007 16:39:29 +0100
> Cc: 
> 
> (file-attributes "~/.emacs"):
> (nil 1 5 5 (18232 28429) (18232 28429) (18206 2636) 3080 "-rw-rw-rw-" 
> nil -16252 (6714 . 34723))
> 
> (visited-file-modtime):
> (18232 28366)

That's 63 seconds of difference, if I'm right.  Is there some process
that touches files on that filesystem?  (What filesystem is that,
btw?)  Do you see a difference in what "ls -l" says about such files
when you first visit the file, and then after Emacs complains and you
type `y'?

Re: <filename> changed on disk; really edit the buffer?

[Stephan Lukits]

Eli Zaretskii schrieb:
 >> From: Stephan Lukits <stephan.lukits@FernUni-Hagen.de>
 >> Date: Mon, 12 Nov 2007 16:39:29 +0100
 >> Cc:
 >>
 >> (file-attributes "~/.emacs"):
 >> (nil 1 5 5 (18232 28429) (18232 28429) (18206 2636) 3080 "-rw-rw-rw-"
 >> nil -16252 (6714 . 34723))
 >>
 >> (visited-file-modtime):
 >> (18232 28366)
 >
 > That's 63 seconds of difference, if I'm right.  Is there some process
 > that touches files on that filesystem?

I don't think so.  But you know it's Windows, thus you never know.
To make sure I started a reference text editor which is also
supposed to complain if the visited file changes on disk.  Since
I can work with that editor without any problem (except it's not
Emacs) I guess it's a problem with Emacs.  Btw as soon I start
Emacs and visit the same file as the other editor and Emacs does
auto-saving the other editor complains about "file changed on
disk" too.

 > (What filesystem is that,
 > btw?)

NTFS

 > Do you see a difference in what "ls -l" says about such files
 > when you first visit the file, and then after Emacs complains and you
 > type `y'?

It changes time even before Emacs complains.  It changes time
exactly at that moment when emacs does auto-saving.

before auto-saving:
$ ls -o auto-save-test.tex
-rwx------+ 1 pc-betreuung 48 Nov 13 09:59 auto-save-test.tex

after auto-saving:
$ ls -o auto-save-test.tex
-rwx------+ 1 pc-betreuung 48 Nov 13 10:00 auto-save-test.tex

Re: <filename> changed on disk; really edit the buffer?

[Jason Rumney]

Stephan Lukits wrote:
> It changes time even before Emacs complains.  It changes time
> exactly at that moment when emacs does auto-saving.
>
> before auto-saving:
> $ ls -o auto-save-test.tex
> -rwx------+ 1 pc-betreuung 48 Nov 13 09:59 auto-save-test.tex
>
> after auto-saving:
> $ ls -o auto-save-test.tex
> -rwx------+ 1 pc-betreuung 48 Nov 13 10:00 auto-save-test.tex

Auto-saving should be writing to #auto-save-test.tex#. Have you made
some customization to try to force it write to the original file?

Re: <filename> changed on disk; really edit the buffer?

[Lennart Borgman (gmail)]

Jason Rumney wrote:
> Stephan Lukits wrote:
>> It changes time even before Emacs complains.  It changes time
>> exactly at that moment when emacs does auto-saving.
>>
>> before auto-saving:
>> $ ls -o auto-save-test.tex
>> -rwx------+ 1 pc-betreuung 48 Nov 13 09:59 auto-save-test.tex
>>
>> after auto-saving:
>> $ ls -o auto-save-test.tex
>> -rwx------+ 1 pc-betreuung 48 Nov 13 10:00 auto-save-test.tex
> 
> Auto-saving should be writing to #auto-save-test.tex#. Have you made
> some customization to try to force it write to the original file?


Should not Emacs detect that situation?

Re: <filename> changed on disk; really edit the buffer?

[martin rudalics]

> It changes time even before Emacs complains.  It changes time
> exactly at that moment when emacs does auto-saving.

Do you have `auto-save-visited-file-name' non-nil?

Re: <filename> changed on disk; really edit the buffer?

[Stephan Lukits]

martin rudalics schrieb:
>> It changes time even before Emacs complains.  It changes time
>> exactly at that moment when emacs does auto-saving.
> 
> Do you have `auto-save-visited-file-name' non-nil?

Yes.  After setting it to nil the problem is gone.
I'm sorry for all the trouble.  I can't remember
having this option set but it was changed.

If this behavior is reasonable or if this setting
is an end user setting is another question.  If this
setting is set I wouldn't expect Emacs to complain
about a changed file which was changed by Emacs.

Thank you all for your kind help and best regards
Stephan

Re: <filename> changed on disk; really edit the buffer?

[martin rudalics]

 > Yes.  After setting it to nil the problem is gone.
 > I'm sorry for all the trouble.  I can't remember
 > having this option set but it was changed.

You helped us to identify a bug.  Thanks.

We could, in auto_save_1, do something like

if (! NILP (Fstring_equal (current_buffer->filename,
         		   current_buffer->auto_save_file_name)))
   Fclear_visited_file_modtime;

if the Fwrite_region succeeds, but I'm not sure of any implications of
this.  For example, current_buffer->save_length would not get set in
Fwrite_region.  Alternatively, we could try to simply save the buffer
which is the behavior described in the Elisp manual but this might be
more tricky.

 > If this behavior is reasonable or if this setting
 > is an end user setting is another question.  If this
 > setting is set I wouldn't expect Emacs to complain
 > about a changed file which was changed by Emacs.

Indeed.  Given the fact that apparently you are the first to report this
bug it seems that the option `auto-save-visited-file-name' is hardly
ever useful (at least nowadays).  The most attractive solution would be
to get rid of it.

Re: <filename> changed on disk; really edit the buffer?

[Richard Stallman]

    We could, in auto_save_1, do something like

    if (! NILP (Fstring_equal (current_buffer->filename,
			       current_buffer->auto_save_file_name)))
       Fclear_visited_file_modtime;

    if the Fwrite_region succeeds, but I'm not sure of any implications of
    this.  For example, current_buffer->save_length would not get set in
    Fwrite_region.

It would be easy enough to do those parts of the actions of
Fclear_visited_file_modtime which are right, and not the rest.

    Alternatively, we could try to simply save the buffer
    which is the behavior described in the Elisp manual but this might be
    more tricky.

Yes, it would be.

    Indeed.  Given the fact that apparently you are the first to report this
    bug it seems that the option `auto-save-visited-file-name' is hardly
    ever useful (at least nowadays).

It may not be very useful.  This option is historical since the
original Emacs.  I am sure some people used it in the 70s, but
maybe few people use it now.

      The most attractive solution would be
    to get rid of it.

Maybe we should do that, but before we do, we should ask the users
whether they mind.  Maybe some people have good reasons to use it.

Stephen, what was your motive for using it?

Re: <filename> changed on disk; really edit the buffer?

[Jonathan Goldblatt]

>>>>> "Richard" == Richard Stallman <rms@gnu.org> writes:

    Richard>     Indeed.  Given the fact that apparently you are
    Richard> the first to report this bug it seems that the
    Richard> option `auto-save-visited-file-name' is hardly ever
    Richard> useful (at least nowadays).

...

    Richard>       The most attractive solution would be to get
    Richard>	   rid of it.

    Richard> Maybe we should do that, but before we do, we should
    Richard> ask the users whether they mind.  Maybe some people
    Richard> have good reasons to use it.

I haven't used auto-save-visited-file-name.  But if I did the
motivation would be to have a hook run at the time of the
autosave.  From the documentation I would assume that the various
write file hooks would be run at the time of the auto-save, and
would try to use saving to the file as a kludge to make what I
wanted happen.  Maybe the solution is a new hook variable that
defaults to the current auto-save function.

While on the subject of possible improvements to auto-save, it
would also be nice to have a command to compare the auto-save
file to the official copy; of course I might just not have found
it yet.

Jonathan

Re: <filename> changed on disk; really edit the buffer?

[jonathangoldblatt]

>>>>> "Richard" == Richard Stallman <rms@gnu.org> writes:

    Richard>       Maybe the solution is a new hook variable that
    Richard> defaults to the current auto-save function.

    Richard> I don't quite understand that.  What does it mean?

Sorry about screwing up the addressing on the first reply. 

What I meant was something like: 

auto-save-hooks

Documentation: 
List of functions to be run before auto-saving.
If one of them returns non-nil, then the file is considered to be
already auto-saved and the rest are not called.  

Then the user can do the auto-save any way that he wants.  

Sorry about the confusion; I didn't take the time to read the
auto-save documentation.

Also occurred to me that a possible use for auto-saving into the
current file is when you don't have enough permissions in the
current directory to create a new file.  

Re: <filename> changed on disk; really edit the buffer?

[Richard Stallman]

    Also occurred to me that a possible use for auto-saving into the
    current file is when you don't have enough permissions in the
    current directory to create a new file.  

I think it would be better to put the auto save file in a different
directory.  In fact, perhaps we should change make-auto-save-file-name
to do this automatically.

Would someone like to try this?

Re: <filename> changed on disk; really edit the buffer?

[jonathangoldblatt]

What did you think of the auto-save-hooks idea?  In GNU Emacs
21.4.1 there is just 

auto-save-hook's value is nil

Documentation:
Normal hook run just before auto-saving.

Another possible advantage of auto-saving into the file is that
it simplifies using session-recover if something does go wrong.
I have one file that always shows up with an auto-save file and
what I always wind up doing is a compare with the original to
check that I really want to do the replace, which I always do.
Just struck me that I maybe I should set this file to save into
itself.  Unfortunately, it's a largish .gz, that takes a while to
save, but I might decide to stop being a bit miser, and just
use a normal file.  

I'd like to do some work on this stuff, and some of the other TO
DO's but unfortunately my personal life doesn't leave me with
enough time.  

Re: <filename> changed on disk; really edit the buffer?

[Richard Stallman]

The idea makes sense.  The variables should be named
auto-save-functions, according to conventions since 15 years ago.

But it isn't quite straightforward, because the code in fileio.c uses
a static variable auto_saving which alters the behavior of
write-region.

We do theoretically have a problem with this now, since the call to
Fsleep_for could run a process filter or sentinel.  So it would be
good to change that mechanism.

Re: <filename> changed on disk; really edit the buffer?

[martin rudalics]

 >     Also occurred to me that a possible use for auto-saving into the
 >     current file is when you don't have enough permissions in the
 >     current directory to create a new file.
 >
 > I think it would be better to put the auto save file in a different
 > directory.  In fact, perhaps we should change make-auto-save-file-name
 > to do this automatically.

`make-auto-save-file-name' already tries to substitute the
default-directory in


		    (expand-file-name
		     (format "#%s#" buffer-name)
		     ;; Try a few alternative directories, to get one we can
		     ;; write it.
		     (cond
		      ((file-writable-p default-directory) default-directory)
		      ((file-writable-p "/var/tmp/") "/var/tmp/")
		      ("~/")))))

What else should it do?

Re: <filename> changed on disk; really edit the buffer?

[Richard Stallman]

    `make-auto-save-file-name' already tries to substitute the
    default-directory in

			(expand-file-name
			 (format "#%s#" buffer-name)
			 ;; Try a few alternative directories, to get one we can
			 ;; write it.
			 (cond
			  ((file-writable-p default-directory) default-directory)

That is in the branch for non-file buffers.

Re: <filename> changed on disk; really edit the buffer?

[Stephan Lukits]

Richard Stallman schrieb:
> [...]
>       The most attractive solution would be
>     to get rid of it.
> 
> Maybe we should do that, but before we do, we should ask the users
> whether they mind.  Maybe some people have good reasons to use it.
> 
> Stephen, what was your motive for using it?
> 

If I work on a tex-Document with some includes and some graphics, a
directory can get pretty crowded, thus I don't want to have further
files which are pretty useless to me.  The only useful situation I can
imagine for having a separate file for auto-saving is if the System,
Machine or Application crashes while emacs does autosaving.
This sounds rather unlikely to me.  Further more I do always backup my
Work after I finished a days work on to different media thus I can
afford the risk which auto-saving in the file in use causes.  But
I wouldn't mind if this function disappears.  If it would work it would
just be a "nice to have".

best regards
Stephan

Re: <filename> changed on disk; really edit the buffer?

[Richard Stallman]

    If I work on a tex-Document with some includes and some graphics, a
    directory can get pretty crowded, thus I don't want to have further
    files which are pretty useless to me.  The only useful situation I can
    imagine for having a separate file for auto-saving is if the System,
    Machine or Application crashes while emacs does autosaving.

Actually that's the principal purpose of autosaving.

Re: <filename> changed on disk; really edit the buffer?

[Hallvard B Furuseth]

Richard Stallman writes:
>     (...) The only useful situation I can imagine for having a
>     separate file for auto-saving is if the System, Machine or
>     Application crashes while emacs does autosaving.
>
> Actually that's the principal purpose of autosaving.

Auto-save has a misleading name, it sounds like it saves to the original
file.  Might be a bit late to rename it, but the related variables and
functions could use some clarifications in the doc strings.

And Info node (emacs)Auto Save might mention "to another file" right up
front, even if menu item "Files: Auto Save Files" is quite a clue if one
does not read further.

-- 
Regards,
Hallvard

Re: <filename> changed on disk; really edit the buffer?

[mdaily2002]

On Nov 13, 6:12 am, Stephan Lukits <stephan.luk...@FernUni-Hagen.de>
wrote:
> martin rudalics schrieb:
>
> >> It changes time even before Emacs complains.  It changes time
> >> exactly at that moment when emacs does auto-saving.
>
> > Do you have `auto-save-visited-file-name' non-nil?
>
> Yes.  After setting it to nil the problem is gone.
> I'm sorry for all the trouble.  I can't remember
> having this option set but it was changed.
>
> If this behavior is reasonable or if this setting
> is an end user setting is another question.  If this
> setting is set I wouldn't expect Emacs to complain
> about a changed file which was changed by Emacs.
>
> Thank you all for your kind help and best regards
> Stephan

I was also having this problem with emacs on windows and it was very
annoying.  So far the solution seems to be working.  I don't think it
has anything to do with summer time since that is now over in the US
as well.

Mike Daily

Re: <filename> changed on disk; really edit the buffer?

[mdaily2002]

On Nov 18, 2:12 pm, mdaily2...@gmail.com wrote:
> On Nov 13, 6:12 am, Stephan Lukits <stephan.luk...@FernUni-Hagen.de>
> wrote:
>
>
>
> > martin rudalics schrieb:
>
> > >> It changes time even before Emacs complains.  It changes time
> > >> exactly at that moment when emacs does auto-saving.
>
> > > Do you have `auto-save-visited-file-name' non-nil?
>
> > Yes.  After setting it to nil the problem is gone.
> > I'm sorry for all the trouble.  I can't remember
> > having this option set but it was changed.
>
> > If this behavior is reasonable or if this setting
> > is an end user setting is another question.  If this
> > setting is set I wouldn't expect Emacs to complain
> > about a changed file which was changed by Emacs.
>
> > Thank you all for your kind help and best regards
> > Stephan
>
> I was also having this problem with emacs on windows and it was very
> annoying.  So far the solution seems to be working.  I don't think it
> has anything to do with summer time since that is now over in the US
> as well.
>
> Mike Daily

Actually it didn't work.  The only solution I found that seems to work
is to turn auto-save-default to nil, with the caveat that that gets
rid of auto-saving.  It looks like emacs auto-saves every 300
characters you type into the file; hence this is why it thinks the
file has changed on disk.

Mike

Re: <filename> changed on disk; really edit the buffer?

[martin rudalics]

> Actually it didn't work.  The only solution I found that seems to work
> is to turn auto-save-default to nil, with the caveat that that gets
> rid of auto-saving.  It looks like emacs auto-saves every 300
> characters you type into the file; hence this is why it thinks the
> file has changed on disk.

Please do two things:

(1) Emacs should not try to overwrite the actual file when autosaving.
For Stephan it was sufficient to leave `auto-save-visited-file-name' at
its default value nil.  Hence, make sure that the value of this variable
is nil.  If Emacs still overwrites the file you're editing there must be
some other reason.  Also, tell us all your customizations containing an
`auto-save-...' prefix.

(2) Post here the values of (file-attributes file) where file is the
name of the file visited by your buffer, and (visited-file-modtime) and
(verify-visited-file-modtime (current-buffer)) bothe evaluated in that
buffer.  Please evaluate these expressions twice: Once immediately after
visiting the file and a second time when Emacs asks you about autosaving.

Re: <filename> changed on disk; really edit the buffer?

[Stephan Lukits]

martin rudalics schrieb:
>> Here we go.  The output of
>>
>> "M-x eval-expression RET" and "(file-attributes "~/.emacs") RET"
>>
>> is
>>
>> (nil 1 5 5 (18224 33856) (18216 41981) (18206 2636) 3042 "-rw-rw-rw-"
>>  nil -16252 (6714 . 34723))
>>
>>>
>>> and by
>>>
>>>    (visited-file-modtime)
>>>
>>> the latter in the buffer that visits FILE?
>>>
>>> Please do this immediately after you visit the file with
>>> "C-x C-f FILE RET".
>>
>>
>> The output of
>>
>> "M-x eval-expression RET" and "(visited-file-modtime) RET"
>>
>> is
>>
>> (18216 41981)
>>
>> immediately after
>>
>> "C-x C-f ~/.emacs RET"
> 
> Just to make sure -  could you always additionally run
> 
> "M-x eval-expression RET" and "(verify-visited-file-modtime 
> (current-buffer)) RET"
> 
> too.  After finding the file and after the error occurred.

It returns nil.

best regards
Stephan

Re: <filename> changed on disk; really edit the buffer?

[martin rudalics]

 >> Just to make sure -  could you always additionally run
 >>
 >> "M-x eval-expression RET" and "(verify-visited-file-modtime
 >> (current-buffer)) RET"
 >>
 >> too.  After finding the file and after the error occurred.
 >
 >
 > It returns nil.

Hence the problem seems to be with `verify-visited-file-modtime'.  Maybe
the file-name encoding.

Re: <filename> changed on disk; really edit the buffer?

[Stephan Lukits]

martin rudalics schrieb:
>> every few minutes I get this annoying question:
>> <filename> changed on disk; really edit the buffer?
> 
> This is from `ask-user-about-supersession-threat'.

Thanks for that one.  I redefined it with an function which has an empty
body, so I can work undisturbed.  Of course this is only an interim
solution until the reason of the problem is tracked down.

> 
>> I'm absolutely sure that no other program is using
>> this file.
> 
> Does this happen since the DST change (saturday/sunday) or did it
> happen before?

This could be but I'm not a 100% sure.

> 
> Does it go away when you touch the file in question, that is, set
> its modification time to now.

Hm.  I couldn't find this file attribute within the Windows Explorer.
Within dired I found the operation "Change Timestamp ... (T)".  I tried
it but it didn't help.  Could you please be a bit more detailed about
what I should do exactly.

best regards and thanks for your help
Stephan Lukits

Re: <filename> changed on disk; really edit the buffer?

[martin rudalics]

 > Hm.  I couldn't find this file attribute within the Windows Explorer.

I never use the Explorer, most file managers allow doing that easily.
You could also try a GNU port like touch.exe.

 > Within dired I found the operation "Change Timestamp ... (T)".  I tried
 > it but it didn't help.  Could you please be a bit more detailed about
 > what I should do exactly.

Experiment with the functions in section 27.6 Buffer Modification Time
of the Elisp manual.  `verify-visited-file-modtime' is probably the one
causing the complaints, if it returns nil you get the message.
`clear-visited-file-modtime' (this should be done when you open a file)
and `set-visited-file-modtime' (usually done when you save a file)
should both assert that the message is not issued, hence if you do
either of these and afterwards get the message for that buffer,
something is wrong with Emacs' way of handling modification times.

Hence you can, for example, do

M-:

(clear-visited-file-modtime)

after opening a file that usually throws the messages and see what

M-:

(verify-visited-file-modtime (current-buffer))

returns.

Re: <filename> changed on disk; really edit the buffer?

[Stephan Lukits]

Jason Rumney schrieb:
> Stephan Lukits wrote:
>> Hello,
>> every few minutes I get this annoying question:
>> <filename> changed on disk; really edit the buffer?
>>
>> I'm absolutely sure that no other program is using
>> this file.
> Do you have TZ set in your environment? 

System infomation -> Software environment -> environment variables
(a free translation from German) says I don't.


best regards
Stephan Lukits

Re: <filename> changed on disk; really edit the buffer?

[Jim Dishaw]

Stephan Lukits <stephan.lukits@FernUni-Hagen.de> writes:

> Hello,
> every few minutes I get this annoying question:
> <filename> changed on disk; really edit the buffer?
>

Is the file located on a network share?  If so, the clocks may be off a
little bit. 

Re: <filename> changed on disk; really edit the buffer?

[Stephan Lukits]

Jim Dishaw schrieb:
> Stephan Lukits <stephan.lukits@FernUni-Hagen.de> writes:
> 
>> Hello,
>> every few minutes I get this annoying question:
>> <filename> changed on disk; really edit the buffer?
>>
> 
> Is the file located on a network share?  

No, it isn't.

best regards
Stephan