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
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
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
On Sun, Jan 4, 2009 at 16:26, Adam Osuchowski ad...@zonk.pl wrote:
Nikolai Weibull wrote:
I haven't really understood what the problem is (I don't believe that
there actually is one),
There is a non-zero time period between open file and write complete
content. Because vim truncate file
Nikolai Weibull wrote:
On Sun, Jan 4, 2009 at 16:26, Adam Osuchowski ad...@zonk.pl wrote:
Nikolai Weibull wrote:
I haven't really understood what the problem is (I don't believe that
there actually is one),
There is a non-zero time period between open file and
On Sun, Jan 4, 2009 at 23:19, Charles E. Campbell, Jr.
drc...@campbellfamily.biz wrote:
Nikolai Weibull wrote:
No, I mean both O_EXCL (so that a file hasn't been created in between
the time the original file has been renamed and the new one opened - a
case so far not mentioned (or?)) and
Nikolai Weibull wrote:
On Sun, Jan 4, 2009 at 23:19, Charles E. Campbell, Jr.
drc...@campbellfamily.biz wrote:
Nikolai Weibull wrote:
No, I mean both O_EXCL (so that a file hasn't been created in between
the time the original file has been renamed and the new one opened - a
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
If you're writing to a file that another program critically needs
/that's/ your problem.
Configuration file, for example, is critically for almost every daemon.
Do you think that it is only my problem? No, it is very real scenario
which could happen to everyone who use vim.
He didn't mean
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
On 03/01/09 22:03, Adam Osuchowski wrote:
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)
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
On 04/01/09 04:19, Adam Osuchowski wrote:
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,
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
16 matches
Mail list logo