This is a feature of ctypes. Without these, pypy complains with
RuntimeWarning: C function without declared arguments called
RuntimeWarning: C function without declared return type called
As a side effect of specifying restypes, the return value of e.g. CreateFileA
is now implicitly converted to an instance of _HANDLE, so we also need to
change the definition
_INVALID_HANDLE_VALUE = -1
to
_INVALID_HANDLE_VALUE = _HANDLE(-1).value
Otherwise, tests for equality to _INVALID_HANDLE_VALUE in code like
def _getfileinfo(name):
fh = _kernel32.CreateFileA(name, 0,
_FILE_SHARE_READ | _FILE_SHARE_WRITE | _FILE_SHARE_DELETE,
None, _OPEN_EXISTING, 0, None)
if fh == _INVALID_HANDLE_VALUE:
_raiseoserror(name)
would now fail to detect an invalid handle, which in turn would lead to
exceptions raised with wrong errno values, like e.g.
>>> nlinks('missing.txt')
Traceback (most recent call last):
...
OSError: [Errno 9] missing.txt: The handle is invalid.
instead of the correct (as per this patch and before it)
>>> nlinks('missing.txt')
Traceback (most recent call last):
...
OSError: [Errno 2] missing.txt: The system cannot find the file specified.
The pywin32 package is no longer needed.
ctypes is now required for running Mercurial on Windows.
ctypes is included in Python since version 2.5. For Python 2.4, ctypes is
available as an extra installer package for Windows.
Moved spawndetached() from windows.py to win32.py and fixed it, using
ctypes as well. spawndetached was defunct with Python 2.6.6 because Python
removed their undocumented subprocess.CreateProcess. This fixes
'hg serve -d' on Windows.
Set dwDesiredAccess to 0 instead of GENERIC_READ.
Zero is enough for querying the file metadata. We don't even need to
access the -contents- of the file.
Set dwShareMode to FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE
instead of the overly restrictive FILE_SHARE_READ.
There is no need to cause write or delete accesses by other processes to
fail while we are querying file metadata.
See http://msdn.microsoft.com/en-us/library/aa363858(v=vs.85).aspx
According to the API document, GetModuleFileName is the preferred way to
retrieve the filename of the current process. So we shouldn't try
GetModuleFileName'Ex' first.
Previously system_rcpath_win32() happened to return unicode paths due to
GetModuleFileNameEx (issue2480). This problem is fixed as GetModuleFileName
never return unicode.
The Linux CIFS kernel driver (even in 2.6.36) suffers from a hardlink
count blindness bug (lstat() returning 1 in st_nlink when it is expected
to return >1), which causes repository corruption if Mercurial running
on Linux pushes or commits to a hardlinked repository stored on a Windows
share, if that share is mounted using the CIFS driver.
This patch works around issue1866 and improves the workaround done in
65e082ae3076 to fix issue761, by teaching the opener to lazily execute a
runtime check (new function checknlink) to see if the hardlink count
reported by nlinks() can be trusted.
Since nlinks() is also known to return varying count values (1 or >1)
depending on whether the file is open or not and depending on what client
and server software combination is being used for accessing and serving
the Windows share, we deliberately open the file before calling nlinks() in
order to have a stable precondition. Trying to depend on the precondition
"file closed" would be fragile, as the file could have been opened very
easily somewhere else in the program.
The fallback was introduced by 33415b0b4e64 at the same time than
nlinks(). Apparently it only handles the case where target path
does not exist. Just raise IOError directly.
win32.nlinks() was often returning 1 instead of the correct
hardlinks count when reading from network drives. This made
commit or push to a repository on a network share to fail
breaking the hardlinks in the datastore, possibly causing
integrity errors in repositories linked locally on the remote
side.
Here is what the MSDN says about GetFileInformationByHandle():
Depending on the underlying network features of the operating
system and the type of server connected to, the
GetFileInformationByHandle function may fail, return partial
information, or full information for the given file.
In practice, we never got the correct hardlinks count when
reading from and to many combinations of Window XP, 2003, Vista
and 7, via network drives or RDP shares. It always returned 1
instead. The only setup returning an accurate links count was a
samba on Debian.
To avoid this, Mercurial now breaks the hardlinks unconditionally
when writing to a network drive.
Hiding the child process window is not strictly necessary but it avoids opening
an empty shell window when running hg serve as well as a task in the task bar.
The window is hidden after the process is already started causing a single
flicker.
This fixes the implied reliance on pywin32 and the win32 module. This
also fixes a regression in fe7c89838a64 that made Mercurial unusable
without pywin32.
The posixfile_nt class has been superseded by posixfile in osutils.c,
which works on Windows NT and above. All other systems get the regular
python file class which is assigned to posixfile in posix.py (for POSIX)
and in the pure python version of osutils.py (for Win 9x or Windows NT
in pure mode).
