<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:13px">In normal compilation, the file remains mapped into memory until compilation is over. Sometimes the AST has pointers to string data embedded in the code. In YCM, I guess compilation is never "over" so the file stays mapped indefinitely.</span> </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>We need to figure out a file mapping strategy that will work on Windows. On Linux, there are no file locks, and "well behaved" editors generally save files atomically by writing a temp file and renaming it over the original file. I don't know what editors on Windows do. If popular editors (Notepad+, VS, sublime, Vim, etc) rewrite the file in place, then we might have to give up on the mmap approach, as it will be racy.<br></div></div></div></div>
</blockquote></div><br></div><div class="gmail_extra">I tried some different editors and commands on the file</div><div class="gmail_extra"> </div><div class="gmail_extra">Fails to write file: Sublime text 2, notepad++</div><div class="gmail_extra">Can write file: Visual studio 2013, windows notepad</div><div class="gmail_extra"><br></div><div class="gmail_extra">Fails to delete file: explorer.exe, Total Commander</div><div class="gmail_extra">Can delete file: del command on commandline</div><div class="gmail_extra"><br></div><div class="gmail_extra">Funny, but painful, how they all act different.</div><div class="gmail_extra"><br></div><div class="gmail_extra">So if this boils down to libclang keeping this file mapped in memory (with sharemode to only read) around to provide an AST and functionality to external tools, maybe the sharemode could be relaxed from read only to read/write/delete when not actively compiling?</div><div class="gmail_extra">Or maybe the external tool should be able to tell libclang to clean the mapping up?</div><div class="gmail_extra">I briefly looked at the C api and saw many "dispose" functions. Will functions like clang_disposeTranslationUnit() not clean up the file mapping?</div><div class="gmail_extra"><br></div><div class="gmail_extra">I hope this is not a too uninformed suggestion!</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div></div>