One more thought about vim race condition during file saving

2009-01-11 Fir de Conversatie Adam Osuchowski
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

Re: Race condition during file saving

2009-01-04 Fir de Conversatie Matt Wozniski
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

Re: Race condition during file saving

2009-01-04 Fir de Conversatie Adam Osuchowski
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.

Re: Race condition during file saving

2009-01-04 Fir de Conversatie Adam Osuchowski
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

Re: Race condition during file saving

2009-01-04 Fir de Conversatie Nikolai Weibull
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

Re: Race condition during file saving

2009-01-04 Fir de Conversatie Charles E. Campbell, Jr.
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

Re: Race condition during file saving

2009-01-04 Fir de Conversatie Nikolai Weibull
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

Re: Race condition during file saving

2009-01-04 Fir de Conversatie Charles E. Campbell, Jr.
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

Re: Race condition during file saving

2009-01-04 Fir de Conversatie Adam Osuchowski
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

Re: Race condition during file saving

2009-01-04 Fir de Conversatie Adam Osuchowski
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

Re: Race condition during file saving

2009-01-04 Fir de Conversatie Ben Schmidt
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

Race condition during file saving

2009-01-03 Fir de Conversatie Adam Osuchowski
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

Re: Race condition during file saving

2009-01-03 Fir de Conversatie Tony Mechelynck
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)

Re: Race condition during file saving

2009-01-03 Fir de Conversatie Adam Osuchowski
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

Re: Race condition during file saving

2009-01-03 Fir de Conversatie Tony Mechelynck
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,

Re: Race condition during file saving

2009-01-03 Fir de Conversatie Adam Osuchowski
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