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
The attached patch fixes the problem with displaying the value of the NL
character in files edited with 'ff' set to mac. The solution was to
replace CARs with NLs when printing their values for mac-format files.
--
Cheers,
Lech
--~--~-~--~~~---~--~~
You received
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
Lech Lorens wrote:
The attached patch fixes the problem with displaying the value of the NL
character in files edited with 'ff' set to mac. The solution was to
replace CARs with NLs when printing their values for mac-format files.
Thanks. I'll look into it later.
--
Why I like vim:
I
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
12 matches
Mail list logo
