Bluelich / vim

Automatically exported from code.google.com/p/vim
0 stars 0 forks source link

gvimdiff on Windows generates the same v:fname_out from multiple processes #353

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Use gvimdiff -R as the diff tool for Perforce
2. Attempt to diff 8 files at once

What is the expected output? What do you see instead?
I expect to see 8 copies of gvimdiff open showing the diffs of those files

Instead, I get 8 copies of gvimdiff open, usually with one or two complaining:
E810: Cannot read or twite temp files
E97: Cannot create diffs.

What version of the product are you using? On what operating system?
This is VIM 7.4.552 MS-Windows 64-bit GUI version with OLE support compiled by 
veegee@veegee-win8, running on Windows 7 Professional x64

Please provide any additional information below.

I've used echom in my diffexpr, and the issue appears to be that two different 
vim processes have picked the same value for v:fname_out.

For example, a successful process shows:
!C:\\program~1\\GnuWin32\\bin\\diff.exe -a 
C:\Users\paulh\AppData\Local\Temp\VIoD3A5.tmp 
C:\Users\paulh\AppData\Local\Temp\VInD3A6.tmp 
C:\Users\paulh\AppData\Local\Temp\VIdD3B5.tmp

and the failed attempt from the same batch shows
!C:\\program~1\\GnuWin32\\bin\\diff.exe -a 
C:\Users\paulh\AppData\Local\Temp\VIoD3B3.tmp 
C:\Users\paulh\AppData\Local\Temp\VInD3B4.tmp 
C:\Users\paulh\AppData\Local\Temp\VIdD3B5.tmp

So it looks like the filename is merely VI[ond]time.tmp but due to minor 
startup time differences, the output file name for two processes was generated 
at the same time, leading to the same output file.

Using :diffupdate in the failed gvimdiff instance will successfully generate 
the diff

Original issue reported on code.google.com by p_hamp...@wargaming.net on 31 Mar 2015 at 5:04

GoogleCodeExporter commented 9 years ago
There is a race condition between getting the name of the temp file and 
creating it. Patch 7.4.684 should avoid it in this specific situation.

Original comment by brammool...@gmail.com on 31 Mar 2015 at 11:45