Adam Osuchowski wrote:
> Some time ago I wrote here about race condition during file saving
> (http://groups.google.com/group/vim_dev/tree/browse_frm/month/2009-01/0049693b73a6a1e6).
> Some of you didn't share my opinion about this problem and said
> "File systems is not databases with ACID properties". Ok, I agree and know
> it is rather POSIX semantic's fault. But my case has come back to me.
>
> In that thread, I suggested that rename() syscall should improve bahaviour
> beacuse of atomical nature of this syscall. One of argument against using
> rename() was that it would break hard and soft links.
>
> In soft links case, I can't imagine how rename() could break it. If process
> atomically exchange file which is pointed to by symlink, nothing will break
> down. Even, if it is chain of symlinks.
>
> In hard links case, really there is a problem, and this case should be
> treated individually (fortunately, hardlinks are rather relatively rare
> case). But in other cases, rename() should be safe.
>
> Furthermore, even now, vim changes inode of edited file:
>
> # ls -li testfile
> 2955134269 -rw------- 1 root root 15 Jan 25 22:44 testfile
> # vim testfile
> [...edit file here...]
> # ls -li testfile
> 2955134271 -rw------- 1 root root 20 Jan 25 22:44 testfile
>
> rename() would behave identically and moreover would be atomic.
It appears you don't have 'backupcopy' set, as was recommended in the
thread you quote.
> So, I have a little request to developers. Please, read it again and try
> to understand me. Atomic rename() is better solution. It's not so stupid
> as it may appear at first look and shouldn't break to much. :-)
I'm afraid that it will break much. Especially when not on a Unix
system. The problem is that using rename() is not atomic, because we
need two of them. And the procedure to write a new file and then rename
again has the problem that the inode changes, which is bad for hard
links and complex ACL.
The only solution is overwriting the file. Currently it's first made
empty. It would be possible to first write the new contents and then
truncate to remove any remaining old text. But that's worse: halfway
writing you have an inconsistent file, at some place it switches from
the new text to the old text. I rather have a truncated file, that's
less problematic.
In case we rename the file to make a backup, it would be possible to
first write the new file and then use two rename calls to swap the old
and new files. Again, if another process is using the file, it will
suddenly see different text. And on Unix, if the file was opened by
another process, it will keep on using the old version. This only
solves a few very specific situations.
--
hundred-and-one symptoms of being an internet addict:
152. You find yourself falling for someone you've never seen or hardly
know, but, boy can he/she TYPE!!!!!!
/// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ download, build and distribute -- http://www.A-A-P.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
--
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
