It makes sense, but we must make sure this does not cause any trouble.
Does it work on all Windows versions?
On Unix we never care about others having the file open, thus I don't
see a reason to check for that on MS-Windows.
--
Q: How do you tell the difference between a female cat and a male cat?
A: You ask it a question and if HE answers, it's a male but, if SHE
answers, it's a female.
/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ download, build and distribute -- http://www.A-A-P.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
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
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.
John
After installing vim7.3 on a ubuntu system, I had again the problem that
import did not work for .so libraries in lib-dynload. I found that
sys.path was initialized with "/usr/..." instead of "/usr/local/...". On
ubuntu (and probably on other linux distros as well) python3 is
installed in /usr/local while python2 is installed in /usr.
The attached patch calls Py_SetPythonHome with PYTHON3_PREFIX defined by
configure.
This solves the problem.
regards, Roland
That's not the case at all[0]. No distribution package should install
to /usr/local as that's a reserved directory structure for the system
administrator[1]. If your Python3 install is in /usr/local, then whoever
admins that system installed it there.
> The attached patch calls Py_SetPythonHome with PYTHON3_PREFIX
> defined by configure.
> This solves the problem.
This does make sense for supporting people who have installed Python
outside of the standard paths, though. This should probably be done for
Python2.x as well.
[0]: http://packages.ubuntu.com/maverick/i386/python3.1/filelist
[1]: http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLOCALLOCALHIERARCHY
--
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega <jame...@jamessan.com>
Would it make more sense to use Py_GetPrefix() or Py_GetExecPrefix() as the
input to Py_SetPythonHome() instead?
Using Thunderbird I've chosen an arbitrary message from vim_dev and
changed subject and body.
I didn't know that the threading is done on invisible email message
fields other than the subject. I looked at the email source and found
fields like References and In-Reply-To.
There is always something new to learn. For my next message I'll take it
into account.