Matt Wozniski wrote:

> On Sat, Jan 3, 2009 at 11:27 PM, Adam Osuchowski wrote:
> >
> > Cases like mbox files are not so rare. There are many examples of
> > simultaneously access to single file, but problem exists even without
> > concurrent modification.
> >
> > A simple example: editing config file for some daemon. When vim
> > truncates this file and program read it at the same time (because,
> > for example, it will be restarted by cron, other administrator or even
> > by itself) it will be problematic situation. The same matter is if
> > a program will be run from cron or other program (for example, procmail
> > from sendmail). Recover option in vim does not help here. Do you suggest
> > turn off all processes during editing config files?
> >
> > Vim is used on multiuser and multiprocess systems, so limiting the working
> > users or simultaneously processes to single one is misunderstanding.
> > Why do you disrespect problem, especially if there is solution in the
> > form of proper use of rename(2) syscall, which I mentioned about?
> 
> rename(2) doesn't do everything needed.  What if the file being
> written is a symlink, or a hard link?  rename() would break the link,
> which probably isn't what you want an editor to do...

That's all taken care of when 'backupcopy' is "auto".  If you want the
original file to always exist set 'backupcopy' to "yes".  Saving files
will be slower then, since Vim needs to both write a copy and write the
actual file.

Since you are overwriting the file there always is a moment it's empty.

-- 
If you don't get everything you want, think of
everything you didn't get and don't want.

 /// 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
-~----------~----~----~----~------~----~------~--~---

Raspunde prin e-mail lui