This patch adds support for py3k in osutil.c. This is accomplished by including
a header file responsible for abstracting the API differences between python 2
and python 3.
listdir_stat_type is also changed in the following way: A previous call to
PyObject_HEAD_INIT is substituted to a call to PyVarObject_HEAD_INIT, which
makes the object buildable in both python 2.x and 3.x without weird warnings.
After testing on windows, some modifications were also made in the posixfile
function, as it calls PyFile_FromFile and PyFile_SetBufSize, which are gone in
py3k. In py3k the PyFile_* API is, actually a wrapper over the io module, and
code has been adapted accordingly to fit py3k.
The posixfile_nt code hits the win32 file API directly, which
essentially amounts to performing a system call for every read and
write. This is slow.
We add a C extension that lets us use a Python file object instead,
but preserve our desired POSIX-like semantics (the ability to rename
or delete a file that is being accessed).
If the C extension is not available (e.g. in a VPS environment
without a compiler), we fall back to the posixfile_nt code.
1) In posix part set error when path is too long so instead of
SystemError: error returned without exception set
it will raise
ValueError: path too long
2) In Win32 part replace generic
PyErr_SetExcFromWindowsErrWithFilename
by
PyErr_SetFromWindowsErrWithFilename
The exception returned is WinError(based on OSError) and
some rudimentary errno translation is performed from Windows error range
to errno module friendly range so errors like ENOENT can be handled via symbolic
constant and consistently between Win32 and Posix.
Use information provided by FindFile... Win32 calls
to generate stat information without lstat call per file.
rwx bits in st_mode are ignored as they are not stored in Win32 fs
and Mercurial does not use them
Unicode path / path names over _MAX_PATH are intentionally not supported.
- manually inline mode_to_kind
- remove unused alloca include
- remove fstatat and associated bits
It's not obvious that there's an advantage to using fstatat in terms
of performance. The race-avoidance properties of fstatat aren't
terribly useful to us either. So best to avoid it until we figure out
how to use it portably.
Some systems (e.g. *BSD) don't have a readdir64 function - the regular
readdir already uses 64-bit types.
On other systems (Linux, Solaris, ...), if Python was compiled with large
file support, Python.h will define _LARGEFILE_SOURCE and _FILE_OFFSET_BITS=64,
so that any call to readdir will actually be a call to readdir64. If Python
was not compiled with large file support, we probably don't want to define
these macros to avoid ABI problems.
