59561Re: windows bug: filewritable() returns 0 if we use it on the current script being read
- Nov 4, 2010
> > Assuming you don't want permissive sharing when doing actualAs I said I'm pretty fine with this way of seeing things, but then it
> > 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?
> Although I haven't followed exactly what the OP is proposing,
> what Craig says is correct. Allowing multiple writers to the
> same file is only desirable under very planned circumstances
> which do NOT include a text editor writing to a file.
means the "bug" is in the current *nix version. IMHO vim should behave
as consistently as possible on the platforms it runs on, thus we'd
then change the *nix api to behave like the current win32 one.
Also, the way vim behaves on win32 about this is probably
inconsistent, as a test script I did the following:
echo 'writable: ' . filewritable(expand('<sfile>'))
When I do ":source %" it output writable: 0, then writes the file
So I *think* that originally the vim authors never intended to prevent
other processes/whatever from begin able to open the same files, only
that on windows on some occasions the authors got lazy and forgot
about the dwSharedMode flag and just set it to 0. Someone should
decide wether we want to prevent it or not and then implement it on
all the platforms.
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
- << Previous post in topic Next post in topic >>