bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Minor bug in simultaneous editing check.


From: Eli Zaretskii
Subject: Re: Minor bug in simultaneous editing check.
Date: Thu, 7 Jun 2001 09:23:44 +0300

On Wed, 6 Jun 2001, Alex Farran wrote:

> Say I have a file on VMS called foo.bar.  There are multiple versions -
> foo.bar;1 , foo.bar;2, foo.bar;3.  Where foo.bar;3 is the latest version.
> 
> Over NFS these appear as foo.bar.1, foo.bar.2 and foo.bar for the latest
> version.
> 
> When I edit foo.bar on emacs and go to save it this happens
> 
> 1.  To create a backup, the latest version of foo.bar ( the only version as
> far as emacs is concerned ) is renamed as foo.bar~
> 2.  The latest foo.bar is is now version 2, so foo.bar.2 is now foo.bar.

This sounds like something Emacs cannot possibly handle: the NFS
client (or is it a server?) is in effect producing hard links behind
Emacs's back.

Perhaps the NFS software has some optional feature which could disable
this effect.

> My solution to this is to set the backup-by-copying variable in .emacs.

Looks like the correct work-around for this case.

> Surely, though, it would be better if the date check was performed
> once on the existing file before backing it up and saving the contents of the
> buffer.

I'm not sure I understand what are you suggesting.

The effect of what NFS does is that Emacs renames foo.bar, and expects
foo.bar to not exist anymore, but another foo.bar, with a different
time stamp, magically appears on the disk.  The same kind of thing
would happen if an external program or another user would produce
foo.bar between the time Emacs renames it and the time it saves the
modified buffer.  Any solution to the VMS problem will stop Emacs from
catching this situation, and so could screw users (by nuking their
files without warning), I think.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]