Phillippe Vaucher wrote: > > I'm pretty sure you nomally WANT to lock a file from being written, > > while you are executing its contents as a script. It sounds like this > > is what is happening. Is there some reason you want to write the file > > while executing it? > > This bug arised from a script that checked wether itself was writable in > order to > decide to go and write to the parent directory or go to alternate routes like > ~/.vim etc. If you want more details I'll be happy to provide them but the > point is > that if such behavior is enabled in *nix it'd also be enabled in windows or > disabled in both. > > The thing I'm really after is consistency, the fix for the particular script > was to > change it to check the script's directory instead which works consistently on > both platforms. > > Philippe
Changing the share mode to (FILE_SHARE_READ | FILE_SHARE_WRITE) in mch_access() is theoretically safe, because mch_access() doesn't do any I/O and closes the handle immediately. It would not be ok to make a broader change throughout the source code to always open handles with more permissive sharing. When you use those share modes, basically you're saying "I'm opening a file handle now, and I really don't care if anyone else is reading and/or writing the file at the same time as I'm working with the file." In general you do care. If you're writing to a file, you don't want another process also writing, which would result in undefined file contents. You don't really want one process reading while another process is writing either, because then the reader will see an inconsistent view. The only type of sharing that is typically safe is read-read. Assuming you don't want permissive sharing when doing actual I/O (I argue above that you don't), I question the value of changing mch_access() in the proposed way. The point of mch_access() is to give you a predictor of what types of access will likely work. If the access check tells you that opening the file for write will work, but then when you actually open it for write (using realistic sharing values) it fails, isn't this worse than what we have now? The proposed change to mch_access() would only address a narrow scenario anyway. It allows you to avoid a sharing violation imposed by *your* handle. You'll still see sharing violations imposed by *other* handles. The general rule is that the access mode of any opened handle must be compatible with the share mode of all other opened handles. Craig -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
