Adam Osuchowski wrote:
fd = open(file);
read(fd, buffer, size);
close(fd);
copy(file, file~);
[...here user edits file...]
fd = open(file.tmp, O_WRONLY|O_CREAT|O_TRUNC);
write(fd, new content of file);
close(fd);
chmod(file.swp, mode);
chown
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
Did you think about use leases to exclusively lock file during save?
I mean fcntl() with F_SETLEASE. It acquires mandatory lock and doesn't break
hard links, which you afraid of. Processes which try to read file during
saving are blocked on open() until lease is removed, so it doesn't change
Matt Wozniski wrote:
rename(2) doesn't do everything needed.
Right, but current behaviour is even worse. We can't protect if somebody
create file while vim saves it due to system limitations, but we can
protect against completely lack of file or situation when it is partially
written.
Bram Moolenaar wrote:
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.
Not quite. Of course, with 'backupcopy' set to
Nikolai Weibull wrote:
Either way, I really don't think we have a problem to fix.
So what is your advice? Ignore it? It's very comfortable to call flows
features, we have perfect situation and don't need to worry about
consequences.
If you're writing to a file that another program critically
Charles E. Campbell, Jr. wrote:
Likely areas for problems like this concern cooperative editing (ie.
multiple people editing the same file) and editing log files (or other
files which are potentially being written to by some other program).
Vim isn't designed for cooperative editing; I
There is a race condition in vim 7.2 (and probably in earlier too) on POSIX
platforms. Below, there is fragment of strace output related to this problem.
stat64(testfile~, 0xbfc35dbc) = -1 ENOENT (No such file or directory)
stat64(testfile, {st_mode=S_IFREG|0600, st_size=12, ...}) = 0
Tony Mechelynck wrote:
See
:help backup
:help 'backup'
:help 'writebackup'
:help 'backupcopy'
:help timestamp
I try different settings of this variables and there was always the same
situation:
open(testfile, O_WRONLY|O_CREAT|O_TRUNC, 0600) = 3
write(3, test
Tony Mechelynck wrote:
I don't know. There're only one keyboard and one display on this
machine, and I try to avoid having several programs modify a single file
simultaneously outside each other's knowledge. The rare case is
/var/spool/mail/root which is appended to by my cron jobs, and
10 matches
Mail list logo
