php-src/Zend/zend_virtual_cwd.c

1923 lines
47 KiB
C
Raw Normal View History

/*
+----------------------------------------------------------------------+
2014-09-19 16:33:14 +00:00
| PHP Version 7 |
+----------------------------------------------------------------------+
2017-01-02 15:30:12 +00:00
| Copyright (c) 1997-2017 The PHP Group |
+----------------------------------------------------------------------+
2006-01-01 12:51:34 +00:00
| This source file is subject to version 3.01 of the PHP license, |
| that is bundled with this package in the file LICENSE, and is |
| available through the world-wide-web at the following url: |
2006-01-01 12:51:34 +00:00
| http://www.php.net/license/3_01.txt |
| If you did not receive a copy of the PHP license and are unable to |
| obtain it through the world-wide-web, please send a note to |
| license@php.net so we can mail you a copy immediately. |
+----------------------------------------------------------------------+
| Authors: Andi Gutmans <andi@zend.com> |
| Sascha Schumann <sascha@schumann.cx> |
2010-09-01 09:49:53 +00:00
| Pierre Joye <pierre@php.net> |
+----------------------------------------------------------------------+
*/
/* $Id$ */
#include <sys/types.h>
#include <sys/stat.h>
#include <string.h>
#include <stdio.h>
#include <limits.h>
#include <errno.h>
#include <stdlib.h>
#include <fcntl.h>
2004-10-06 23:56:29 +00:00
#include <time.h>
#include "zend.h"
#include "zend_virtual_cwd.h"
2000-09-03 18:47:35 +00:00
#ifdef ZEND_WIN32
2000-09-03 18:47:35 +00:00
#include <io.h>
2001-04-27 16:41:53 +00:00
#include "tsrm_win32.h"
# ifndef IO_REPARSE_TAG_SYMLINK
# define IO_REPARSE_TAG_SYMLINK 0xA000000C
# endif
# ifndef IO_REPARSE_TAG_DEDUP
# define IO_REPARSE_TAG_DEDUP 0x80000013
# endif
# ifndef VOLUME_NAME_NT
# define VOLUME_NAME_NT 0x2
# endif
# ifndef VOLUME_NAME_DOS
# define VOLUME_NAME_DOS 0x0
# endif
#endif
#ifndef HAVE_REALPATH
#define realpath(x,y) strcpy(y,x)
#endif
#define VIRTUAL_CWD_DEBUG 0
#include "TSRM.h"
/* Only need mutex for popen() in Windows because it doesn't chdir() on UNIX */
#if defined(ZEND_WIN32) && defined(ZTS)
MUTEX_T cwd_mutex;
#endif
#ifdef ZTS
ts_rsrc_id cwd_globals_id;
#else
virtual_cwd_globals cwd_globals;
#endif
cwd_state main_cwd_state; /* True global */
#ifndef ZEND_WIN32
#include <unistd.h>
#else
#include <direct.h>
#endif
#define CWD_STATE_COPY(d, s) \
(d)->cwd_length = (s)->cwd_length; \
(d)->cwd = (char *) emalloc((s)->cwd_length+1); \
memcpy((d)->cwd, (s)->cwd, (s)->cwd_length+1);
#define CWD_STATE_FREE(s) \
efree((s)->cwd); \
(s)->cwd_length = 0;
2010-09-10 14:02:19 +00:00
#ifdef ZEND_WIN32
# define CWD_STATE_FREE_ERR(state) do { \
DWORD last_error = GetLastError(); \
CWD_STATE_FREE(state); \
SetLastError(last_error); \
} while (0)
#else
# define CWD_STATE_FREE_ERR(state) CWD_STATE_FREE(state)
#endif
#ifdef ZEND_WIN32
#ifdef CTL_CODE
#undef CTL_CODE
#endif
#define CTL_CODE(DeviceType,Function,Method,Access) (((DeviceType) << 16) | ((Access) << 14) | ((Function) << 2) | (Method))
#define FILE_DEVICE_FILE_SYSTEM 0x00000009
#define METHOD_BUFFERED 0
#define FILE_ANY_ACCESS 0
#define FSCTL_GET_REPARSE_POINT CTL_CODE(FILE_DEVICE_FILE_SYSTEM, 42, METHOD_BUFFERED, FILE_ANY_ACCESS)
#define MAXIMUM_REPARSE_DATA_BUFFER_SIZE ( 16 * 1024 )
typedef struct {
2014-09-22 06:53:15 +00:00
unsigned long ReparseTag;
unsigned short ReparseDataLength;
unsigned short Reserved;
union {
struct {
unsigned short SubstituteNameOffset;
unsigned short SubstituteNameLength;
unsigned short PrintNameOffset;
unsigned short PrintNameLength;
2014-09-22 06:53:15 +00:00
unsigned long Flags;
wchar_t ReparseTarget[1];
} SymbolicLinkReparseBuffer;
struct {
unsigned short SubstituteNameOffset;
unsigned short SubstituteNameLength;
unsigned short PrintNameOffset;
unsigned short PrintNameLength;
wchar_t ReparseTarget[1];
} MountPointReparseBuffer;
struct {
unsigned char ReparseTarget[1];
} GenericReparseBuffer;
};
2014-09-22 06:53:15 +00:00
} REPARSE_DATA_BUFFER, *PREPARSE_DATA_BUFFER;
#define SECS_BETWEEN_EPOCHS (__int64)11644473600
#define SECS_TO_100NS (__int64)10000000
static inline time_t FileTimeToUnixTime(const FILETIME *FileTime)
{
__int64 UnixTime;
long *nsec = NULL;
SYSTEMTIME SystemTime;
FileTimeToSystemTime(FileTime, &SystemTime);
UnixTime = ((__int64)FileTime->dwHighDateTime << 32) +
FileTime->dwLowDateTime;
UnixTime -= (SECS_BETWEEN_EPOCHS * SECS_TO_100NS);
if (nsec) {
*nsec = (UnixTime % SECS_TO_100NS) * (__int64)100;
}
UnixTime /= SECS_TO_100NS; /* now convert to seconds */
if ((time_t)UnixTime != UnixTime) {
UnixTime = 0;
}
return (time_t)UnixTime;
}
2010-09-10 14:01:44 +00:00
CWD_API int php_sys_readlink(const char *link, char *target, size_t target_len){ /* {{{ */
HANDLE hFile;
Fixed the UTF-8 and long path support in the streams on Windows. Since long the default PHP charset is UTF-8, however the Windows part is out of step with this important point. The current implementation in PHP doesn't technically permit to handle UTF-8 filepath and several other things. Till now, only the ANSI compatible APIs are being used. Here is more about it https://msdn.microsoft.com/en-us/library/windows/desktop/dd317752%28v=vs.85%29.aspx The patch fixes not only issues with multibyte filenames under incompatible codepages, but indirectly also issues with some other multibyte encodings like BIG5, Shift-JIS, etc. by providing a clean way to access filenames in UTF-8. Below is a small list of issues from the bug tracker, that are getting fixed: https://bugs.php.net/63401 https://bugs.php.net/41199 https://bugs.php.net/50203 https://bugs.php.net/71509 https://bugs.php.net/64699 https://bugs.php.net/64506 https://bugs.php.net/30195 https://bugs.php.net/65358 https://bugs.php.net/61315 https://bugs.php.net/70943 https://bugs.php.net/70903 https://bugs.php.net/63593 https://bugs.php.net/54977 https://bugs.php.net/54028 https://bugs.php.net/43148 https://bugs.php.net/30730 https://bugs.php.net/33350 https://bugs.php.net/35300 https://bugs.php.net/46990 https://bugs.php.net/61309 https://bugs.php.net/69333 https://bugs.php.net/45517 https://bugs.php.net/70551 https://bugs.php.net/50197 https://bugs.php.net/72200 https://bugs.php.net/37672 Yet more related tickets can for sure be found - on bugs.php.net, Stackoverflow and Github. Some of the bugs are pretty recent, some descend to early 2000th, but the user comments in there last even till today. Just for example, bug #30195 was opened in 2004, the latest comment in there was made in 2014. It is certain, that these bugs descend not only to pure PHP use cases, but get also redirected from the popular PHP based projects. Given the modern systems (and those supported by PHP) are always based on NTFS, there is no excuse to keep these issues unresolved. The internalization approach on Windows is in many ways different from UNIX and Linux, while it supports and is based on Unicode. It depends on the current system code page, APIs used and exact kind how the binary was compiled The locale doesn't affect the way Unicode or ANSI API work. PHP in particular is being compiled without _UNICODE defined and this is conditioned by the way we handle strings. Here is more about it https://msdn.microsoft.com/en-us/library/tsbaswba.aspx However, with any system code page ANSI functions automatically convert paths to UTF-16. Paths in some encodings incompatible with the current system code page, won't work correctly with ANSI APIs. PHP till now only uses the ANSI Windows APIs. For example, on a system with the current code page 1252, the paths in cp1252 are supported and transparently converted to UTF-16 by the ANSI functions. Once one wants to handle a filepath encoded with cp932 on that particular system, an ANSI or a POSIX compatible function used in PHP will produce an erroneous result. When trying to convert that cp932 path to UTF-8 and passing to the ANSI functions, an ANSI function would likely interpret the UTF-8 string as some string in the current code page and create a filepath that represents every single byte of the UTF-8 string. These behaviors are not only broken but also disregard the documented INI settings. This patch solves the issies with the multibyte paths on Windows by intelligently enforcing the usage of the Unicode aware APIs. For functions expect Unicode (fe CreateFileW, FindFirstFileW, etc.), arguments will be converted to UTF-16 wide chars. For functions returning Unicode aware data (fe GetCurrentDirectoryW, etc.), resulting wide string is converted back to char's depending on the current PHP charset settings, either to the current ANSI codepage (this is the behavior prior to this patch) or to UTF-8 (the default behavior). In a particular case, users might have to explicitly set internal_encoding or default_charset, if filenames in ANSI codepage are necessary. Current tests show no regressions and witness that this will be an exotic case, the current default UTF-8 encoding is compatible with any supported system. The dependency libraries are long switching to Unicode APIs, so some tests were also added for extensions not directly related to streams. At large, the patch brings over 150 related tests into the core. Those target and was run on various environments with European, Asian, etc. codepages. General PHP frameworks was tested and showed no regressions. The impact on the current C code base is low, the most places affected are the Windows only places in the three files tsrm_win32.c, zend_virtual_cwd.c and plain_wrapper.c. The actual implementation of the most of the wide char supporting functionality is in win32/ioutil.* and win32/codepage.*, several low level functionsare extended in place to avoid reimplementation for now. No performance impact was sighted. As previously mentioned, the ANSI APIs used prior the patch perform Unicode conversions internally. Using the Unicode APIs directly while doing custom conversions just retains the status quo. The ways to optimize it are open (fe. by implementing caching for the strings converted to wide variants). The long path implementation is user transparent. If a path exceeds the length of _MAX_PATH, it'll be automatically prefixed with \\?\. The MAXPATHLEN is set to 2048 bytes. Appreciation to Pierre Joye, Matt Ficken, @algo13 and others for tips, ideas and testing. Thanks.
2016-06-20 07:32:19 +00:00
wchar_t *linkw = php_win32_ioutil_any_to_w(link), targetw[MAXPATHLEN];
size_t ret_len, targetw_len, offset = 0;
char *ret;
2010-09-10 14:01:44 +00:00
Fixed the UTF-8 and long path support in the streams on Windows. Since long the default PHP charset is UTF-8, however the Windows part is out of step with this important point. The current implementation in PHP doesn't technically permit to handle UTF-8 filepath and several other things. Till now, only the ANSI compatible APIs are being used. Here is more about it https://msdn.microsoft.com/en-us/library/windows/desktop/dd317752%28v=vs.85%29.aspx The patch fixes not only issues with multibyte filenames under incompatible codepages, but indirectly also issues with some other multibyte encodings like BIG5, Shift-JIS, etc. by providing a clean way to access filenames in UTF-8. Below is a small list of issues from the bug tracker, that are getting fixed: https://bugs.php.net/63401 https://bugs.php.net/41199 https://bugs.php.net/50203 https://bugs.php.net/71509 https://bugs.php.net/64699 https://bugs.php.net/64506 https://bugs.php.net/30195 https://bugs.php.net/65358 https://bugs.php.net/61315 https://bugs.php.net/70943 https://bugs.php.net/70903 https://bugs.php.net/63593 https://bugs.php.net/54977 https://bugs.php.net/54028 https://bugs.php.net/43148 https://bugs.php.net/30730 https://bugs.php.net/33350 https://bugs.php.net/35300 https://bugs.php.net/46990 https://bugs.php.net/61309 https://bugs.php.net/69333 https://bugs.php.net/45517 https://bugs.php.net/70551 https://bugs.php.net/50197 https://bugs.php.net/72200 https://bugs.php.net/37672 Yet more related tickets can for sure be found - on bugs.php.net, Stackoverflow and Github. Some of the bugs are pretty recent, some descend to early 2000th, but the user comments in there last even till today. Just for example, bug #30195 was opened in 2004, the latest comment in there was made in 2014. It is certain, that these bugs descend not only to pure PHP use cases, but get also redirected from the popular PHP based projects. Given the modern systems (and those supported by PHP) are always based on NTFS, there is no excuse to keep these issues unresolved. The internalization approach on Windows is in many ways different from UNIX and Linux, while it supports and is based on Unicode. It depends on the current system code page, APIs used and exact kind how the binary was compiled The locale doesn't affect the way Unicode or ANSI API work. PHP in particular is being compiled without _UNICODE defined and this is conditioned by the way we handle strings. Here is more about it https://msdn.microsoft.com/en-us/library/tsbaswba.aspx However, with any system code page ANSI functions automatically convert paths to UTF-16. Paths in some encodings incompatible with the current system code page, won't work correctly with ANSI APIs. PHP till now only uses the ANSI Windows APIs. For example, on a system with the current code page 1252, the paths in cp1252 are supported and transparently converted to UTF-16 by the ANSI functions. Once one wants to handle a filepath encoded with cp932 on that particular system, an ANSI or a POSIX compatible function used in PHP will produce an erroneous result. When trying to convert that cp932 path to UTF-8 and passing to the ANSI functions, an ANSI function would likely interpret the UTF-8 string as some string in the current code page and create a filepath that represents every single byte of the UTF-8 string. These behaviors are not only broken but also disregard the documented INI settings. This patch solves the issies with the multibyte paths on Windows by intelligently enforcing the usage of the Unicode aware APIs. For functions expect Unicode (fe CreateFileW, FindFirstFileW, etc.), arguments will be converted to UTF-16 wide chars. For functions returning Unicode aware data (fe GetCurrentDirectoryW, etc.), resulting wide string is converted back to char's depending on the current PHP charset settings, either to the current ANSI codepage (this is the behavior prior to this patch) or to UTF-8 (the default behavior). In a particular case, users might have to explicitly set internal_encoding or default_charset, if filenames in ANSI codepage are necessary. Current tests show no regressions and witness that this will be an exotic case, the current default UTF-8 encoding is compatible with any supported system. The dependency libraries are long switching to Unicode APIs, so some tests were also added for extensions not directly related to streams. At large, the patch brings over 150 related tests into the core. Those target and was run on various environments with European, Asian, etc. codepages. General PHP frameworks was tested and showed no regressions. The impact on the current C code base is low, the most places affected are the Windows only places in the three files tsrm_win32.c, zend_virtual_cwd.c and plain_wrapper.c. The actual implementation of the most of the wide char supporting functionality is in win32/ioutil.* and win32/codepage.*, several low level functionsare extended in place to avoid reimplementation for now. No performance impact was sighted. As previously mentioned, the ANSI APIs used prior the patch perform Unicode conversions internally. Using the Unicode APIs directly while doing custom conversions just retains the status quo. The ways to optimize it are open (fe. by implementing caching for the strings converted to wide variants). The long path implementation is user transparent. If a path exceeds the length of _MAX_PATH, it'll be automatically prefixed with \\?\. The MAXPATHLEN is set to 2048 bytes. Appreciation to Pierre Joye, Matt Ficken, @algo13 and others for tips, ideas and testing. Thanks.
2016-06-20 07:32:19 +00:00
if (!linkw) {
return -1;
}
Fixed the UTF-8 and long path support in the streams on Windows. Since long the default PHP charset is UTF-8, however the Windows part is out of step with this important point. The current implementation in PHP doesn't technically permit to handle UTF-8 filepath and several other things. Till now, only the ANSI compatible APIs are being used. Here is more about it https://msdn.microsoft.com/en-us/library/windows/desktop/dd317752%28v=vs.85%29.aspx The patch fixes not only issues with multibyte filenames under incompatible codepages, but indirectly also issues with some other multibyte encodings like BIG5, Shift-JIS, etc. by providing a clean way to access filenames in UTF-8. Below is a small list of issues from the bug tracker, that are getting fixed: https://bugs.php.net/63401 https://bugs.php.net/41199 https://bugs.php.net/50203 https://bugs.php.net/71509 https://bugs.php.net/64699 https://bugs.php.net/64506 https://bugs.php.net/30195 https://bugs.php.net/65358 https://bugs.php.net/61315 https://bugs.php.net/70943 https://bugs.php.net/70903 https://bugs.php.net/63593 https://bugs.php.net/54977 https://bugs.php.net/54028 https://bugs.php.net/43148 https://bugs.php.net/30730 https://bugs.php.net/33350 https://bugs.php.net/35300 https://bugs.php.net/46990 https://bugs.php.net/61309 https://bugs.php.net/69333 https://bugs.php.net/45517 https://bugs.php.net/70551 https://bugs.php.net/50197 https://bugs.php.net/72200 https://bugs.php.net/37672 Yet more related tickets can for sure be found - on bugs.php.net, Stackoverflow and Github. Some of the bugs are pretty recent, some descend to early 2000th, but the user comments in there last even till today. Just for example, bug #30195 was opened in 2004, the latest comment in there was made in 2014. It is certain, that these bugs descend not only to pure PHP use cases, but get also redirected from the popular PHP based projects. Given the modern systems (and those supported by PHP) are always based on NTFS, there is no excuse to keep these issues unresolved. The internalization approach on Windows is in many ways different from UNIX and Linux, while it supports and is based on Unicode. It depends on the current system code page, APIs used and exact kind how the binary was compiled The locale doesn't affect the way Unicode or ANSI API work. PHP in particular is being compiled without _UNICODE defined and this is conditioned by the way we handle strings. Here is more about it https://msdn.microsoft.com/en-us/library/tsbaswba.aspx However, with any system code page ANSI functions automatically convert paths to UTF-16. Paths in some encodings incompatible with the current system code page, won't work correctly with ANSI APIs. PHP till now only uses the ANSI Windows APIs. For example, on a system with the current code page 1252, the paths in cp1252 are supported and transparently converted to UTF-16 by the ANSI functions. Once one wants to handle a filepath encoded with cp932 on that particular system, an ANSI or a POSIX compatible function used in PHP will produce an erroneous result. When trying to convert that cp932 path to UTF-8 and passing to the ANSI functions, an ANSI function would likely interpret the UTF-8 string as some string in the current code page and create a filepath that represents every single byte of the UTF-8 string. These behaviors are not only broken but also disregard the documented INI settings. This patch solves the issies with the multibyte paths on Windows by intelligently enforcing the usage of the Unicode aware APIs. For functions expect Unicode (fe CreateFileW, FindFirstFileW, etc.), arguments will be converted to UTF-16 wide chars. For functions returning Unicode aware data (fe GetCurrentDirectoryW, etc.), resulting wide string is converted back to char's depending on the current PHP charset settings, either to the current ANSI codepage (this is the behavior prior to this patch) or to UTF-8 (the default behavior). In a particular case, users might have to explicitly set internal_encoding or default_charset, if filenames in ANSI codepage are necessary. Current tests show no regressions and witness that this will be an exotic case, the current default UTF-8 encoding is compatible with any supported system. The dependency libraries are long switching to Unicode APIs, so some tests were also added for extensions not directly related to streams. At large, the patch brings over 150 related tests into the core. Those target and was run on various environments with European, Asian, etc. codepages. General PHP frameworks was tested and showed no regressions. The impact on the current C code base is low, the most places affected are the Windows only places in the three files tsrm_win32.c, zend_virtual_cwd.c and plain_wrapper.c. The actual implementation of the most of the wide char supporting functionality is in win32/ioutil.* and win32/codepage.*, several low level functionsare extended in place to avoid reimplementation for now. No performance impact was sighted. As previously mentioned, the ANSI APIs used prior the patch perform Unicode conversions internally. Using the Unicode APIs directly while doing custom conversions just retains the status quo. The ways to optimize it are open (fe. by implementing caching for the strings converted to wide variants). The long path implementation is user transparent. If a path exceeds the length of _MAX_PATH, it'll be automatically prefixed with \\?\. The MAXPATHLEN is set to 2048 bytes. Appreciation to Pierre Joye, Matt Ficken, @algo13 and others for tips, ideas and testing. Thanks.
2016-06-20 07:32:19 +00:00
if (!target_len) {
free(linkw);
2010-09-10 14:01:44 +00:00
return -1;
}
Fixed the UTF-8 and long path support in the streams on Windows. Since long the default PHP charset is UTF-8, however the Windows part is out of step with this important point. The current implementation in PHP doesn't technically permit to handle UTF-8 filepath and several other things. Till now, only the ANSI compatible APIs are being used. Here is more about it https://msdn.microsoft.com/en-us/library/windows/desktop/dd317752%28v=vs.85%29.aspx The patch fixes not only issues with multibyte filenames under incompatible codepages, but indirectly also issues with some other multibyte encodings like BIG5, Shift-JIS, etc. by providing a clean way to access filenames in UTF-8. Below is a small list of issues from the bug tracker, that are getting fixed: https://bugs.php.net/63401 https://bugs.php.net/41199 https://bugs.php.net/50203 https://bugs.php.net/71509 https://bugs.php.net/64699 https://bugs.php.net/64506 https://bugs.php.net/30195 https://bugs.php.net/65358 https://bugs.php.net/61315 https://bugs.php.net/70943 https://bugs.php.net/70903 https://bugs.php.net/63593 https://bugs.php.net/54977 https://bugs.php.net/54028 https://bugs.php.net/43148 https://bugs.php.net/30730 https://bugs.php.net/33350 https://bugs.php.net/35300 https://bugs.php.net/46990 https://bugs.php.net/61309 https://bugs.php.net/69333 https://bugs.php.net/45517 https://bugs.php.net/70551 https://bugs.php.net/50197 https://bugs.php.net/72200 https://bugs.php.net/37672 Yet more related tickets can for sure be found - on bugs.php.net, Stackoverflow and Github. Some of the bugs are pretty recent, some descend to early 2000th, but the user comments in there last even till today. Just for example, bug #30195 was opened in 2004, the latest comment in there was made in 2014. It is certain, that these bugs descend not only to pure PHP use cases, but get also redirected from the popular PHP based projects. Given the modern systems (and those supported by PHP) are always based on NTFS, there is no excuse to keep these issues unresolved. The internalization approach on Windows is in many ways different from UNIX and Linux, while it supports and is based on Unicode. It depends on the current system code page, APIs used and exact kind how the binary was compiled The locale doesn't affect the way Unicode or ANSI API work. PHP in particular is being compiled without _UNICODE defined and this is conditioned by the way we handle strings. Here is more about it https://msdn.microsoft.com/en-us/library/tsbaswba.aspx However, with any system code page ANSI functions automatically convert paths to UTF-16. Paths in some encodings incompatible with the current system code page, won't work correctly with ANSI APIs. PHP till now only uses the ANSI Windows APIs. For example, on a system with the current code page 1252, the paths in cp1252 are supported and transparently converted to UTF-16 by the ANSI functions. Once one wants to handle a filepath encoded with cp932 on that particular system, an ANSI or a POSIX compatible function used in PHP will produce an erroneous result. When trying to convert that cp932 path to UTF-8 and passing to the ANSI functions, an ANSI function would likely interpret the UTF-8 string as some string in the current code page and create a filepath that represents every single byte of the UTF-8 string. These behaviors are not only broken but also disregard the documented INI settings. This patch solves the issies with the multibyte paths on Windows by intelligently enforcing the usage of the Unicode aware APIs. For functions expect Unicode (fe CreateFileW, FindFirstFileW, etc.), arguments will be converted to UTF-16 wide chars. For functions returning Unicode aware data (fe GetCurrentDirectoryW, etc.), resulting wide string is converted back to char's depending on the current PHP charset settings, either to the current ANSI codepage (this is the behavior prior to this patch) or to UTF-8 (the default behavior). In a particular case, users might have to explicitly set internal_encoding or default_charset, if filenames in ANSI codepage are necessary. Current tests show no regressions and witness that this will be an exotic case, the current default UTF-8 encoding is compatible with any supported system. The dependency libraries are long switching to Unicode APIs, so some tests were also added for extensions not directly related to streams. At large, the patch brings over 150 related tests into the core. Those target and was run on various environments with European, Asian, etc. codepages. General PHP frameworks was tested and showed no regressions. The impact on the current C code base is low, the most places affected are the Windows only places in the three files tsrm_win32.c, zend_virtual_cwd.c and plain_wrapper.c. The actual implementation of the most of the wide char supporting functionality is in win32/ioutil.* and win32/codepage.*, several low level functionsare extended in place to avoid reimplementation for now. No performance impact was sighted. As previously mentioned, the ANSI APIs used prior the patch perform Unicode conversions internally. Using the Unicode APIs directly while doing custom conversions just retains the status quo. The ways to optimize it are open (fe. by implementing caching for the strings converted to wide variants). The long path implementation is user transparent. If a path exceeds the length of _MAX_PATH, it'll be automatically prefixed with \\?\. The MAXPATHLEN is set to 2048 bytes. Appreciation to Pierre Joye, Matt Ficken, @algo13 and others for tips, ideas and testing. Thanks.
2016-06-20 07:32:19 +00:00
hFile = CreateFileW(linkw, // file to open
2010-09-10 14:01:44 +00:00
GENERIC_READ, // open for reading
FILE_SHARE_READ, // share for reading
NULL, // default security
OPEN_EXISTING, // existing file only
FILE_FLAG_BACKUP_SEMANTICS, // normal file
NULL); // no attr. template
if( hFile == INVALID_HANDLE_VALUE) {
Fixed the UTF-8 and long path support in the streams on Windows. Since long the default PHP charset is UTF-8, however the Windows part is out of step with this important point. The current implementation in PHP doesn't technically permit to handle UTF-8 filepath and several other things. Till now, only the ANSI compatible APIs are being used. Here is more about it https://msdn.microsoft.com/en-us/library/windows/desktop/dd317752%28v=vs.85%29.aspx The patch fixes not only issues with multibyte filenames under incompatible codepages, but indirectly also issues with some other multibyte encodings like BIG5, Shift-JIS, etc. by providing a clean way to access filenames in UTF-8. Below is a small list of issues from the bug tracker, that are getting fixed: https://bugs.php.net/63401 https://bugs.php.net/41199 https://bugs.php.net/50203 https://bugs.php.net/71509 https://bugs.php.net/64699 https://bugs.php.net/64506 https://bugs.php.net/30195 https://bugs.php.net/65358 https://bugs.php.net/61315 https://bugs.php.net/70943 https://bugs.php.net/70903 https://bugs.php.net/63593 https://bugs.php.net/54977 https://bugs.php.net/54028 https://bugs.php.net/43148 https://bugs.php.net/30730 https://bugs.php.net/33350 https://bugs.php.net/35300 https://bugs.php.net/46990 https://bugs.php.net/61309 https://bugs.php.net/69333 https://bugs.php.net/45517 https://bugs.php.net/70551 https://bugs.php.net/50197 https://bugs.php.net/72200 https://bugs.php.net/37672 Yet more related tickets can for sure be found - on bugs.php.net, Stackoverflow and Github. Some of the bugs are pretty recent, some descend to early 2000th, but the user comments in there last even till today. Just for example, bug #30195 was opened in 2004, the latest comment in there was made in 2014. It is certain, that these bugs descend not only to pure PHP use cases, but get also redirected from the popular PHP based projects. Given the modern systems (and those supported by PHP) are always based on NTFS, there is no excuse to keep these issues unresolved. The internalization approach on Windows is in many ways different from UNIX and Linux, while it supports and is based on Unicode. It depends on the current system code page, APIs used and exact kind how the binary was compiled The locale doesn't affect the way Unicode or ANSI API work. PHP in particular is being compiled without _UNICODE defined and this is conditioned by the way we handle strings. Here is more about it https://msdn.microsoft.com/en-us/library/tsbaswba.aspx However, with any system code page ANSI functions automatically convert paths to UTF-16. Paths in some encodings incompatible with the current system code page, won't work correctly with ANSI APIs. PHP till now only uses the ANSI Windows APIs. For example, on a system with the current code page 1252, the paths in cp1252 are supported and transparently converted to UTF-16 by the ANSI functions. Once one wants to handle a filepath encoded with cp932 on that particular system, an ANSI or a POSIX compatible function used in PHP will produce an erroneous result. When trying to convert that cp932 path to UTF-8 and passing to the ANSI functions, an ANSI function would likely interpret the UTF-8 string as some string in the current code page and create a filepath that represents every single byte of the UTF-8 string. These behaviors are not only broken but also disregard the documented INI settings. This patch solves the issies with the multibyte paths on Windows by intelligently enforcing the usage of the Unicode aware APIs. For functions expect Unicode (fe CreateFileW, FindFirstFileW, etc.), arguments will be converted to UTF-16 wide chars. For functions returning Unicode aware data (fe GetCurrentDirectoryW, etc.), resulting wide string is converted back to char's depending on the current PHP charset settings, either to the current ANSI codepage (this is the behavior prior to this patch) or to UTF-8 (the default behavior). In a particular case, users might have to explicitly set internal_encoding or default_charset, if filenames in ANSI codepage are necessary. Current tests show no regressions and witness that this will be an exotic case, the current default UTF-8 encoding is compatible with any supported system. The dependency libraries are long switching to Unicode APIs, so some tests were also added for extensions not directly related to streams. At large, the patch brings over 150 related tests into the core. Those target and was run on various environments with European, Asian, etc. codepages. General PHP frameworks was tested and showed no regressions. The impact on the current C code base is low, the most places affected are the Windows only places in the three files tsrm_win32.c, zend_virtual_cwd.c and plain_wrapper.c. The actual implementation of the most of the wide char supporting functionality is in win32/ioutil.* and win32/codepage.*, several low level functionsare extended in place to avoid reimplementation for now. No performance impact was sighted. As previously mentioned, the ANSI APIs used prior the patch perform Unicode conversions internally. Using the Unicode APIs directly while doing custom conversions just retains the status quo. The ways to optimize it are open (fe. by implementing caching for the strings converted to wide variants). The long path implementation is user transparent. If a path exceeds the length of _MAX_PATH, it'll be automatically prefixed with \\?\. The MAXPATHLEN is set to 2048 bytes. Appreciation to Pierre Joye, Matt Ficken, @algo13 and others for tips, ideas and testing. Thanks.
2016-06-20 07:32:19 +00:00
free(linkw);
return -1;
2010-09-10 14:01:44 +00:00
}
/* Despite MSDN has documented it won't to, the length returned by
GetFinalPathNameByHandleA includes the length of the
null terminator. This behavior is at least reproducible
with VS2012 and earlier, and seems not to be fixed till
now. Thus, correcting target_len so it's suddenly don't
overflown. */
targetw_len = GetFinalPathNameByHandleW(hFile, targetw, MAXPATHLEN, VOLUME_NAME_DOS);
if(targetw_len >= target_len || targetw_len >= MAXPATHLEN || targetw_len == 0) {
Fixed the UTF-8 and long path support in the streams on Windows. Since long the default PHP charset is UTF-8, however the Windows part is out of step with this important point. The current implementation in PHP doesn't technically permit to handle UTF-8 filepath and several other things. Till now, only the ANSI compatible APIs are being used. Here is more about it https://msdn.microsoft.com/en-us/library/windows/desktop/dd317752%28v=vs.85%29.aspx The patch fixes not only issues with multibyte filenames under incompatible codepages, but indirectly also issues with some other multibyte encodings like BIG5, Shift-JIS, etc. by providing a clean way to access filenames in UTF-8. Below is a small list of issues from the bug tracker, that are getting fixed: https://bugs.php.net/63401 https://bugs.php.net/41199 https://bugs.php.net/50203 https://bugs.php.net/71509 https://bugs.php.net/64699 https://bugs.php.net/64506 https://bugs.php.net/30195 https://bugs.php.net/65358 https://bugs.php.net/61315 https://bugs.php.net/70943 https://bugs.php.net/70903 https://bugs.php.net/63593 https://bugs.php.net/54977 https://bugs.php.net/54028 https://bugs.php.net/43148 https://bugs.php.net/30730 https://bugs.php.net/33350 https://bugs.php.net/35300 https://bugs.php.net/46990 https://bugs.php.net/61309 https://bugs.php.net/69333 https://bugs.php.net/45517 https://bugs.php.net/70551 https://bugs.php.net/50197 https://bugs.php.net/72200 https://bugs.php.net/37672 Yet more related tickets can for sure be found - on bugs.php.net, Stackoverflow and Github. Some of the bugs are pretty recent, some descend to early 2000th, but the user comments in there last even till today. Just for example, bug #30195 was opened in 2004, the latest comment in there was made in 2014. It is certain, that these bugs descend not only to pure PHP use cases, but get also redirected from the popular PHP based projects. Given the modern systems (and those supported by PHP) are always based on NTFS, there is no excuse to keep these issues unresolved. The internalization approach on Windows is in many ways different from UNIX and Linux, while it supports and is based on Unicode. It depends on the current system code page, APIs used and exact kind how the binary was compiled The locale doesn't affect the way Unicode or ANSI API work. PHP in particular is being compiled without _UNICODE defined and this is conditioned by the way we handle strings. Here is more about it https://msdn.microsoft.com/en-us/library/tsbaswba.aspx However, with any system code page ANSI functions automatically convert paths to UTF-16. Paths in some encodings incompatible with the current system code page, won't work correctly with ANSI APIs. PHP till now only uses the ANSI Windows APIs. For example, on a system with the current code page 1252, the paths in cp1252 are supported and transparently converted to UTF-16 by the ANSI functions. Once one wants to handle a filepath encoded with cp932 on that particular system, an ANSI or a POSIX compatible function used in PHP will produce an erroneous result. When trying to convert that cp932 path to UTF-8 and passing to the ANSI functions, an ANSI function would likely interpret the UTF-8 string as some string in the current code page and create a filepath that represents every single byte of the UTF-8 string. These behaviors are not only broken but also disregard the documented INI settings. This patch solves the issies with the multibyte paths on Windows by intelligently enforcing the usage of the Unicode aware APIs. For functions expect Unicode (fe CreateFileW, FindFirstFileW, etc.), arguments will be converted to UTF-16 wide chars. For functions returning Unicode aware data (fe GetCurrentDirectoryW, etc.), resulting wide string is converted back to char's depending on the current PHP charset settings, either to the current ANSI codepage (this is the behavior prior to this patch) or to UTF-8 (the default behavior). In a particular case, users might have to explicitly set internal_encoding or default_charset, if filenames in ANSI codepage are necessary. Current tests show no regressions and witness that this will be an exotic case, the current default UTF-8 encoding is compatible with any supported system. The dependency libraries are long switching to Unicode APIs, so some tests were also added for extensions not directly related to streams. At large, the patch brings over 150 related tests into the core. Those target and was run on various environments with European, Asian, etc. codepages. General PHP frameworks was tested and showed no regressions. The impact on the current C code base is low, the most places affected are the Windows only places in the three files tsrm_win32.c, zend_virtual_cwd.c and plain_wrapper.c. The actual implementation of the most of the wide char supporting functionality is in win32/ioutil.* and win32/codepage.*, several low level functionsare extended in place to avoid reimplementation for now. No performance impact was sighted. As previously mentioned, the ANSI APIs used prior the patch perform Unicode conversions internally. Using the Unicode APIs directly while doing custom conversions just retains the status quo. The ways to optimize it are open (fe. by implementing caching for the strings converted to wide variants). The long path implementation is user transparent. If a path exceeds the length of _MAX_PATH, it'll be automatically prefixed with \\?\. The MAXPATHLEN is set to 2048 bytes. Appreciation to Pierre Joye, Matt Ficken, @algo13 and others for tips, ideas and testing. Thanks.
2016-06-20 07:32:19 +00:00
free(linkw);
CloseHandle(hFile);
2010-09-10 14:01:44 +00:00
return -1;
}
if(targetw_len > 4) {
/* Skip first 4 characters if they are "\\?\" */
if(targetw[0] == L'\\' && targetw[1] == L'\\' && targetw[2] == L'?' && targetw[3] == L'\\') {
offset = 4;
/* \\?\UNC\ */
if (targetw_len > 7 && targetw[4] == L'U' && targetw[5] == L'N' && targetw[6] == L'C') {
offset += 2;
targetw[offset] = L'\\';
}
}
}
ret = php_win32_ioutil_conv_w_to_any(targetw + offset, targetw_len - offset, &ret_len);
if (!ret || ret_len >= MAXPATHLEN) {
Fixed the UTF-8 and long path support in the streams on Windows. Since long the default PHP charset is UTF-8, however the Windows part is out of step with this important point. The current implementation in PHP doesn't technically permit to handle UTF-8 filepath and several other things. Till now, only the ANSI compatible APIs are being used. Here is more about it https://msdn.microsoft.com/en-us/library/windows/desktop/dd317752%28v=vs.85%29.aspx The patch fixes not only issues with multibyte filenames under incompatible codepages, but indirectly also issues with some other multibyte encodings like BIG5, Shift-JIS, etc. by providing a clean way to access filenames in UTF-8. Below is a small list of issues from the bug tracker, that are getting fixed: https://bugs.php.net/63401 https://bugs.php.net/41199 https://bugs.php.net/50203 https://bugs.php.net/71509 https://bugs.php.net/64699 https://bugs.php.net/64506 https://bugs.php.net/30195 https://bugs.php.net/65358 https://bugs.php.net/61315 https://bugs.php.net/70943 https://bugs.php.net/70903 https://bugs.php.net/63593 https://bugs.php.net/54977 https://bugs.php.net/54028 https://bugs.php.net/43148 https://bugs.php.net/30730 https://bugs.php.net/33350 https://bugs.php.net/35300 https://bugs.php.net/46990 https://bugs.php.net/61309 https://bugs.php.net/69333 https://bugs.php.net/45517 https://bugs.php.net/70551 https://bugs.php.net/50197 https://bugs.php.net/72200 https://bugs.php.net/37672 Yet more related tickets can for sure be found - on bugs.php.net, Stackoverflow and Github. Some of the bugs are pretty recent, some descend to early 2000th, but the user comments in there last even till today. Just for example, bug #30195 was opened in 2004, the latest comment in there was made in 2014. It is certain, that these bugs descend not only to pure PHP use cases, but get also redirected from the popular PHP based projects. Given the modern systems (and those supported by PHP) are always based on NTFS, there is no excuse to keep these issues unresolved. The internalization approach on Windows is in many ways different from UNIX and Linux, while it supports and is based on Unicode. It depends on the current system code page, APIs used and exact kind how the binary was compiled The locale doesn't affect the way Unicode or ANSI API work. PHP in particular is being compiled without _UNICODE defined and this is conditioned by the way we handle strings. Here is more about it https://msdn.microsoft.com/en-us/library/tsbaswba.aspx However, with any system code page ANSI functions automatically convert paths to UTF-16. Paths in some encodings incompatible with the current system code page, won't work correctly with ANSI APIs. PHP till now only uses the ANSI Windows APIs. For example, on a system with the current code page 1252, the paths in cp1252 are supported and transparently converted to UTF-16 by the ANSI functions. Once one wants to handle a filepath encoded with cp932 on that particular system, an ANSI or a POSIX compatible function used in PHP will produce an erroneous result. When trying to convert that cp932 path to UTF-8 and passing to the ANSI functions, an ANSI function would likely interpret the UTF-8 string as some string in the current code page and create a filepath that represents every single byte of the UTF-8 string. These behaviors are not only broken but also disregard the documented INI settings. This patch solves the issies with the multibyte paths on Windows by intelligently enforcing the usage of the Unicode aware APIs. For functions expect Unicode (fe CreateFileW, FindFirstFileW, etc.), arguments will be converted to UTF-16 wide chars. For functions returning Unicode aware data (fe GetCurrentDirectoryW, etc.), resulting wide string is converted back to char's depending on the current PHP charset settings, either to the current ANSI codepage (this is the behavior prior to this patch) or to UTF-8 (the default behavior). In a particular case, users might have to explicitly set internal_encoding or default_charset, if filenames in ANSI codepage are necessary. Current tests show no regressions and witness that this will be an exotic case, the current default UTF-8 encoding is compatible with any supported system. The dependency libraries are long switching to Unicode APIs, so some tests were also added for extensions not directly related to streams. At large, the patch brings over 150 related tests into the core. Those target and was run on various environments with European, Asian, etc. codepages. General PHP frameworks was tested and showed no regressions. The impact on the current C code base is low, the most places affected are the Windows only places in the three files tsrm_win32.c, zend_virtual_cwd.c and plain_wrapper.c. The actual implementation of the most of the wide char supporting functionality is in win32/ioutil.* and win32/codepage.*, several low level functionsare extended in place to avoid reimplementation for now. No performance impact was sighted. As previously mentioned, the ANSI APIs used prior the patch perform Unicode conversions internally. Using the Unicode APIs directly while doing custom conversions just retains the status quo. The ways to optimize it are open (fe. by implementing caching for the strings converted to wide variants). The long path implementation is user transparent. If a path exceeds the length of _MAX_PATH, it'll be automatically prefixed with \\?\. The MAXPATHLEN is set to 2048 bytes. Appreciation to Pierre Joye, Matt Ficken, @algo13 and others for tips, ideas and testing. Thanks.
2016-06-20 07:32:19 +00:00
CloseHandle(hFile);
free(linkw);
2017-01-07 00:15:49 +00:00
free(ret);
Fixed the UTF-8 and long path support in the streams on Windows. Since long the default PHP charset is UTF-8, however the Windows part is out of step with this important point. The current implementation in PHP doesn't technically permit to handle UTF-8 filepath and several other things. Till now, only the ANSI compatible APIs are being used. Here is more about it https://msdn.microsoft.com/en-us/library/windows/desktop/dd317752%28v=vs.85%29.aspx The patch fixes not only issues with multibyte filenames under incompatible codepages, but indirectly also issues with some other multibyte encodings like BIG5, Shift-JIS, etc. by providing a clean way to access filenames in UTF-8. Below is a small list of issues from the bug tracker, that are getting fixed: https://bugs.php.net/63401 https://bugs.php.net/41199 https://bugs.php.net/50203 https://bugs.php.net/71509 https://bugs.php.net/64699 https://bugs.php.net/64506 https://bugs.php.net/30195 https://bugs.php.net/65358 https://bugs.php.net/61315 https://bugs.php.net/70943 https://bugs.php.net/70903 https://bugs.php.net/63593 https://bugs.php.net/54977 https://bugs.php.net/54028 https://bugs.php.net/43148 https://bugs.php.net/30730 https://bugs.php.net/33350 https://bugs.php.net/35300 https://bugs.php.net/46990 https://bugs.php.net/61309 https://bugs.php.net/69333 https://bugs.php.net/45517 https://bugs.php.net/70551 https://bugs.php.net/50197 https://bugs.php.net/72200 https://bugs.php.net/37672 Yet more related tickets can for sure be found - on bugs.php.net, Stackoverflow and Github. Some of the bugs are pretty recent, some descend to early 2000th, but the user comments in there last even till today. Just for example, bug #30195 was opened in 2004, the latest comment in there was made in 2014. It is certain, that these bugs descend not only to pure PHP use cases, but get also redirected from the popular PHP based projects. Given the modern systems (and those supported by PHP) are always based on NTFS, there is no excuse to keep these issues unresolved. The internalization approach on Windows is in many ways different from UNIX and Linux, while it supports and is based on Unicode. It depends on the current system code page, APIs used and exact kind how the binary was compiled The locale doesn't affect the way Unicode or ANSI API work. PHP in particular is being compiled without _UNICODE defined and this is conditioned by the way we handle strings. Here is more about it https://msdn.microsoft.com/en-us/library/tsbaswba.aspx However, with any system code page ANSI functions automatically convert paths to UTF-16. Paths in some encodings incompatible with the current system code page, won't work correctly with ANSI APIs. PHP till now only uses the ANSI Windows APIs. For example, on a system with the current code page 1252, the paths in cp1252 are supported and transparently converted to UTF-16 by the ANSI functions. Once one wants to handle a filepath encoded with cp932 on that particular system, an ANSI or a POSIX compatible function used in PHP will produce an erroneous result. When trying to convert that cp932 path to UTF-8 and passing to the ANSI functions, an ANSI function would likely interpret the UTF-8 string as some string in the current code page and create a filepath that represents every single byte of the UTF-8 string. These behaviors are not only broken but also disregard the documented INI settings. This patch solves the issies with the multibyte paths on Windows by intelligently enforcing the usage of the Unicode aware APIs. For functions expect Unicode (fe CreateFileW, FindFirstFileW, etc.), arguments will be converted to UTF-16 wide chars. For functions returning Unicode aware data (fe GetCurrentDirectoryW, etc.), resulting wide string is converted back to char's depending on the current PHP charset settings, either to the current ANSI codepage (this is the behavior prior to this patch) or to UTF-8 (the default behavior). In a particular case, users might have to explicitly set internal_encoding or default_charset, if filenames in ANSI codepage are necessary. Current tests show no regressions and witness that this will be an exotic case, the current default UTF-8 encoding is compatible with any supported system. The dependency libraries are long switching to Unicode APIs, so some tests were also added for extensions not directly related to streams. At large, the patch brings over 150 related tests into the core. Those target and was run on various environments with European, Asian, etc. codepages. General PHP frameworks was tested and showed no regressions. The impact on the current C code base is low, the most places affected are the Windows only places in the three files tsrm_win32.c, zend_virtual_cwd.c and plain_wrapper.c. The actual implementation of the most of the wide char supporting functionality is in win32/ioutil.* and win32/codepage.*, several low level functionsare extended in place to avoid reimplementation for now. No performance impact was sighted. As previously mentioned, the ANSI APIs used prior the patch perform Unicode conversions internally. Using the Unicode APIs directly while doing custom conversions just retains the status quo. The ways to optimize it are open (fe. by implementing caching for the strings converted to wide variants). The long path implementation is user transparent. If a path exceeds the length of _MAX_PATH, it'll be automatically prefixed with \\?\. The MAXPATHLEN is set to 2048 bytes. Appreciation to Pierre Joye, Matt Ficken, @algo13 and others for tips, ideas and testing. Thanks.
2016-06-20 07:32:19 +00:00
return -1;
}
memcpy(target, ret, ret_len + 1);
Fixed the UTF-8 and long path support in the streams on Windows. Since long the default PHP charset is UTF-8, however the Windows part is out of step with this important point. The current implementation in PHP doesn't technically permit to handle UTF-8 filepath and several other things. Till now, only the ANSI compatible APIs are being used. Here is more about it https://msdn.microsoft.com/en-us/library/windows/desktop/dd317752%28v=vs.85%29.aspx The patch fixes not only issues with multibyte filenames under incompatible codepages, but indirectly also issues with some other multibyte encodings like BIG5, Shift-JIS, etc. by providing a clean way to access filenames in UTF-8. Below is a small list of issues from the bug tracker, that are getting fixed: https://bugs.php.net/63401 https://bugs.php.net/41199 https://bugs.php.net/50203 https://bugs.php.net/71509 https://bugs.php.net/64699 https://bugs.php.net/64506 https://bugs.php.net/30195 https://bugs.php.net/65358 https://bugs.php.net/61315 https://bugs.php.net/70943 https://bugs.php.net/70903 https://bugs.php.net/63593 https://bugs.php.net/54977 https://bugs.php.net/54028 https://bugs.php.net/43148 https://bugs.php.net/30730 https://bugs.php.net/33350 https://bugs.php.net/35300 https://bugs.php.net/46990 https://bugs.php.net/61309 https://bugs.php.net/69333 https://bugs.php.net/45517 https://bugs.php.net/70551 https://bugs.php.net/50197 https://bugs.php.net/72200 https://bugs.php.net/37672 Yet more related tickets can for sure be found - on bugs.php.net, Stackoverflow and Github. Some of the bugs are pretty recent, some descend to early 2000th, but the user comments in there last even till today. Just for example, bug #30195 was opened in 2004, the latest comment in there was made in 2014. It is certain, that these bugs descend not only to pure PHP use cases, but get also redirected from the popular PHP based projects. Given the modern systems (and those supported by PHP) are always based on NTFS, there is no excuse to keep these issues unresolved. The internalization approach on Windows is in many ways different from UNIX and Linux, while it supports and is based on Unicode. It depends on the current system code page, APIs used and exact kind how the binary was compiled The locale doesn't affect the way Unicode or ANSI API work. PHP in particular is being compiled without _UNICODE defined and this is conditioned by the way we handle strings. Here is more about it https://msdn.microsoft.com/en-us/library/tsbaswba.aspx However, with any system code page ANSI functions automatically convert paths to UTF-16. Paths in some encodings incompatible with the current system code page, won't work correctly with ANSI APIs. PHP till now only uses the ANSI Windows APIs. For example, on a system with the current code page 1252, the paths in cp1252 are supported and transparently converted to UTF-16 by the ANSI functions. Once one wants to handle a filepath encoded with cp932 on that particular system, an ANSI or a POSIX compatible function used in PHP will produce an erroneous result. When trying to convert that cp932 path to UTF-8 and passing to the ANSI functions, an ANSI function would likely interpret the UTF-8 string as some string in the current code page and create a filepath that represents every single byte of the UTF-8 string. These behaviors are not only broken but also disregard the documented INI settings. This patch solves the issies with the multibyte paths on Windows by intelligently enforcing the usage of the Unicode aware APIs. For functions expect Unicode (fe CreateFileW, FindFirstFileW, etc.), arguments will be converted to UTF-16 wide chars. For functions returning Unicode aware data (fe GetCurrentDirectoryW, etc.), resulting wide string is converted back to char's depending on the current PHP charset settings, either to the current ANSI codepage (this is the behavior prior to this patch) or to UTF-8 (the default behavior). In a particular case, users might have to explicitly set internal_encoding or default_charset, if filenames in ANSI codepage are necessary. Current tests show no regressions and witness that this will be an exotic case, the current default UTF-8 encoding is compatible with any supported system. The dependency libraries are long switching to Unicode APIs, so some tests were also added for extensions not directly related to streams. At large, the patch brings over 150 related tests into the core. Those target and was run on various environments with European, Asian, etc. codepages. General PHP frameworks was tested and showed no regressions. The impact on the current C code base is low, the most places affected are the Windows only places in the three files tsrm_win32.c, zend_virtual_cwd.c and plain_wrapper.c. The actual implementation of the most of the wide char supporting functionality is in win32/ioutil.* and win32/codepage.*, several low level functionsare extended in place to avoid reimplementation for now. No performance impact was sighted. As previously mentioned, the ANSI APIs used prior the patch perform Unicode conversions internally. Using the Unicode APIs directly while doing custom conversions just retains the status quo. The ways to optimize it are open (fe. by implementing caching for the strings converted to wide variants). The long path implementation is user transparent. If a path exceeds the length of _MAX_PATH, it'll be automatically prefixed with \\?\. The MAXPATHLEN is set to 2048 bytes. Appreciation to Pierre Joye, Matt Ficken, @algo13 and others for tips, ideas and testing. Thanks.
2016-06-20 07:32:19 +00:00
2017-01-07 00:15:49 +00:00
free(ret);
2010-09-10 14:01:44 +00:00
CloseHandle(hFile);
Fixed the UTF-8 and long path support in the streams on Windows. Since long the default PHP charset is UTF-8, however the Windows part is out of step with this important point. The current implementation in PHP doesn't technically permit to handle UTF-8 filepath and several other things. Till now, only the ANSI compatible APIs are being used. Here is more about it https://msdn.microsoft.com/en-us/library/windows/desktop/dd317752%28v=vs.85%29.aspx The patch fixes not only issues with multibyte filenames under incompatible codepages, but indirectly also issues with some other multibyte encodings like BIG5, Shift-JIS, etc. by providing a clean way to access filenames in UTF-8. Below is a small list of issues from the bug tracker, that are getting fixed: https://bugs.php.net/63401 https://bugs.php.net/41199 https://bugs.php.net/50203 https://bugs.php.net/71509 https://bugs.php.net/64699 https://bugs.php.net/64506 https://bugs.php.net/30195 https://bugs.php.net/65358 https://bugs.php.net/61315 https://bugs.php.net/70943 https://bugs.php.net/70903 https://bugs.php.net/63593 https://bugs.php.net/54977 https://bugs.php.net/54028 https://bugs.php.net/43148 https://bugs.php.net/30730 https://bugs.php.net/33350 https://bugs.php.net/35300 https://bugs.php.net/46990 https://bugs.php.net/61309 https://bugs.php.net/69333 https://bugs.php.net/45517 https://bugs.php.net/70551 https://bugs.php.net/50197 https://bugs.php.net/72200 https://bugs.php.net/37672 Yet more related tickets can for sure be found - on bugs.php.net, Stackoverflow and Github. Some of the bugs are pretty recent, some descend to early 2000th, but the user comments in there last even till today. Just for example, bug #30195 was opened in 2004, the latest comment in there was made in 2014. It is certain, that these bugs descend not only to pure PHP use cases, but get also redirected from the popular PHP based projects. Given the modern systems (and those supported by PHP) are always based on NTFS, there is no excuse to keep these issues unresolved. The internalization approach on Windows is in many ways different from UNIX and Linux, while it supports and is based on Unicode. It depends on the current system code page, APIs used and exact kind how the binary was compiled The locale doesn't affect the way Unicode or ANSI API work. PHP in particular is being compiled without _UNICODE defined and this is conditioned by the way we handle strings. Here is more about it https://msdn.microsoft.com/en-us/library/tsbaswba.aspx However, with any system code page ANSI functions automatically convert paths to UTF-16. Paths in some encodings incompatible with the current system code page, won't work correctly with ANSI APIs. PHP till now only uses the ANSI Windows APIs. For example, on a system with the current code page 1252, the paths in cp1252 are supported and transparently converted to UTF-16 by the ANSI functions. Once one wants to handle a filepath encoded with cp932 on that particular system, an ANSI or a POSIX compatible function used in PHP will produce an erroneous result. When trying to convert that cp932 path to UTF-8 and passing to the ANSI functions, an ANSI function would likely interpret the UTF-8 string as some string in the current code page and create a filepath that represents every single byte of the UTF-8 string. These behaviors are not only broken but also disregard the documented INI settings. This patch solves the issies with the multibyte paths on Windows by intelligently enforcing the usage of the Unicode aware APIs. For functions expect Unicode (fe CreateFileW, FindFirstFileW, etc.), arguments will be converted to UTF-16 wide chars. For functions returning Unicode aware data (fe GetCurrentDirectoryW, etc.), resulting wide string is converted back to char's depending on the current PHP charset settings, either to the current ANSI codepage (this is the behavior prior to this patch) or to UTF-8 (the default behavior). In a particular case, users might have to explicitly set internal_encoding or default_charset, if filenames in ANSI codepage are necessary. Current tests show no regressions and witness that this will be an exotic case, the current default UTF-8 encoding is compatible with any supported system. The dependency libraries are long switching to Unicode APIs, so some tests were also added for extensions not directly related to streams. At large, the patch brings over 150 related tests into the core. Those target and was run on various environments with European, Asian, etc. codepages. General PHP frameworks was tested and showed no regressions. The impact on the current C code base is low, the most places affected are the Windows only places in the three files tsrm_win32.c, zend_virtual_cwd.c and plain_wrapper.c. The actual implementation of the most of the wide char supporting functionality is in win32/ioutil.* and win32/codepage.*, several low level functionsare extended in place to avoid reimplementation for now. No performance impact was sighted. As previously mentioned, the ANSI APIs used prior the patch perform Unicode conversions internally. Using the Unicode APIs directly while doing custom conversions just retains the status quo. The ways to optimize it are open (fe. by implementing caching for the strings converted to wide variants). The long path implementation is user transparent. If a path exceeds the length of _MAX_PATH, it'll be automatically prefixed with \\?\. The MAXPATHLEN is set to 2048 bytes. Appreciation to Pierre Joye, Matt Ficken, @algo13 and others for tips, ideas and testing. Thanks.
2016-06-20 07:32:19 +00:00
free(linkw);
2010-09-10 14:01:44 +00:00
return ret_len;
2010-09-10 14:01:44 +00:00
}
/* }}} */
CWD_API int php_sys_stat_ex(const char *path, zend_stat_t *buf, int lstat) /* {{{ */
{
WIN32_FILE_ATTRIBUTE_DATA data;
LARGE_INTEGER t;
size_t pathw_len = 0;
2016-07-30 15:30:49 +00:00
ALLOCA_FLAG(use_heap_large)
wchar_t *pathw = php_win32_ioutil_conv_any_to_w(path, PHP_WIN32_CP_IGNORE_LEN, &pathw_len);
Fixed the UTF-8 and long path support in the streams on Windows. Since long the default PHP charset is UTF-8, however the Windows part is out of step with this important point. The current implementation in PHP doesn't technically permit to handle UTF-8 filepath and several other things. Till now, only the ANSI compatible APIs are being used. Here is more about it https://msdn.microsoft.com/en-us/library/windows/desktop/dd317752%28v=vs.85%29.aspx The patch fixes not only issues with multibyte filenames under incompatible codepages, but indirectly also issues with some other multibyte encodings like BIG5, Shift-JIS, etc. by providing a clean way to access filenames in UTF-8. Below is a small list of issues from the bug tracker, that are getting fixed: https://bugs.php.net/63401 https://bugs.php.net/41199 https://bugs.php.net/50203 https://bugs.php.net/71509 https://bugs.php.net/64699 https://bugs.php.net/64506 https://bugs.php.net/30195 https://bugs.php.net/65358 https://bugs.php.net/61315 https://bugs.php.net/70943 https://bugs.php.net/70903 https://bugs.php.net/63593 https://bugs.php.net/54977 https://bugs.php.net/54028 https://bugs.php.net/43148 https://bugs.php.net/30730 https://bugs.php.net/33350 https://bugs.php.net/35300 https://bugs.php.net/46990 https://bugs.php.net/61309 https://bugs.php.net/69333 https://bugs.php.net/45517 https://bugs.php.net/70551 https://bugs.php.net/50197 https://bugs.php.net/72200 https://bugs.php.net/37672 Yet more related tickets can for sure be found - on bugs.php.net, Stackoverflow and Github. Some of the bugs are pretty recent, some descend to early 2000th, but the user comments in there last even till today. Just for example, bug #30195 was opened in 2004, the latest comment in there was made in 2014. It is certain, that these bugs descend not only to pure PHP use cases, but get also redirected from the popular PHP based projects. Given the modern systems (and those supported by PHP) are always based on NTFS, there is no excuse to keep these issues unresolved. The internalization approach on Windows is in many ways different from UNIX and Linux, while it supports and is based on Unicode. It depends on the current system code page, APIs used and exact kind how the binary was compiled The locale doesn't affect the way Unicode or ANSI API work. PHP in particular is being compiled without _UNICODE defined and this is conditioned by the way we handle strings. Here is more about it https://msdn.microsoft.com/en-us/library/tsbaswba.aspx However, with any system code page ANSI functions automatically convert paths to UTF-16. Paths in some encodings incompatible with the current system code page, won't work correctly with ANSI APIs. PHP till now only uses the ANSI Windows APIs. For example, on a system with the current code page 1252, the paths in cp1252 are supported and transparently converted to UTF-16 by the ANSI functions. Once one wants to handle a filepath encoded with cp932 on that particular system, an ANSI or a POSIX compatible function used in PHP will produce an erroneous result. When trying to convert that cp932 path to UTF-8 and passing to the ANSI functions, an ANSI function would likely interpret the UTF-8 string as some string in the current code page and create a filepath that represents every single byte of the UTF-8 string. These behaviors are not only broken but also disregard the documented INI settings. This patch solves the issies with the multibyte paths on Windows by intelligently enforcing the usage of the Unicode aware APIs. For functions expect Unicode (fe CreateFileW, FindFirstFileW, etc.), arguments will be converted to UTF-16 wide chars. For functions returning Unicode aware data (fe GetCurrentDirectoryW, etc.), resulting wide string is converted back to char's depending on the current PHP charset settings, either to the current ANSI codepage (this is the behavior prior to this patch) or to UTF-8 (the default behavior). In a particular case, users might have to explicitly set internal_encoding or default_charset, if filenames in ANSI codepage are necessary. Current tests show no regressions and witness that this will be an exotic case, the current default UTF-8 encoding is compatible with any supported system. The dependency libraries are long switching to Unicode APIs, so some tests were also added for extensions not directly related to streams. At large, the patch brings over 150 related tests into the core. Those target and was run on various environments with European, Asian, etc. codepages. General PHP frameworks was tested and showed no regressions. The impact on the current C code base is low, the most places affected are the Windows only places in the three files tsrm_win32.c, zend_virtual_cwd.c and plain_wrapper.c. The actual implementation of the most of the wide char supporting functionality is in win32/ioutil.* and win32/codepage.*, several low level functionsare extended in place to avoid reimplementation for now. No performance impact was sighted. As previously mentioned, the ANSI APIs used prior the patch perform Unicode conversions internally. Using the Unicode APIs directly while doing custom conversions just retains the status quo. The ways to optimize it are open (fe. by implementing caching for the strings converted to wide variants). The long path implementation is user transparent. If a path exceeds the length of _MAX_PATH, it'll be automatically prefixed with \\?\. The MAXPATHLEN is set to 2048 bytes. Appreciation to Pierre Joye, Matt Ficken, @algo13 and others for tips, ideas and testing. Thanks.
2016-06-20 07:32:19 +00:00
if (!pathw) {
return -1;
}
Fixed the UTF-8 and long path support in the streams on Windows. Since long the default PHP charset is UTF-8, however the Windows part is out of step with this important point. The current implementation in PHP doesn't technically permit to handle UTF-8 filepath and several other things. Till now, only the ANSI compatible APIs are being used. Here is more about it https://msdn.microsoft.com/en-us/library/windows/desktop/dd317752%28v=vs.85%29.aspx The patch fixes not only issues with multibyte filenames under incompatible codepages, but indirectly also issues with some other multibyte encodings like BIG5, Shift-JIS, etc. by providing a clean way to access filenames in UTF-8. Below is a small list of issues from the bug tracker, that are getting fixed: https://bugs.php.net/63401 https://bugs.php.net/41199 https://bugs.php.net/50203 https://bugs.php.net/71509 https://bugs.php.net/64699 https://bugs.php.net/64506 https://bugs.php.net/30195 https://bugs.php.net/65358 https://bugs.php.net/61315 https://bugs.php.net/70943 https://bugs.php.net/70903 https://bugs.php.net/63593 https://bugs.php.net/54977 https://bugs.php.net/54028 https://bugs.php.net/43148 https://bugs.php.net/30730 https://bugs.php.net/33350 https://bugs.php.net/35300 https://bugs.php.net/46990 https://bugs.php.net/61309 https://bugs.php.net/69333 https://bugs.php.net/45517 https://bugs.php.net/70551 https://bugs.php.net/50197 https://bugs.php.net/72200 https://bugs.php.net/37672 Yet more related tickets can for sure be found - on bugs.php.net, Stackoverflow and Github. Some of the bugs are pretty recent, some descend to early 2000th, but the user comments in there last even till today. Just for example, bug #30195 was opened in 2004, the latest comment in there was made in 2014. It is certain, that these bugs descend not only to pure PHP use cases, but get also redirected from the popular PHP based projects. Given the modern systems (and those supported by PHP) are always based on NTFS, there is no excuse to keep these issues unresolved. The internalization approach on Windows is in many ways different from UNIX and Linux, while it supports and is based on Unicode. It depends on the current system code page, APIs used and exact kind how the binary was compiled The locale doesn't affect the way Unicode or ANSI API work. PHP in particular is being compiled without _UNICODE defined and this is conditioned by the way we handle strings. Here is more about it https://msdn.microsoft.com/en-us/library/tsbaswba.aspx However, with any system code page ANSI functions automatically convert paths to UTF-16. Paths in some encodings incompatible with the current system code page, won't work correctly with ANSI APIs. PHP till now only uses the ANSI Windows APIs. For example, on a system with the current code page 1252, the paths in cp1252 are supported and transparently converted to UTF-16 by the ANSI functions. Once one wants to handle a filepath encoded with cp932 on that particular system, an ANSI or a POSIX compatible function used in PHP will produce an erroneous result. When trying to convert that cp932 path to UTF-8 and passing to the ANSI functions, an ANSI function would likely interpret the UTF-8 string as some string in the current code page and create a filepath that represents every single byte of the UTF-8 string. These behaviors are not only broken but also disregard the documented INI settings. This patch solves the issies with the multibyte paths on Windows by intelligently enforcing the usage of the Unicode aware APIs. For functions expect Unicode (fe CreateFileW, FindFirstFileW, etc.), arguments will be converted to UTF-16 wide chars. For functions returning Unicode aware data (fe GetCurrentDirectoryW, etc.), resulting wide string is converted back to char's depending on the current PHP charset settings, either to the current ANSI codepage (this is the behavior prior to this patch) or to UTF-8 (the default behavior). In a particular case, users might have to explicitly set internal_encoding or default_charset, if filenames in ANSI codepage are necessary. Current tests show no regressions and witness that this will be an exotic case, the current default UTF-8 encoding is compatible with any supported system. The dependency libraries are long switching to Unicode APIs, so some tests were also added for extensions not directly related to streams. At large, the patch brings over 150 related tests into the core. Those target and was run on various environments with European, Asian, etc. codepages. General PHP frameworks was tested and showed no regressions. The impact on the current C code base is low, the most places affected are the Windows only places in the three files tsrm_win32.c, zend_virtual_cwd.c and plain_wrapper.c. The actual implementation of the most of the wide char supporting functionality is in win32/ioutil.* and win32/codepage.*, several low level functionsare extended in place to avoid reimplementation for now. No performance impact was sighted. As previously mentioned, the ANSI APIs used prior the patch perform Unicode conversions internally. Using the Unicode APIs directly while doing custom conversions just retains the status quo. The ways to optimize it are open (fe. by implementing caching for the strings converted to wide variants). The long path implementation is user transparent. If a path exceeds the length of _MAX_PATH, it'll be automatically prefixed with \\?\. The MAXPATHLEN is set to 2048 bytes. Appreciation to Pierre Joye, Matt Ficken, @algo13 and others for tips, ideas and testing. Thanks.
2016-06-20 07:32:19 +00:00
if (!GetFileAttributesExW(pathw, GetFileExInfoStandard, &data)) {
int ret;
#if ZEND_ENABLE_ZVAL_LONG64
ret = _wstat64(pathw, buf);
#else
2016-07-07 13:34:46 +00:00
ret = _wstat(pathw, (struct _stat32 *)buf);
Fixed the UTF-8 and long path support in the streams on Windows. Since long the default PHP charset is UTF-8, however the Windows part is out of step with this important point. The current implementation in PHP doesn't technically permit to handle UTF-8 filepath and several other things. Till now, only the ANSI compatible APIs are being used. Here is more about it https://msdn.microsoft.com/en-us/library/windows/desktop/dd317752%28v=vs.85%29.aspx The patch fixes not only issues with multibyte filenames under incompatible codepages, but indirectly also issues with some other multibyte encodings like BIG5, Shift-JIS, etc. by providing a clean way to access filenames in UTF-8. Below is a small list of issues from the bug tracker, that are getting fixed: https://bugs.php.net/63401 https://bugs.php.net/41199 https://bugs.php.net/50203 https://bugs.php.net/71509 https://bugs.php.net/64699 https://bugs.php.net/64506 https://bugs.php.net/30195 https://bugs.php.net/65358 https://bugs.php.net/61315 https://bugs.php.net/70943 https://bugs.php.net/70903 https://bugs.php.net/63593 https://bugs.php.net/54977 https://bugs.php.net/54028 https://bugs.php.net/43148 https://bugs.php.net/30730 https://bugs.php.net/33350 https://bugs.php.net/35300 https://bugs.php.net/46990 https://bugs.php.net/61309 https://bugs.php.net/69333 https://bugs.php.net/45517 https://bugs.php.net/70551 https://bugs.php.net/50197 https://bugs.php.net/72200 https://bugs.php.net/37672 Yet more related tickets can for sure be found - on bugs.php.net, Stackoverflow and Github. Some of the bugs are pretty recent, some descend to early 2000th, but the user comments in there last even till today. Just for example, bug #30195 was opened in 2004, the latest comment in there was made in 2014. It is certain, that these bugs descend not only to pure PHP use cases, but get also redirected from the popular PHP based projects. Given the modern systems (and those supported by PHP) are always based on NTFS, there is no excuse to keep these issues unresolved. The internalization approach on Windows is in many ways different from UNIX and Linux, while it supports and is based on Unicode. It depends on the current system code page, APIs used and exact kind how the binary was compiled The locale doesn't affect the way Unicode or ANSI API work. PHP in particular is being compiled without _UNICODE defined and this is conditioned by the way we handle strings. Here is more about it https://msdn.microsoft.com/en-us/library/tsbaswba.aspx However, with any system code page ANSI functions automatically convert paths to UTF-16. Paths in some encodings incompatible with the current system code page, won't work correctly with ANSI APIs. PHP till now only uses the ANSI Windows APIs. For example, on a system with the current code page 1252, the paths in cp1252 are supported and transparently converted to UTF-16 by the ANSI functions. Once one wants to handle a filepath encoded with cp932 on that particular system, an ANSI or a POSIX compatible function used in PHP will produce an erroneous result. When trying to convert that cp932 path to UTF-8 and passing to the ANSI functions, an ANSI function would likely interpret the UTF-8 string as some string in the current code page and create a filepath that represents every single byte of the UTF-8 string. These behaviors are not only broken but also disregard the documented INI settings. This patch solves the issies with the multibyte paths on Windows by intelligently enforcing the usage of the Unicode aware APIs. For functions expect Unicode (fe CreateFileW, FindFirstFileW, etc.), arguments will be converted to UTF-16 wide chars. For functions returning Unicode aware data (fe GetCurrentDirectoryW, etc.), resulting wide string is converted back to char's depending on the current PHP charset settings, either to the current ANSI codepage (this is the behavior prior to this patch) or to UTF-8 (the default behavior). In a particular case, users might have to explicitly set internal_encoding or default_charset, if filenames in ANSI codepage are necessary. Current tests show no regressions and witness that this will be an exotic case, the current default UTF-8 encoding is compatible with any supported system. The dependency libraries are long switching to Unicode APIs, so some tests were also added for extensions not directly related to streams. At large, the patch brings over 150 related tests into the core. Those target and was run on various environments with European, Asian, etc. codepages. General PHP frameworks was tested and showed no regressions. The impact on the current C code base is low, the most places affected are the Windows only places in the three files tsrm_win32.c, zend_virtual_cwd.c and plain_wrapper.c. The actual implementation of the most of the wide char supporting functionality is in win32/ioutil.* and win32/codepage.*, several low level functionsare extended in place to avoid reimplementation for now. No performance impact was sighted. As previously mentioned, the ANSI APIs used prior the patch perform Unicode conversions internally. Using the Unicode APIs directly while doing custom conversions just retains the status quo. The ways to optimize it are open (fe. by implementing caching for the strings converted to wide variants). The long path implementation is user transparent. If a path exceeds the length of _MAX_PATH, it'll be automatically prefixed with \\?\. The MAXPATHLEN is set to 2048 bytes. Appreciation to Pierre Joye, Matt Ficken, @algo13 and others for tips, ideas and testing. Thanks.
2016-06-20 07:32:19 +00:00
#endif
free(pathw);
return ret;
}
if (pathw_len >= 1 && pathw[1] == L':') {
if (pathw[0] >= L'A' && pathw[0] <= L'Z') {
buf->st_dev = buf->st_rdev = pathw[0] - L'A';
} else {
buf->st_dev = buf->st_rdev = pathw[0] - L'a';
}
} else if (PHP_WIN32_IOUTIL_IS_UNC(pathw, pathw_len)) {
buf->st_dev = buf->st_rdev = 0;
} else {
Fixed the UTF-8 and long path support in the streams on Windows. Since long the default PHP charset is UTF-8, however the Windows part is out of step with this important point. The current implementation in PHP doesn't technically permit to handle UTF-8 filepath and several other things. Till now, only the ANSI compatible APIs are being used. Here is more about it https://msdn.microsoft.com/en-us/library/windows/desktop/dd317752%28v=vs.85%29.aspx The patch fixes not only issues with multibyte filenames under incompatible codepages, but indirectly also issues with some other multibyte encodings like BIG5, Shift-JIS, etc. by providing a clean way to access filenames in UTF-8. Below is a small list of issues from the bug tracker, that are getting fixed: https://bugs.php.net/63401 https://bugs.php.net/41199 https://bugs.php.net/50203 https://bugs.php.net/71509 https://bugs.php.net/64699 https://bugs.php.net/64506 https://bugs.php.net/30195 https://bugs.php.net/65358 https://bugs.php.net/61315 https://bugs.php.net/70943 https://bugs.php.net/70903 https://bugs.php.net/63593 https://bugs.php.net/54977 https://bugs.php.net/54028 https://bugs.php.net/43148 https://bugs.php.net/30730 https://bugs.php.net/33350 https://bugs.php.net/35300 https://bugs.php.net/46990 https://bugs.php.net/61309 https://bugs.php.net/69333 https://bugs.php.net/45517 https://bugs.php.net/70551 https://bugs.php.net/50197 https://bugs.php.net/72200 https://bugs.php.net/37672 Yet more related tickets can for sure be found - on bugs.php.net, Stackoverflow and Github. Some of the bugs are pretty recent, some descend to early 2000th, but the user comments in there last even till today. Just for example, bug #30195 was opened in 2004, the latest comment in there was made in 2014. It is certain, that these bugs descend not only to pure PHP use cases, but get also redirected from the popular PHP based projects. Given the modern systems (and those supported by PHP) are always based on NTFS, there is no excuse to keep these issues unresolved. The internalization approach on Windows is in many ways different from UNIX and Linux, while it supports and is based on Unicode. It depends on the current system code page, APIs used and exact kind how the binary was compiled The locale doesn't affect the way Unicode or ANSI API work. PHP in particular is being compiled without _UNICODE defined and this is conditioned by the way we handle strings. Here is more about it https://msdn.microsoft.com/en-us/library/tsbaswba.aspx However, with any system code page ANSI functions automatically convert paths to UTF-16. Paths in some encodings incompatible with the current system code page, won't work correctly with ANSI APIs. PHP till now only uses the ANSI Windows APIs. For example, on a system with the current code page 1252, the paths in cp1252 are supported and transparently converted to UTF-16 by the ANSI functions. Once one wants to handle a filepath encoded with cp932 on that particular system, an ANSI or a POSIX compatible function used in PHP will produce an erroneous result. When trying to convert that cp932 path to UTF-8 and passing to the ANSI functions, an ANSI function would likely interpret the UTF-8 string as some string in the current code page and create a filepath that represents every single byte of the UTF-8 string. These behaviors are not only broken but also disregard the documented INI settings. This patch solves the issies with the multibyte paths on Windows by intelligently enforcing the usage of the Unicode aware APIs. For functions expect Unicode (fe CreateFileW, FindFirstFileW, etc.), arguments will be converted to UTF-16 wide chars. For functions returning Unicode aware data (fe GetCurrentDirectoryW, etc.), resulting wide string is converted back to char's depending on the current PHP charset settings, either to the current ANSI codepage (this is the behavior prior to this patch) or to UTF-8 (the default behavior). In a particular case, users might have to explicitly set internal_encoding or default_charset, if filenames in ANSI codepage are necessary. Current tests show no regressions and witness that this will be an exotic case, the current default UTF-8 encoding is compatible with any supported system. The dependency libraries are long switching to Unicode APIs, so some tests were also added for extensions not directly related to streams. At large, the patch brings over 150 related tests into the core. Those target and was run on various environments with European, Asian, etc. codepages. General PHP frameworks was tested and showed no regressions. The impact on the current C code base is low, the most places affected are the Windows only places in the three files tsrm_win32.c, zend_virtual_cwd.c and plain_wrapper.c. The actual implementation of the most of the wide char supporting functionality is in win32/ioutil.* and win32/codepage.*, several low level functionsare extended in place to avoid reimplementation for now. No performance impact was sighted. As previously mentioned, the ANSI APIs used prior the patch perform Unicode conversions internally. Using the Unicode APIs directly while doing custom conversions just retains the status quo. The ways to optimize it are open (fe. by implementing caching for the strings converted to wide variants). The long path implementation is user transparent. If a path exceeds the length of _MAX_PATH, it'll be automatically prefixed with \\?\. The MAXPATHLEN is set to 2048 bytes. Appreciation to Pierre Joye, Matt Ficken, @algo13 and others for tips, ideas and testing. Thanks.
2016-06-20 07:32:19 +00:00
wchar_t cur_path[MAXPATHLEN+1];
if (NULL != _wgetcwd(cur_path, sizeof(cur_path)/sizeof(wchar_t))) {
if (cur_path[1] == L':') {
if (pathw[0] >= L'A' && pathw[0] <= L'Z') {
buf->st_dev = buf->st_rdev = pathw[0] - L'A';
} else {
buf->st_dev = buf->st_rdev = pathw[0] - L'a';
}
} else {
buf->st_dev = buf->st_rdev = -1;
}
} else {
buf->st_dev = buf->st_rdev = -1;
2010-08-27 10:09:52 +00:00
}
}
2010-09-01 09:49:53 +00:00
buf->st_uid = buf->st_gid = buf->st_ino = 0;
2010-09-01 09:49:53 +00:00
if (lstat && data.dwFileAttributes & FILE_ATTRIBUTE_REPARSE_POINT) {
/* File is a reparse point. Get the target */
HANDLE hLink = NULL;
REPARSE_DATA_BUFFER * pbuffer;
2014-11-18 10:49:06 +00:00
DWORD retlength = 0;
2010-09-01 09:49:53 +00:00
Fixed the UTF-8 and long path support in the streams on Windows. Since long the default PHP charset is UTF-8, however the Windows part is out of step with this important point. The current implementation in PHP doesn't technically permit to handle UTF-8 filepath and several other things. Till now, only the ANSI compatible APIs are being used. Here is more about it https://msdn.microsoft.com/en-us/library/windows/desktop/dd317752%28v=vs.85%29.aspx The patch fixes not only issues with multibyte filenames under incompatible codepages, but indirectly also issues with some other multibyte encodings like BIG5, Shift-JIS, etc. by providing a clean way to access filenames in UTF-8. Below is a small list of issues from the bug tracker, that are getting fixed: https://bugs.php.net/63401 https://bugs.php.net/41199 https://bugs.php.net/50203 https://bugs.php.net/71509 https://bugs.php.net/64699 https://bugs.php.net/64506 https://bugs.php.net/30195 https://bugs.php.net/65358 https://bugs.php.net/61315 https://bugs.php.net/70943 https://bugs.php.net/70903 https://bugs.php.net/63593 https://bugs.php.net/54977 https://bugs.php.net/54028 https://bugs.php.net/43148 https://bugs.php.net/30730 https://bugs.php.net/33350 https://bugs.php.net/35300 https://bugs.php.net/46990 https://bugs.php.net/61309 https://bugs.php.net/69333 https://bugs.php.net/45517 https://bugs.php.net/70551 https://bugs.php.net/50197 https://bugs.php.net/72200 https://bugs.php.net/37672 Yet more related tickets can for sure be found - on bugs.php.net, Stackoverflow and Github. Some of the bugs are pretty recent, some descend to early 2000th, but the user comments in there last even till today. Just for example, bug #30195 was opened in 2004, the latest comment in there was made in 2014. It is certain, that these bugs descend not only to pure PHP use cases, but get also redirected from the popular PHP based projects. Given the modern systems (and those supported by PHP) are always based on NTFS, there is no excuse to keep these issues unresolved. The internalization approach on Windows is in many ways different from UNIX and Linux, while it supports and is based on Unicode. It depends on the current system code page, APIs used and exact kind how the binary was compiled The locale doesn't affect the way Unicode or ANSI API work. PHP in particular is being compiled without _UNICODE defined and this is conditioned by the way we handle strings. Here is more about it https://msdn.microsoft.com/en-us/library/tsbaswba.aspx However, with any system code page ANSI functions automatically convert paths to UTF-16. Paths in some encodings incompatible with the current system code page, won't work correctly with ANSI APIs. PHP till now only uses the ANSI Windows APIs. For example, on a system with the current code page 1252, the paths in cp1252 are supported and transparently converted to UTF-16 by the ANSI functions. Once one wants to handle a filepath encoded with cp932 on that particular system, an ANSI or a POSIX compatible function used in PHP will produce an erroneous result. When trying to convert that cp932 path to UTF-8 and passing to the ANSI functions, an ANSI function would likely interpret the UTF-8 string as some string in the current code page and create a filepath that represents every single byte of the UTF-8 string. These behaviors are not only broken but also disregard the documented INI settings. This patch solves the issies with the multibyte paths on Windows by intelligently enforcing the usage of the Unicode aware APIs. For functions expect Unicode (fe CreateFileW, FindFirstFileW, etc.), arguments will be converted to UTF-16 wide chars. For functions returning Unicode aware data (fe GetCurrentDirectoryW, etc.), resulting wide string is converted back to char's depending on the current PHP charset settings, either to the current ANSI codepage (this is the behavior prior to this patch) or to UTF-8 (the default behavior). In a particular case, users might have to explicitly set internal_encoding or default_charset, if filenames in ANSI codepage are necessary. Current tests show no regressions and witness that this will be an exotic case, the current default UTF-8 encoding is compatible with any supported system. The dependency libraries are long switching to Unicode APIs, so some tests were also added for extensions not directly related to streams. At large, the patch brings over 150 related tests into the core. Those target and was run on various environments with European, Asian, etc. codepages. General PHP frameworks was tested and showed no regressions. The impact on the current C code base is low, the most places affected are the Windows only places in the three files tsrm_win32.c, zend_virtual_cwd.c and plain_wrapper.c. The actual implementation of the most of the wide char supporting functionality is in win32/ioutil.* and win32/codepage.*, several low level functionsare extended in place to avoid reimplementation for now. No performance impact was sighted. As previously mentioned, the ANSI APIs used prior the patch perform Unicode conversions internally. Using the Unicode APIs directly while doing custom conversions just retains the status quo. The ways to optimize it are open (fe. by implementing caching for the strings converted to wide variants). The long path implementation is user transparent. If a path exceeds the length of _MAX_PATH, it'll be automatically prefixed with \\?\. The MAXPATHLEN is set to 2048 bytes. Appreciation to Pierre Joye, Matt Ficken, @algo13 and others for tips, ideas and testing. Thanks.
2016-06-20 07:32:19 +00:00
hLink = CreateFileW(pathw, GENERIC_READ, 0, NULL, OPEN_EXISTING, FILE_FLAG_OPEN_REPARSE_POINT|FILE_FLAG_BACKUP_SEMANTICS, NULL);
2010-09-01 09:49:53 +00:00
if(hLink == INVALID_HANDLE_VALUE) {
Fixed the UTF-8 and long path support in the streams on Windows. Since long the default PHP charset is UTF-8, however the Windows part is out of step with this important point. The current implementation in PHP doesn't technically permit to handle UTF-8 filepath and several other things. Till now, only the ANSI compatible APIs are being used. Here is more about it https://msdn.microsoft.com/en-us/library/windows/desktop/dd317752%28v=vs.85%29.aspx The patch fixes not only issues with multibyte filenames under incompatible codepages, but indirectly also issues with some other multibyte encodings like BIG5, Shift-JIS, etc. by providing a clean way to access filenames in UTF-8. Below is a small list of issues from the bug tracker, that are getting fixed: https://bugs.php.net/63401 https://bugs.php.net/41199 https://bugs.php.net/50203 https://bugs.php.net/71509 https://bugs.php.net/64699 https://bugs.php.net/64506 https://bugs.php.net/30195 https://bugs.php.net/65358 https://bugs.php.net/61315 https://bugs.php.net/70943 https://bugs.php.net/70903 https://bugs.php.net/63593 https://bugs.php.net/54977 https://bugs.php.net/54028 https://bugs.php.net/43148 https://bugs.php.net/30730 https://bugs.php.net/33350 https://bugs.php.net/35300 https://bugs.php.net/46990 https://bugs.php.net/61309 https://bugs.php.net/69333 https://bugs.php.net/45517 https://bugs.php.net/70551 https://bugs.php.net/50197 https://bugs.php.net/72200 https://bugs.php.net/37672 Yet more related tickets can for sure be found - on bugs.php.net, Stackoverflow and Github. Some of the bugs are pretty recent, some descend to early 2000th, but the user comments in there last even till today. Just for example, bug #30195 was opened in 2004, the latest comment in there was made in 2014. It is certain, that these bugs descend not only to pure PHP use cases, but get also redirected from the popular PHP based projects. Given the modern systems (and those supported by PHP) are always based on NTFS, there is no excuse to keep these issues unresolved. The internalization approach on Windows is in many ways different from UNIX and Linux, while it supports and is based on Unicode. It depends on the current system code page, APIs used and exact kind how the binary was compiled The locale doesn't affect the way Unicode or ANSI API work. PHP in particular is being compiled without _UNICODE defined and this is conditioned by the way we handle strings. Here is more about it https://msdn.microsoft.com/en-us/library/tsbaswba.aspx However, with any system code page ANSI functions automatically convert paths to UTF-16. Paths in some encodings incompatible with the current system code page, won't work correctly with ANSI APIs. PHP till now only uses the ANSI Windows APIs. For example, on a system with the current code page 1252, the paths in cp1252 are supported and transparently converted to UTF-16 by the ANSI functions. Once one wants to handle a filepath encoded with cp932 on that particular system, an ANSI or a POSIX compatible function used in PHP will produce an erroneous result. When trying to convert that cp932 path to UTF-8 and passing to the ANSI functions, an ANSI function would likely interpret the UTF-8 string as some string in the current code page and create a filepath that represents every single byte of the UTF-8 string. These behaviors are not only broken but also disregard the documented INI settings. This patch solves the issies with the multibyte paths on Windows by intelligently enforcing the usage of the Unicode aware APIs. For functions expect Unicode (fe CreateFileW, FindFirstFileW, etc.), arguments will be converted to UTF-16 wide chars. For functions returning Unicode aware data (fe GetCurrentDirectoryW, etc.), resulting wide string is converted back to char's depending on the current PHP charset settings, either to the current ANSI codepage (this is the behavior prior to this patch) or to UTF-8 (the default behavior). In a particular case, users might have to explicitly set internal_encoding or default_charset, if filenames in ANSI codepage are necessary. Current tests show no regressions and witness that this will be an exotic case, the current default UTF-8 encoding is compatible with any supported system. The dependency libraries are long switching to Unicode APIs, so some tests were also added for extensions not directly related to streams. At large, the patch brings over 150 related tests into the core. Those target and was run on various environments with European, Asian, etc. codepages. General PHP frameworks was tested and showed no regressions. The impact on the current C code base is low, the most places affected are the Windows only places in the three files tsrm_win32.c, zend_virtual_cwd.c and plain_wrapper.c. The actual implementation of the most of the wide char supporting functionality is in win32/ioutil.* and win32/codepage.*, several low level functionsare extended in place to avoid reimplementation for now. No performance impact was sighted. As previously mentioned, the ANSI APIs used prior the patch perform Unicode conversions internally. Using the Unicode APIs directly while doing custom conversions just retains the status quo. The ways to optimize it are open (fe. by implementing caching for the strings converted to wide variants). The long path implementation is user transparent. If a path exceeds the length of _MAX_PATH, it'll be automatically prefixed with \\?\. The MAXPATHLEN is set to 2048 bytes. Appreciation to Pierre Joye, Matt Ficken, @algo13 and others for tips, ideas and testing. Thanks.
2016-06-20 07:32:19 +00:00
free(pathw);
2010-09-01 09:49:53 +00:00
return -1;
}
pbuffer = (REPARSE_DATA_BUFFER *)do_alloca(MAXIMUM_REPARSE_DATA_BUFFER_SIZE, use_heap_large);
2010-09-01 09:49:53 +00:00
if(!DeviceIoControl(hLink, FSCTL_GET_REPARSE_POINT, NULL, 0, pbuffer, MAXIMUM_REPARSE_DATA_BUFFER_SIZE, &retlength, NULL)) {
free_alloca(pbuffer, use_heap_large);
2010-09-01 09:49:53 +00:00
CloseHandle(hLink);
Fixed the UTF-8 and long path support in the streams on Windows. Since long the default PHP charset is UTF-8, however the Windows part is out of step with this important point. The current implementation in PHP doesn't technically permit to handle UTF-8 filepath and several other things. Till now, only the ANSI compatible APIs are being used. Here is more about it https://msdn.microsoft.com/en-us/library/windows/desktop/dd317752%28v=vs.85%29.aspx The patch fixes not only issues with multibyte filenames under incompatible codepages, but indirectly also issues with some other multibyte encodings like BIG5, Shift-JIS, etc. by providing a clean way to access filenames in UTF-8. Below is a small list of issues from the bug tracker, that are getting fixed: https://bugs.php.net/63401 https://bugs.php.net/41199 https://bugs.php.net/50203 https://bugs.php.net/71509 https://bugs.php.net/64699 https://bugs.php.net/64506 https://bugs.php.net/30195 https://bugs.php.net/65358 https://bugs.php.net/61315 https://bugs.php.net/70943 https://bugs.php.net/70903 https://bugs.php.net/63593 https://bugs.php.net/54977 https://bugs.php.net/54028 https://bugs.php.net/43148 https://bugs.php.net/30730 https://bugs.php.net/33350 https://bugs.php.net/35300 https://bugs.php.net/46990 https://bugs.php.net/61309 https://bugs.php.net/69333 https://bugs.php.net/45517 https://bugs.php.net/70551 https://bugs.php.net/50197 https://bugs.php.net/72200 https://bugs.php.net/37672 Yet more related tickets can for sure be found - on bugs.php.net, Stackoverflow and Github. Some of the bugs are pretty recent, some descend to early 2000th, but the user comments in there last even till today. Just for example, bug #30195 was opened in 2004, the latest comment in there was made in 2014. It is certain, that these bugs descend not only to pure PHP use cases, but get also redirected from the popular PHP based projects. Given the modern systems (and those supported by PHP) are always based on NTFS, there is no excuse to keep these issues unresolved. The internalization approach on Windows is in many ways different from UNIX and Linux, while it supports and is based on Unicode. It depends on the current system code page, APIs used and exact kind how the binary was compiled The locale doesn't affect the way Unicode or ANSI API work. PHP in particular is being compiled without _UNICODE defined and this is conditioned by the way we handle strings. Here is more about it https://msdn.microsoft.com/en-us/library/tsbaswba.aspx However, with any system code page ANSI functions automatically convert paths to UTF-16. Paths in some encodings incompatible with the current system code page, won't work correctly with ANSI APIs. PHP till now only uses the ANSI Windows APIs. For example, on a system with the current code page 1252, the paths in cp1252 are supported and transparently converted to UTF-16 by the ANSI functions. Once one wants to handle a filepath encoded with cp932 on that particular system, an ANSI or a POSIX compatible function used in PHP will produce an erroneous result. When trying to convert that cp932 path to UTF-8 and passing to the ANSI functions, an ANSI function would likely interpret the UTF-8 string as some string in the current code page and create a filepath that represents every single byte of the UTF-8 string. These behaviors are not only broken but also disregard the documented INI settings. This patch solves the issies with the multibyte paths on Windows by intelligently enforcing the usage of the Unicode aware APIs. For functions expect Unicode (fe CreateFileW, FindFirstFileW, etc.), arguments will be converted to UTF-16 wide chars. For functions returning Unicode aware data (fe GetCurrentDirectoryW, etc.), resulting wide string is converted back to char's depending on the current PHP charset settings, either to the current ANSI codepage (this is the behavior prior to this patch) or to UTF-8 (the default behavior). In a particular case, users might have to explicitly set internal_encoding or default_charset, if filenames in ANSI codepage are necessary. Current tests show no regressions and witness that this will be an exotic case, the current default UTF-8 encoding is compatible with any supported system. The dependency libraries are long switching to Unicode APIs, so some tests were also added for extensions not directly related to streams. At large, the patch brings over 150 related tests into the core. Those target and was run on various environments with European, Asian, etc. codepages. General PHP frameworks was tested and showed no regressions. The impact on the current C code base is low, the most places affected are the Windows only places in the three files tsrm_win32.c, zend_virtual_cwd.c and plain_wrapper.c. The actual implementation of the most of the wide char supporting functionality is in win32/ioutil.* and win32/codepage.*, several low level functionsare extended in place to avoid reimplementation for now. No performance impact was sighted. As previously mentioned, the ANSI APIs used prior the patch perform Unicode conversions internally. Using the Unicode APIs directly while doing custom conversions just retains the status quo. The ways to optimize it are open (fe. by implementing caching for the strings converted to wide variants). The long path implementation is user transparent. If a path exceeds the length of _MAX_PATH, it'll be automatically prefixed with \\?\. The MAXPATHLEN is set to 2048 bytes. Appreciation to Pierre Joye, Matt Ficken, @algo13 and others for tips, ideas and testing. Thanks.
2016-06-20 07:32:19 +00:00
free(pathw);
2010-09-01 09:49:53 +00:00
return -1;
}
CloseHandle(hLink);
if(pbuffer->ReparseTag == IO_REPARSE_TAG_SYMLINK) {
buf->st_mode = S_IFLNK;
buf->st_mode |= (data.dwFileAttributes & FILE_ATTRIBUTE_READONLY) ? (S_IREAD|(S_IREAD>>3)|(S_IREAD>>6)) : (S_IREAD|(S_IREAD>>3)|(S_IREAD>>6)|S_IWRITE|(S_IWRITE>>3)|(S_IWRITE>>6));
}
#if 0 /* Not used yet */
else if(pbuffer->ReparseTag == IO_REPARSE_TAG_MOUNT_POINT) {
buf->st_mode |=;
}
#endif
free_alloca(pbuffer, use_heap_large);
2010-09-01 09:49:53 +00:00
} else {
buf->st_mode = (data.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY) ? (S_IFDIR|S_IEXEC|(S_IEXEC>>3)|(S_IEXEC>>6)) : S_IFREG;
buf->st_mode |= (data.dwFileAttributes & FILE_ATTRIBUTE_READONLY) ? (S_IREAD|(S_IREAD>>3)|(S_IREAD>>6)) : (S_IREAD|(S_IREAD>>3)|(S_IREAD>>6)|S_IWRITE|(S_IWRITE>>3)|(S_IWRITE>>6));
}
if ((data.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY) == 0) {
if (pathw_len >= 4 && pathw[pathw_len-4] == L'.') {
if (_wcsnicmp(pathw+pathw_len-3, L"exe", 3) == 0 ||
_wcsnicmp(pathw+pathw_len-3, L"com", 3) == 0 ||
_wcsnicmp(pathw+pathw_len-3, L"bat", 3) == 0 ||
_wcsnicmp(pathw+pathw_len-3, L"cmd", 3) == 0) {
buf->st_mode |= (S_IEXEC|(S_IEXEC>>3)|(S_IEXEC>>6));
}
}
}
buf->st_nlink = 1;
t.HighPart = data.nFileSizeHigh;
t.LowPart = data.nFileSizeLow;
/* It's an overflow on 32 bit, however it won't fix as long
as zend_long is 32 bit. */
buf->st_size = (zend_long)t.QuadPart;
buf->st_atime = FileTimeToUnixTime(&data.ftLastAccessTime);
buf->st_ctime = FileTimeToUnixTime(&data.ftCreationTime);
buf->st_mtime = FileTimeToUnixTime(&data.ftLastWriteTime);
Fixed the UTF-8 and long path support in the streams on Windows. Since long the default PHP charset is UTF-8, however the Windows part is out of step with this important point. The current implementation in PHP doesn't technically permit to handle UTF-8 filepath and several other things. Till now, only the ANSI compatible APIs are being used. Here is more about it https://msdn.microsoft.com/en-us/library/windows/desktop/dd317752%28v=vs.85%29.aspx The patch fixes not only issues with multibyte filenames under incompatible codepages, but indirectly also issues with some other multibyte encodings like BIG5, Shift-JIS, etc. by providing a clean way to access filenames in UTF-8. Below is a small list of issues from the bug tracker, that are getting fixed: https://bugs.php.net/63401 https://bugs.php.net/41199 https://bugs.php.net/50203 https://bugs.php.net/71509 https://bugs.php.net/64699 https://bugs.php.net/64506 https://bugs.php.net/30195 https://bugs.php.net/65358 https://bugs.php.net/61315 https://bugs.php.net/70943 https://bugs.php.net/70903 https://bugs.php.net/63593 https://bugs.php.net/54977 https://bugs.php.net/54028 https://bugs.php.net/43148 https://bugs.php.net/30730 https://bugs.php.net/33350 https://bugs.php.net/35300 https://bugs.php.net/46990 https://bugs.php.net/61309 https://bugs.php.net/69333 https://bugs.php.net/45517 https://bugs.php.net/70551 https://bugs.php.net/50197 https://bugs.php.net/72200 https://bugs.php.net/37672 Yet more related tickets can for sure be found - on bugs.php.net, Stackoverflow and Github. Some of the bugs are pretty recent, some descend to early 2000th, but the user comments in there last even till today. Just for example, bug #30195 was opened in 2004, the latest comment in there was made in 2014. It is certain, that these bugs descend not only to pure PHP use cases, but get also redirected from the popular PHP based projects. Given the modern systems (and those supported by PHP) are always based on NTFS, there is no excuse to keep these issues unresolved. The internalization approach on Windows is in many ways different from UNIX and Linux, while it supports and is based on Unicode. It depends on the current system code page, APIs used and exact kind how the binary was compiled The locale doesn't affect the way Unicode or ANSI API work. PHP in particular is being compiled without _UNICODE defined and this is conditioned by the way we handle strings. Here is more about it https://msdn.microsoft.com/en-us/library/tsbaswba.aspx However, with any system code page ANSI functions automatically convert paths to UTF-16. Paths in some encodings incompatible with the current system code page, won't work correctly with ANSI APIs. PHP till now only uses the ANSI Windows APIs. For example, on a system with the current code page 1252, the paths in cp1252 are supported and transparently converted to UTF-16 by the ANSI functions. Once one wants to handle a filepath encoded with cp932 on that particular system, an ANSI or a POSIX compatible function used in PHP will produce an erroneous result. When trying to convert that cp932 path to UTF-8 and passing to the ANSI functions, an ANSI function would likely interpret the UTF-8 string as some string in the current code page and create a filepath that represents every single byte of the UTF-8 string. These behaviors are not only broken but also disregard the documented INI settings. This patch solves the issies with the multibyte paths on Windows by intelligently enforcing the usage of the Unicode aware APIs. For functions expect Unicode (fe CreateFileW, FindFirstFileW, etc.), arguments will be converted to UTF-16 wide chars. For functions returning Unicode aware data (fe GetCurrentDirectoryW, etc.), resulting wide string is converted back to char's depending on the current PHP charset settings, either to the current ANSI codepage (this is the behavior prior to this patch) or to UTF-8 (the default behavior). In a particular case, users might have to explicitly set internal_encoding or default_charset, if filenames in ANSI codepage are necessary. Current tests show no regressions and witness that this will be an exotic case, the current default UTF-8 encoding is compatible with any supported system. The dependency libraries are long switching to Unicode APIs, so some tests were also added for extensions not directly related to streams. At large, the patch brings over 150 related tests into the core. Those target and was run on various environments with European, Asian, etc. codepages. General PHP frameworks was tested and showed no regressions. The impact on the current C code base is low, the most places affected are the Windows only places in the three files tsrm_win32.c, zend_virtual_cwd.c and plain_wrapper.c. The actual implementation of the most of the wide char supporting functionality is in win32/ioutil.* and win32/codepage.*, several low level functionsare extended in place to avoid reimplementation for now. No performance impact was sighted. As previously mentioned, the ANSI APIs used prior the patch perform Unicode conversions internally. Using the Unicode APIs directly while doing custom conversions just retains the status quo. The ways to optimize it are open (fe. by implementing caching for the strings converted to wide variants). The long path implementation is user transparent. If a path exceeds the length of _MAX_PATH, it'll be automatically prefixed with \\?\. The MAXPATHLEN is set to 2048 bytes. Appreciation to Pierre Joye, Matt Ficken, @algo13 and others for tips, ideas and testing. Thanks.
2016-06-20 07:32:19 +00:00
free(pathw);
return 0;
}
2007-08-10 09:09:46 +00:00
/* }}} */
#endif
2007-08-10 09:09:46 +00:00
static int php_is_dir_ok(const cwd_state *state) /* {{{ */
{
zend_stat_t buf;
if (php_sys_stat(state->cwd, &buf) == 0 && S_ISDIR(buf.st_mode))
return (0);
return (1);
}
2007-08-10 09:09:46 +00:00
/* }}} */
2007-08-10 09:09:46 +00:00
static int php_is_file_ok(const cwd_state *state) /* {{{ */
{
zend_stat_t buf;
if (php_sys_stat(state->cwd, &buf) == 0 && S_ISREG(buf.st_mode))
return (0);
return (1);
}
2007-08-10 09:09:46 +00:00
/* }}} */
2014-12-13 22:06:14 +00:00
static void cwd_globals_ctor(virtual_cwd_globals *cwd_g) /* {{{ */
{
CWD_STATE_COPY(&cwd_g->cwd, &main_cwd_state);
cwd_g->realpath_cache_size = 0;
cwd_g->realpath_cache_size_limit = REALPATH_CACHE_SIZE;
cwd_g->realpath_cache_ttl = REALPATH_CACHE_TTL;
memset(cwd_g->realpath_cache, 0, sizeof(cwd_g->realpath_cache));
}
2007-08-10 09:09:46 +00:00
/* }}} */
2014-12-13 22:06:14 +00:00
static void cwd_globals_dtor(virtual_cwd_globals *cwd_g) /* {{{ */
{
2014-12-13 22:06:14 +00:00
realpath_cache_clean();
}
2007-08-10 09:09:46 +00:00
/* }}} */
2017-08-13 22:44:19 +00:00
void virtual_cwd_main_cwd_init(uint8_t reinit) /* {{{ */
{
char cwd[MAXPATHLEN];
char *result;
2017-08-13 22:44:19 +00:00
if (reinit) {
free(main_cwd_state.cwd);
}
#ifdef ZEND_WIN32
ZeroMemory(&cwd, sizeof(cwd));
2017-08-13 22:44:19 +00:00
result = php_win32_ioutil_getcwd(cwd, sizeof(cwd));
#else
2010-09-10 14:02:19 +00:00
result = getcwd(cwd, sizeof(cwd));
#endif
if (!result) {
cwd[0] = '\0';
}
2014-10-24 18:57:38 +00:00
main_cwd_state.cwd_length = (int)strlen(cwd);
#ifdef ZEND_WIN32
if (main_cwd_state.cwd_length >= 2 && cwd[1] == ':') {
cwd[0] = toupper(cwd[0]);
}
#endif
main_cwd_state.cwd = strdup(cwd);
2017-08-13 22:44:19 +00:00
}
/* }}} */
2017-08-13 22:44:19 +00:00
CWD_API void virtual_cwd_startup(void) /* {{{ */
{
virtual_cwd_main_cwd_init(0);
#ifdef ZTS
ts_allocate_id(&cwd_globals_id, sizeof(virtual_cwd_globals), (ts_allocate_ctor) cwd_globals_ctor, (ts_allocate_dtor) cwd_globals_dtor);
#else
2014-12-13 22:06:14 +00:00
cwd_globals_ctor(&cwd_globals);
#endif
#if (defined(ZEND_WIN32)) && defined(ZTS)
cwd_mutex = tsrm_mutex_alloc();
#endif
}
2007-08-10 09:09:46 +00:00
/* }}} */
2007-08-10 09:09:46 +00:00
CWD_API void virtual_cwd_shutdown(void) /* {{{ */
{
#ifndef ZTS
2014-12-13 22:06:14 +00:00
cwd_globals_dtor(&cwd_globals);
#endif
#if (defined(ZEND_WIN32)) && defined(ZTS)
tsrm_mutex_free(cwd_mutex);
#endif
free(main_cwd_state.cwd); /* Don't use CWD_STATE_FREE because the non global states will probably use emalloc()/efree() */
}
2007-08-10 09:09:46 +00:00
/* }}} */
2014-12-13 22:06:14 +00:00
CWD_API int virtual_cwd_activate(void) /* {{{ */
{
if (CWDG(cwd).cwd == NULL) {
CWD_STATE_COPY(&CWDG(cwd), &main_cwd_state);
}
return 0;
}
/* }}} */
2014-12-13 22:06:14 +00:00
CWD_API int virtual_cwd_deactivate(void) /* {{{ */
{
if (CWDG(cwd).cwd != NULL) {
CWD_STATE_FREE(&CWDG(cwd));
2013-10-31 16:39:17 +00:00
CWDG(cwd).cwd = NULL;
}
return 0;
}
/* }}} */
2014-12-13 22:06:14 +00:00
CWD_API char *virtual_getcwd_ex(size_t *length) /* {{{ */
{
cwd_state *state;
state = &CWDG(cwd);
if (state->cwd_length == 0) {
char *retval;
*length = 1;
retval = (char *) emalloc(2);
retval[0] = DEFAULT_SLASH;
2010-09-10 14:02:19 +00:00
retval[1] = '\0';
return retval;
}
#ifdef ZEND_WIN32
/* If we have something like C: */
if (state->cwd_length == 2 && state->cwd[state->cwd_length-1] == ':') {
char *retval;
*length = state->cwd_length+1;
retval = (char *) emalloc(*length+1);
memcpy(retval, state->cwd, *length);
retval[0] = toupper(retval[0]);
retval[*length-1] = DEFAULT_SLASH;
retval[*length] = '\0';
return retval;
}
#endif
if (!state->cwd) {
*length = 0;
return NULL;
}
*length = state->cwd_length;
return estrdup(state->cwd);
}
2007-08-10 09:09:46 +00:00
/* }}} */
/* Same semantics as UNIX getcwd() */
2014-12-13 22:06:14 +00:00
CWD_API char *virtual_getcwd(char *buf, size_t size) /* {{{ */
{
size_t length;
char *cwd;
2014-12-13 22:06:14 +00:00
cwd = virtual_getcwd_ex(&length);
if (buf == NULL) {
return cwd;
}
if (length > size-1) {
efree(cwd);
errno = ERANGE; /* Is this OK? */
return NULL;
}
if (!cwd) {
return NULL;
}
memcpy(buf, cwd, length+1);
efree(cwd);
return buf;
}
2007-08-10 09:09:46 +00:00
/* }}} */
#ifdef ZEND_WIN32
static inline zend_ulong realpath_cache_key(const char *path, size_t path_len) /* {{{ */
{
2014-08-25 17:24:55 +00:00
register zend_ulong h;
2017-04-27 13:39:32 +00:00
size_t bucket_key_len;
char *bucket_key_start = tsrm_win32_get_path_sid_key(path, path_len, &bucket_key_len);
2010-01-27 16:43:16 +00:00
char *bucket_key = (char *)bucket_key_start;
const char *e;
if (!bucket_key) {
return 0;
}
2017-04-27 13:39:32 +00:00
e = bucket_key + bucket_key_len;
2014-08-25 18:57:25 +00:00
for (h = Z_UL(2166136261); bucket_key < e;) {
h *= Z_UL(16777619);
h ^= *bucket_key++;
}
if (bucket_key_start != path) {
HeapFree(GetProcessHeap(), 0, (LPVOID)bucket_key_start);
}
return h;
}
/* }}} */
#else
static inline zend_ulong realpath_cache_key(const char *path, size_t path_len) /* {{{ */
{
2014-08-25 17:24:55 +00:00
register zend_ulong h;
2007-01-20 16:22:51 +00:00
const char *e = path + path_len;
2014-08-25 18:57:25 +00:00
for (h = Z_UL(2166136261); path < e;) {
h *= Z_UL(16777619);
2007-01-20 16:22:51 +00:00
h ^= *path++;
}
return h;
}
2007-08-10 09:09:46 +00:00
/* }}} */
#endif /* defined(ZEND_WIN32) */
2014-12-13 22:06:14 +00:00
CWD_API void realpath_cache_clean(void) /* {{{ */
{
2014-12-12 18:57:34 +00:00
uint32_t i;
for (i = 0; i < sizeof(CWDG(realpath_cache))/sizeof(CWDG(realpath_cache)[0]); i++) {
realpath_cache_bucket *p = CWDG(realpath_cache)[i];
while (p != NULL) {
realpath_cache_bucket *r = p;
p = p->next;
free(r);
}
CWDG(realpath_cache)[i] = NULL;
}
CWDG(realpath_cache_size) = 0;
}
2007-08-10 09:09:46 +00:00
/* }}} */
CWD_API void realpath_cache_del(const char *path, size_t path_len) /* {{{ */
{
2014-12-13 22:06:14 +00:00
zend_ulong key = realpath_cache_key(path, path_len);
2014-08-25 17:24:55 +00:00
zend_ulong n = key % (sizeof(CWDG(realpath_cache)) / sizeof(CWDG(realpath_cache)[0]));
realpath_cache_bucket **bucket = &CWDG(realpath_cache)[n];
while (*bucket != NULL) {
if (key == (*bucket)->key && path_len == (*bucket)->path_len &&
2010-08-27 10:09:52 +00:00
memcmp(path, (*bucket)->path, path_len) == 0) {
realpath_cache_bucket *r = *bucket;
*bucket = (*bucket)->next;
2015-01-03 09:22:58 +00:00
2011-05-19 23:09:58 +00:00
/* if the pointers match then only subtract the length of the path */
2011-05-19 23:18:55 +00:00
if(r->path == r->realpath) {
CWDG(realpath_cache_size) -= sizeof(realpath_cache_bucket) + r->path_len + 1;
} else {
CWDG(realpath_cache_size) -= sizeof(realpath_cache_bucket) + r->path_len + 1 + r->realpath_len + 1;
}
2015-01-03 09:22:58 +00:00
free(r);
return;
} else {
bucket = &(*bucket)->next;
}
}
}
2007-08-10 09:09:46 +00:00
/* }}} */
static inline void realpath_cache_add(const char *path, int path_len, const char *realpath, size_t realpath_len, int is_dir, time_t t) /* {{{ */
{
2014-08-25 17:24:55 +00:00
zend_long size = sizeof(realpath_cache_bucket) + path_len + 1;
int same = 1;
2010-09-10 14:02:19 +00:00
if (realpath_len != path_len ||
2010-08-27 10:09:52 +00:00
memcmp(path, realpath, path_len) != 0) {
size += realpath_len + 1;
same = 0;
}
if (CWDG(realpath_cache_size) + size <= CWDG(realpath_cache_size_limit)) {
realpath_cache_bucket *bucket = malloc(size);
2014-08-25 17:24:55 +00:00
zend_ulong n;
2011-01-10 00:43:08 +00:00
if (bucket == NULL) {
return;
}
bucket->key = realpath_cache_key(path, path_len);
bucket->path = (char*)bucket + sizeof(realpath_cache_bucket);
memcpy(bucket->path, path, path_len+1);
bucket->path_len = path_len;
if (same) {
bucket->realpath = bucket->path;
} else {
bucket->realpath = bucket->path + (path_len + 1);
memcpy(bucket->realpath, realpath, realpath_len+1);
}
bucket->realpath_len = realpath_len;
bucket->is_dir = is_dir > 0;
#ifdef ZEND_WIN32
bucket->is_rvalid = 0;
bucket->is_readable = 0;
bucket->is_wvalid = 0;
bucket->is_writable = 0;
#endif
bucket->expires = t + CWDG(realpath_cache_ttl);
n = bucket->key % (sizeof(CWDG(realpath_cache)) / sizeof(CWDG(realpath_cache)[0]));
bucket->next = CWDG(realpath_cache)[n];
CWDG(realpath_cache)[n] = bucket;
2007-01-20 16:22:51 +00:00
CWDG(realpath_cache_size) += size;
}
}
2007-08-10 09:09:46 +00:00
/* }}} */
static inline realpath_cache_bucket* realpath_cache_find(const char *path, size_t path_len, time_t t) /* {{{ */
{
2014-08-25 17:24:55 +00:00
zend_ulong key = realpath_cache_key(path, path_len);
zend_ulong n = key % (sizeof(CWDG(realpath_cache)) / sizeof(CWDG(realpath_cache)[0]));
realpath_cache_bucket **bucket = &CWDG(realpath_cache)[n];
while (*bucket != NULL) {
if (CWDG(realpath_cache_ttl) && (*bucket)->expires < t) {
realpath_cache_bucket *r = *bucket;
*bucket = (*bucket)->next;
2011-05-19 23:09:58 +00:00
2015-01-03 09:22:58 +00:00
/* if the pointers match then only subtract the length of the path */
2011-05-19 23:18:55 +00:00
if(r->path == r->realpath) {
CWDG(realpath_cache_size) -= sizeof(realpath_cache_bucket) + r->path_len + 1;
} else {
CWDG(realpath_cache_size) -= sizeof(realpath_cache_bucket) + r->path_len + 1 + r->realpath_len + 1;
}
free(r);
} else if (key == (*bucket)->key && path_len == (*bucket)->path_len &&
2010-08-27 10:09:52 +00:00
memcmp(path, (*bucket)->path, path_len) == 0) {
return *bucket;
} else {
bucket = &(*bucket)->next;
}
}
return NULL;
}
2007-08-10 09:09:46 +00:00
/* }}} */
CWD_API realpath_cache_bucket* realpath_cache_lookup(const char *path, size_t path_len, time_t t) /* {{{ */
{
2014-12-13 22:06:14 +00:00
return realpath_cache_find(path, path_len, t);
}
/* }}} */
2014-12-13 22:06:14 +00:00
CWD_API zend_long realpath_cache_size(void)
2009-12-08 01:35:08 +00:00
{
return CWDG(realpath_cache_size);
}
2014-12-13 22:06:14 +00:00
CWD_API zend_long realpath_cache_max_buckets(void)
2009-12-08 01:35:08 +00:00
{
return (sizeof(CWDG(realpath_cache)) / sizeof(CWDG(realpath_cache)[0]));
}
2014-12-13 22:06:14 +00:00
CWD_API realpath_cache_bucket** realpath_cache_get_buckets(void)
2009-12-08 01:35:08 +00:00
{
return CWDG(realpath_cache);
}
#undef LINK_MAX
#define LINK_MAX 32
2014-12-13 22:06:14 +00:00
static int tsrm_realpath_r(char *path, int start, int len, int *ll, time_t *t, int use_realpath, int is_dir, int *link_is_dir) /* {{{ */
{
int i, j, save;
int directory = 0;
#ifdef ZEND_WIN32
Fixed the UTF-8 and long path support in the streams on Windows. Since long the default PHP charset is UTF-8, however the Windows part is out of step with this important point. The current implementation in PHP doesn't technically permit to handle UTF-8 filepath and several other things. Till now, only the ANSI compatible APIs are being used. Here is more about it https://msdn.microsoft.com/en-us/library/windows/desktop/dd317752%28v=vs.85%29.aspx The patch fixes not only issues with multibyte filenames under incompatible codepages, but indirectly also issues with some other multibyte encodings like BIG5, Shift-JIS, etc. by providing a clean way to access filenames in UTF-8. Below is a small list of issues from the bug tracker, that are getting fixed: https://bugs.php.net/63401 https://bugs.php.net/41199 https://bugs.php.net/50203 https://bugs.php.net/71509 https://bugs.php.net/64699 https://bugs.php.net/64506 https://bugs.php.net/30195 https://bugs.php.net/65358 https://bugs.php.net/61315 https://bugs.php.net/70943 https://bugs.php.net/70903 https://bugs.php.net/63593 https://bugs.php.net/54977 https://bugs.php.net/54028 https://bugs.php.net/43148 https://bugs.php.net/30730 https://bugs.php.net/33350 https://bugs.php.net/35300 https://bugs.php.net/46990 https://bugs.php.net/61309 https://bugs.php.net/69333 https://bugs.php.net/45517 https://bugs.php.net/70551 https://bugs.php.net/50197 https://bugs.php.net/72200 https://bugs.php.net/37672 Yet more related tickets can for sure be found - on bugs.php.net, Stackoverflow and Github. Some of the bugs are pretty recent, some descend to early 2000th, but the user comments in there last even till today. Just for example, bug #30195 was opened in 2004, the latest comment in there was made in 2014. It is certain, that these bugs descend not only to pure PHP use cases, but get also redirected from the popular PHP based projects. Given the modern systems (and those supported by PHP) are always based on NTFS, there is no excuse to keep these issues unresolved. The internalization approach on Windows is in many ways different from UNIX and Linux, while it supports and is based on Unicode. It depends on the current system code page, APIs used and exact kind how the binary was compiled The locale doesn't affect the way Unicode or ANSI API work. PHP in particular is being compiled without _UNICODE defined and this is conditioned by the way we handle strings. Here is more about it https://msdn.microsoft.com/en-us/library/tsbaswba.aspx However, with any system code page ANSI functions automatically convert paths to UTF-16. Paths in some encodings incompatible with the current system code page, won't work correctly with ANSI APIs. PHP till now only uses the ANSI Windows APIs. For example, on a system with the current code page 1252, the paths in cp1252 are supported and transparently converted to UTF-16 by the ANSI functions. Once one wants to handle a filepath encoded with cp932 on that particular system, an ANSI or a POSIX compatible function used in PHP will produce an erroneous result. When trying to convert that cp932 path to UTF-8 and passing to the ANSI functions, an ANSI function would likely interpret the UTF-8 string as some string in the current code page and create a filepath that represents every single byte of the UTF-8 string. These behaviors are not only broken but also disregard the documented INI settings. This patch solves the issies with the multibyte paths on Windows by intelligently enforcing the usage of the Unicode aware APIs. For functions expect Unicode (fe CreateFileW, FindFirstFileW, etc.), arguments will be converted to UTF-16 wide chars. For functions returning Unicode aware data (fe GetCurrentDirectoryW, etc.), resulting wide string is converted back to char's depending on the current PHP charset settings, either to the current ANSI codepage (this is the behavior prior to this patch) or to UTF-8 (the default behavior). In a particular case, users might have to explicitly set internal_encoding or default_charset, if filenames in ANSI codepage are necessary. Current tests show no regressions and witness that this will be an exotic case, the current default UTF-8 encoding is compatible with any supported system. The dependency libraries are long switching to Unicode APIs, so some tests were also added for extensions not directly related to streams. At large, the patch brings over 150 related tests into the core. Those target and was run on various environments with European, Asian, etc. codepages. General PHP frameworks was tested and showed no regressions. The impact on the current C code base is low, the most places affected are the Windows only places in the three files tsrm_win32.c, zend_virtual_cwd.c and plain_wrapper.c. The actual implementation of the most of the wide char supporting functionality is in win32/ioutil.* and win32/codepage.*, several low level functionsare extended in place to avoid reimplementation for now. No performance impact was sighted. As previously mentioned, the ANSI APIs used prior the patch perform Unicode conversions internally. Using the Unicode APIs directly while doing custom conversions just retains the status quo. The ways to optimize it are open (fe. by implementing caching for the strings converted to wide variants). The long path implementation is user transparent. If a path exceeds the length of _MAX_PATH, it'll be automatically prefixed with \\?\. The MAXPATHLEN is set to 2048 bytes. Appreciation to Pierre Joye, Matt Ficken, @algo13 and others for tips, ideas and testing. Thanks.
2016-06-20 07:32:19 +00:00
WIN32_FIND_DATAW dataw;
HANDLE hFind = INVALID_HANDLE_VALUE;
ALLOCA_FLAG(use_heap_large)
Fixed the UTF-8 and long path support in the streams on Windows. Since long the default PHP charset is UTF-8, however the Windows part is out of step with this important point. The current implementation in PHP doesn't technically permit to handle UTF-8 filepath and several other things. Till now, only the ANSI compatible APIs are being used. Here is more about it https://msdn.microsoft.com/en-us/library/windows/desktop/dd317752%28v=vs.85%29.aspx The patch fixes not only issues with multibyte filenames under incompatible codepages, but indirectly also issues with some other multibyte encodings like BIG5, Shift-JIS, etc. by providing a clean way to access filenames in UTF-8. Below is a small list of issues from the bug tracker, that are getting fixed: https://bugs.php.net/63401 https://bugs.php.net/41199 https://bugs.php.net/50203 https://bugs.php.net/71509 https://bugs.php.net/64699 https://bugs.php.net/64506 https://bugs.php.net/30195 https://bugs.php.net/65358 https://bugs.php.net/61315 https://bugs.php.net/70943 https://bugs.php.net/70903 https://bugs.php.net/63593 https://bugs.php.net/54977 https://bugs.php.net/54028 https://bugs.php.net/43148 https://bugs.php.net/30730 https://bugs.php.net/33350 https://bugs.php.net/35300 https://bugs.php.net/46990 https://bugs.php.net/61309 https://bugs.php.net/69333 https://bugs.php.net/45517 https://bugs.php.net/70551 https://bugs.php.net/50197 https://bugs.php.net/72200 https://bugs.php.net/37672 Yet more related tickets can for sure be found - on bugs.php.net, Stackoverflow and Github. Some of the bugs are pretty recent, some descend to early 2000th, but the user comments in there last even till today. Just for example, bug #30195 was opened in 2004, the latest comment in there was made in 2014. It is certain, that these bugs descend not only to pure PHP use cases, but get also redirected from the popular PHP based projects. Given the modern systems (and those supported by PHP) are always based on NTFS, there is no excuse to keep these issues unresolved. The internalization approach on Windows is in many ways different from UNIX and Linux, while it supports and is based on Unicode. It depends on the current system code page, APIs used and exact kind how the binary was compiled The locale doesn't affect the way Unicode or ANSI API work. PHP in particular is being compiled without _UNICODE defined and this is conditioned by the way we handle strings. Here is more about it https://msdn.microsoft.com/en-us/library/tsbaswba.aspx However, with any system code page ANSI functions automatically convert paths to UTF-16. Paths in some encodings incompatible with the current system code page, won't work correctly with ANSI APIs. PHP till now only uses the ANSI Windows APIs. For example, on a system with the current code page 1252, the paths in cp1252 are supported and transparently converted to UTF-16 by the ANSI functions. Once one wants to handle a filepath encoded with cp932 on that particular system, an ANSI or a POSIX compatible function used in PHP will produce an erroneous result. When trying to convert that cp932 path to UTF-8 and passing to the ANSI functions, an ANSI function would likely interpret the UTF-8 string as some string in the current code page and create a filepath that represents every single byte of the UTF-8 string. These behaviors are not only broken but also disregard the documented INI settings. This patch solves the issies with the multibyte paths on Windows by intelligently enforcing the usage of the Unicode aware APIs. For functions expect Unicode (fe CreateFileW, FindFirstFileW, etc.), arguments will be converted to UTF-16 wide chars. For functions returning Unicode aware data (fe GetCurrentDirectoryW, etc.), resulting wide string is converted back to char's depending on the current PHP charset settings, either to the current ANSI codepage (this is the behavior prior to this patch) or to UTF-8 (the default behavior). In a particular case, users might have to explicitly set internal_encoding or default_charset, if filenames in ANSI codepage are necessary. Current tests show no regressions and witness that this will be an exotic case, the current default UTF-8 encoding is compatible with any supported system. The dependency libraries are long switching to Unicode APIs, so some tests were also added for extensions not directly related to streams. At large, the patch brings over 150 related tests into the core. Those target and was run on various environments with European, Asian, etc. codepages. General PHP frameworks was tested and showed no regressions. The impact on the current C code base is low, the most places affected are the Windows only places in the three files tsrm_win32.c, zend_virtual_cwd.c and plain_wrapper.c. The actual implementation of the most of the wide char supporting functionality is in win32/ioutil.* and win32/codepage.*, several low level functionsare extended in place to avoid reimplementation for now. No performance impact was sighted. As previously mentioned, the ANSI APIs used prior the patch perform Unicode conversions internally. Using the Unicode APIs directly while doing custom conversions just retains the status quo. The ways to optimize it are open (fe. by implementing caching for the strings converted to wide variants). The long path implementation is user transparent. If a path exceeds the length of _MAX_PATH, it'll be automatically prefixed with \\?\. The MAXPATHLEN is set to 2048 bytes. Appreciation to Pierre Joye, Matt Ficken, @algo13 and others for tips, ideas and testing. Thanks.
2016-06-20 07:32:19 +00:00
wchar_t *pathw = NULL;
#define FREE_PATHW() \
do { free(pathw); } while(0);
#else
zend_stat_t st;
#endif
realpath_cache_bucket *bucket;
char *tmp;
ALLOCA_FLAG(use_heap)
while (1) {
if (len <= start) {
if (link_is_dir) {
*link_is_dir = 1;
}
return start;
}
i = len;
while (i > start && !IS_SLASH(path[i-1])) {
i--;
}
if (i == len ||
(i == len - 1 && path[i] == '.')) {
/* remove double slashes and '.' */
len = i - 1;
is_dir = 1;
continue;
} else if (i == len - 2 && path[i] == '.' && path[i+1] == '.') {
/* remove '..' and previous directory */
is_dir = 1;
if (link_is_dir) {
*link_is_dir = 1;
}
if (i - 1 <= start) {
return start ? start : len;
}
2014-12-13 22:06:14 +00:00
j = tsrm_realpath_r(path, start, i-1, ll, t, use_realpath, 1, NULL);
if (j > start) {
j--;
while (j > start && !IS_SLASH(path[j])) {
j--;
}
if (!start) {
/* leading '..' must not be removed in case of relative path */
if (j == 0 && path[0] == '.' && path[1] == '.' &&
2010-08-27 10:09:52 +00:00
IS_SLASH(path[2])) {
path[3] = '.';
path[4] = '.';
path[5] = DEFAULT_SLASH;
j = 5;
2010-09-10 14:02:19 +00:00
} else if (j > 0 &&
2010-08-27 10:09:52 +00:00
path[j+1] == '.' && path[j+2] == '.' &&
IS_SLASH(path[j+3])) {
j += 4;
path[j++] = '.';
path[j++] = '.';
path[j] = DEFAULT_SLASH;
}
}
} else if (!start && !j) {
/* leading '..' must not be removed in case of relative path */
path[0] = '.';
path[1] = '.';
path[2] = DEFAULT_SLASH;
j = 2;
}
return j;
}
2010-09-10 14:02:19 +00:00
path[len] = 0;
save = (use_realpath != CWD_EXPAND);
if (start && save && CWDG(realpath_cache_size_limit)) {
/* cache lookup for absolute path */
if (!*t) {
*t = time(0);
}
2014-12-13 22:06:14 +00:00
if ((bucket = realpath_cache_find(path, len, *t)) != NULL) {
2010-08-27 10:09:52 +00:00
if (is_dir && !bucket->is_dir) {
/* not a directory */
return -1;
2010-08-27 10:09:52 +00:00
} else {
if (link_is_dir) {
*link_is_dir = bucket->is_dir;
}
memcpy(path, bucket->realpath, bucket->realpath_len + 1);
2010-08-27 10:09:52 +00:00
return bucket->realpath_len;
}
2010-08-27 10:09:52 +00:00
}
}
#ifdef ZEND_WIN32
Fixed the UTF-8 and long path support in the streams on Windows. Since long the default PHP charset is UTF-8, however the Windows part is out of step with this important point. The current implementation in PHP doesn't technically permit to handle UTF-8 filepath and several other things. Till now, only the ANSI compatible APIs are being used. Here is more about it https://msdn.microsoft.com/en-us/library/windows/desktop/dd317752%28v=vs.85%29.aspx The patch fixes not only issues with multibyte filenames under incompatible codepages, but indirectly also issues with some other multibyte encodings like BIG5, Shift-JIS, etc. by providing a clean way to access filenames in UTF-8. Below is a small list of issues from the bug tracker, that are getting fixed: https://bugs.php.net/63401 https://bugs.php.net/41199 https://bugs.php.net/50203 https://bugs.php.net/71509 https://bugs.php.net/64699 https://bugs.php.net/64506 https://bugs.php.net/30195 https://bugs.php.net/65358 https://bugs.php.net/61315 https://bugs.php.net/70943 https://bugs.php.net/70903 https://bugs.php.net/63593 https://bugs.php.net/54977 https://bugs.php.net/54028 https://bugs.php.net/43148 https://bugs.php.net/30730 https://bugs.php.net/33350 https://bugs.php.net/35300 https://bugs.php.net/46990 https://bugs.php.net/61309 https://bugs.php.net/69333 https://bugs.php.net/45517 https://bugs.php.net/70551 https://bugs.php.net/50197 https://bugs.php.net/72200 https://bugs.php.net/37672 Yet more related tickets can for sure be found - on bugs.php.net, Stackoverflow and Github. Some of the bugs are pretty recent, some descend to early 2000th, but the user comments in there last even till today. Just for example, bug #30195 was opened in 2004, the latest comment in there was made in 2014. It is certain, that these bugs descend not only to pure PHP use cases, but get also redirected from the popular PHP based projects. Given the modern systems (and those supported by PHP) are always based on NTFS, there is no excuse to keep these issues unresolved. The internalization approach on Windows is in many ways different from UNIX and Linux, while it supports and is based on Unicode. It depends on the current system code page, APIs used and exact kind how the binary was compiled The locale doesn't affect the way Unicode or ANSI API work. PHP in particular is being compiled without _UNICODE defined and this is conditioned by the way we handle strings. Here is more about it https://msdn.microsoft.com/en-us/library/tsbaswba.aspx However, with any system code page ANSI functions automatically convert paths to UTF-16. Paths in some encodings incompatible with the current system code page, won't work correctly with ANSI APIs. PHP till now only uses the ANSI Windows APIs. For example, on a system with the current code page 1252, the paths in cp1252 are supported and transparently converted to UTF-16 by the ANSI functions. Once one wants to handle a filepath encoded with cp932 on that particular system, an ANSI or a POSIX compatible function used in PHP will produce an erroneous result. When trying to convert that cp932 path to UTF-8 and passing to the ANSI functions, an ANSI function would likely interpret the UTF-8 string as some string in the current code page and create a filepath that represents every single byte of the UTF-8 string. These behaviors are not only broken but also disregard the documented INI settings. This patch solves the issies with the multibyte paths on Windows by intelligently enforcing the usage of the Unicode aware APIs. For functions expect Unicode (fe CreateFileW, FindFirstFileW, etc.), arguments will be converted to UTF-16 wide chars. For functions returning Unicode aware data (fe GetCurrentDirectoryW, etc.), resulting wide string is converted back to char's depending on the current PHP charset settings, either to the current ANSI codepage (this is the behavior prior to this patch) or to UTF-8 (the default behavior). In a particular case, users might have to explicitly set internal_encoding or default_charset, if filenames in ANSI codepage are necessary. Current tests show no regressions and witness that this will be an exotic case, the current default UTF-8 encoding is compatible with any supported system. The dependency libraries are long switching to Unicode APIs, so some tests were also added for extensions not directly related to streams. At large, the patch brings over 150 related tests into the core. Those target and was run on various environments with European, Asian, etc. codepages. General PHP frameworks was tested and showed no regressions. The impact on the current C code base is low, the most places affected are the Windows only places in the three files tsrm_win32.c, zend_virtual_cwd.c and plain_wrapper.c. The actual implementation of the most of the wide char supporting functionality is in win32/ioutil.* and win32/codepage.*, several low level functionsare extended in place to avoid reimplementation for now. No performance impact was sighted. As previously mentioned, the ANSI APIs used prior the patch perform Unicode conversions internally. Using the Unicode APIs directly while doing custom conversions just retains the status quo. The ways to optimize it are open (fe. by implementing caching for the strings converted to wide variants). The long path implementation is user transparent. If a path exceeds the length of _MAX_PATH, it'll be automatically prefixed with \\?\. The MAXPATHLEN is set to 2048 bytes. Appreciation to Pierre Joye, Matt Ficken, @algo13 and others for tips, ideas and testing. Thanks.
2016-06-20 07:32:19 +00:00
if (save) {
pathw = php_win32_ioutil_any_to_w(path);
if (!pathw) {
return -1;
}
hFind = FindFirstFileExW(pathw, FindExInfoBasic, &dataw, FindExSearchNameMatch, NULL, 0);
Fixed the UTF-8 and long path support in the streams on Windows. Since long the default PHP charset is UTF-8, however the Windows part is out of step with this important point. The current implementation in PHP doesn't technically permit to handle UTF-8 filepath and several other things. Till now, only the ANSI compatible APIs are being used. Here is more about it https://msdn.microsoft.com/en-us/library/windows/desktop/dd317752%28v=vs.85%29.aspx The patch fixes not only issues with multibyte filenames under incompatible codepages, but indirectly also issues with some other multibyte encodings like BIG5, Shift-JIS, etc. by providing a clean way to access filenames in UTF-8. Below is a small list of issues from the bug tracker, that are getting fixed: https://bugs.php.net/63401 https://bugs.php.net/41199 https://bugs.php.net/50203 https://bugs.php.net/71509 https://bugs.php.net/64699 https://bugs.php.net/64506 https://bugs.php.net/30195 https://bugs.php.net/65358 https://bugs.php.net/61315 https://bugs.php.net/70943 https://bugs.php.net/70903 https://bugs.php.net/63593 https://bugs.php.net/54977 https://bugs.php.net/54028 https://bugs.php.net/43148 https://bugs.php.net/30730 https://bugs.php.net/33350 https://bugs.php.net/35300 https://bugs.php.net/46990 https://bugs.php.net/61309 https://bugs.php.net/69333 https://bugs.php.net/45517 https://bugs.php.net/70551 https://bugs.php.net/50197 https://bugs.php.net/72200 https://bugs.php.net/37672 Yet more related tickets can for sure be found - on bugs.php.net, Stackoverflow and Github. Some of the bugs are pretty recent, some descend to early 2000th, but the user comments in there last even till today. Just for example, bug #30195 was opened in 2004, the latest comment in there was made in 2014. It is certain, that these bugs descend not only to pure PHP use cases, but get also redirected from the popular PHP based projects. Given the modern systems (and those supported by PHP) are always based on NTFS, there is no excuse to keep these issues unresolved. The internalization approach on Windows is in many ways different from UNIX and Linux, while it supports and is based on Unicode. It depends on the current system code page, APIs used and exact kind how the binary was compiled The locale doesn't affect the way Unicode or ANSI API work. PHP in particular is being compiled without _UNICODE defined and this is conditioned by the way we handle strings. Here is more about it https://msdn.microsoft.com/en-us/library/tsbaswba.aspx However, with any system code page ANSI functions automatically convert paths to UTF-16. Paths in some encodings incompatible with the current system code page, won't work correctly with ANSI APIs. PHP till now only uses the ANSI Windows APIs. For example, on a system with the current code page 1252, the paths in cp1252 are supported and transparently converted to UTF-16 by the ANSI functions. Once one wants to handle a filepath encoded with cp932 on that particular system, an ANSI or a POSIX compatible function used in PHP will produce an erroneous result. When trying to convert that cp932 path to UTF-8 and passing to the ANSI functions, an ANSI function would likely interpret the UTF-8 string as some string in the current code page and create a filepath that represents every single byte of the UTF-8 string. These behaviors are not only broken but also disregard the documented INI settings. This patch solves the issies with the multibyte paths on Windows by intelligently enforcing the usage of the Unicode aware APIs. For functions expect Unicode (fe CreateFileW, FindFirstFileW, etc.), arguments will be converted to UTF-16 wide chars. For functions returning Unicode aware data (fe GetCurrentDirectoryW, etc.), resulting wide string is converted back to char's depending on the current PHP charset settings, either to the current ANSI codepage (this is the behavior prior to this patch) or to UTF-8 (the default behavior). In a particular case, users might have to explicitly set internal_encoding or default_charset, if filenames in ANSI codepage are necessary. Current tests show no regressions and witness that this will be an exotic case, the current default UTF-8 encoding is compatible with any supported system. The dependency libraries are long switching to Unicode APIs, so some tests were also added for extensions not directly related to streams. At large, the patch brings over 150 related tests into the core. Those target and was run on various environments with European, Asian, etc. codepages. General PHP frameworks was tested and showed no regressions. The impact on the current C code base is low, the most places affected are the Windows only places in the three files tsrm_win32.c, zend_virtual_cwd.c and plain_wrapper.c. The actual implementation of the most of the wide char supporting functionality is in win32/ioutil.* and win32/codepage.*, several low level functionsare extended in place to avoid reimplementation for now. No performance impact was sighted. As previously mentioned, the ANSI APIs used prior the patch perform Unicode conversions internally. Using the Unicode APIs directly while doing custom conversions just retains the status quo. The ways to optimize it are open (fe. by implementing caching for the strings converted to wide variants). The long path implementation is user transparent. If a path exceeds the length of _MAX_PATH, it'll be automatically prefixed with \\?\. The MAXPATHLEN is set to 2048 bytes. Appreciation to Pierre Joye, Matt Ficken, @algo13 and others for tips, ideas and testing. Thanks.
2016-06-20 07:32:19 +00:00
if (INVALID_HANDLE_VALUE == hFind) {
if (use_realpath == CWD_REALPATH) {
/* file not found */
FREE_PATHW()
return -1;
}
/* continue resolution anyway but don't save result in the cache */
save = 0;
} else {
FindClose(hFind);
}
}
tmp = do_alloca(len+1, use_heap);
memcpy(tmp, path, len+1);
2010-09-10 14:02:19 +00:00
if(save &&
2011-01-10 00:59:19 +00:00
!(IS_UNC_PATH(path, len) && len >= 3 && path[2] != '?') &&
Fixed the UTF-8 and long path support in the streams on Windows. Since long the default PHP charset is UTF-8, however the Windows part is out of step with this important point. The current implementation in PHP doesn't technically permit to handle UTF-8 filepath and several other things. Till now, only the ANSI compatible APIs are being used. Here is more about it https://msdn.microsoft.com/en-us/library/windows/desktop/dd317752%28v=vs.85%29.aspx The patch fixes not only issues with multibyte filenames under incompatible codepages, but indirectly also issues with some other multibyte encodings like BIG5, Shift-JIS, etc. by providing a clean way to access filenames in UTF-8. Below is a small list of issues from the bug tracker, that are getting fixed: https://bugs.php.net/63401 https://bugs.php.net/41199 https://bugs.php.net/50203 https://bugs.php.net/71509 https://bugs.php.net/64699 https://bugs.php.net/64506 https://bugs.php.net/30195 https://bugs.php.net/65358 https://bugs.php.net/61315 https://bugs.php.net/70943 https://bugs.php.net/70903 https://bugs.php.net/63593 https://bugs.php.net/54977 https://bugs.php.net/54028 https://bugs.php.net/43148 https://bugs.php.net/30730 https://bugs.php.net/33350 https://bugs.php.net/35300 https://bugs.php.net/46990 https://bugs.php.net/61309 https://bugs.php.net/69333 https://bugs.php.net/45517 https://bugs.php.net/70551 https://bugs.php.net/50197 https://bugs.php.net/72200 https://bugs.php.net/37672 Yet more related tickets can for sure be found - on bugs.php.net, Stackoverflow and Github. Some of the bugs are pretty recent, some descend to early 2000th, but the user comments in there last even till today. Just for example, bug #30195 was opened in 2004, the latest comment in there was made in 2014. It is certain, that these bugs descend not only to pure PHP use cases, but get also redirected from the popular PHP based projects. Given the modern systems (and those supported by PHP) are always based on NTFS, there is no excuse to keep these issues unresolved. The internalization approach on Windows is in many ways different from UNIX and Linux, while it supports and is based on Unicode. It depends on the current system code page, APIs used and exact kind how the binary was compiled The locale doesn't affect the way Unicode or ANSI API work. PHP in particular is being compiled without _UNICODE defined and this is conditioned by the way we handle strings. Here is more about it https://msdn.microsoft.com/en-us/library/tsbaswba.aspx However, with any system code page ANSI functions automatically convert paths to UTF-16. Paths in some encodings incompatible with the current system code page, won't work correctly with ANSI APIs. PHP till now only uses the ANSI Windows APIs. For example, on a system with the current code page 1252, the paths in cp1252 are supported and transparently converted to UTF-16 by the ANSI functions. Once one wants to handle a filepath encoded with cp932 on that particular system, an ANSI or a POSIX compatible function used in PHP will produce an erroneous result. When trying to convert that cp932 path to UTF-8 and passing to the ANSI functions, an ANSI function would likely interpret the UTF-8 string as some string in the current code page and create a filepath that represents every single byte of the UTF-8 string. These behaviors are not only broken but also disregard the documented INI settings. This patch solves the issies with the multibyte paths on Windows by intelligently enforcing the usage of the Unicode aware APIs. For functions expect Unicode (fe CreateFileW, FindFirstFileW, etc.), arguments will be converted to UTF-16 wide chars. For functions returning Unicode aware data (fe GetCurrentDirectoryW, etc.), resulting wide string is converted back to char's depending on the current PHP charset settings, either to the current ANSI codepage (this is the behavior prior to this patch) or to UTF-8 (the default behavior). In a particular case, users might have to explicitly set internal_encoding or default_charset, if filenames in ANSI codepage are necessary. Current tests show no regressions and witness that this will be an exotic case, the current default UTF-8 encoding is compatible with any supported system. The dependency libraries are long switching to Unicode APIs, so some tests were also added for extensions not directly related to streams. At large, the patch brings over 150 related tests into the core. Those target and was run on various environments with European, Asian, etc. codepages. General PHP frameworks was tested and showed no regressions. The impact on the current C code base is low, the most places affected are the Windows only places in the three files tsrm_win32.c, zend_virtual_cwd.c and plain_wrapper.c. The actual implementation of the most of the wide char supporting functionality is in win32/ioutil.* and win32/codepage.*, several low level functionsare extended in place to avoid reimplementation for now. No performance impact was sighted. As previously mentioned, the ANSI APIs used prior the patch perform Unicode conversions internally. Using the Unicode APIs directly while doing custom conversions just retains the status quo. The ways to optimize it are open (fe. by implementing caching for the strings converted to wide variants). The long path implementation is user transparent. If a path exceeds the length of _MAX_PATH, it'll be automatically prefixed with \\?\. The MAXPATHLEN is set to 2048 bytes. Appreciation to Pierre Joye, Matt Ficken, @algo13 and others for tips, ideas and testing. Thanks.
2016-06-20 07:32:19 +00:00
(dataw.dwFileAttributes & FILE_ATTRIBUTE_REPARSE_POINT)
) {
/* File is a reparse point. Get the target */
HANDLE hLink = NULL;
REPARSE_DATA_BUFFER * pbuffer;
2014-11-18 10:49:06 +00:00
DWORD retlength = 0;
int bufindex = 0, isabsolute = 0;
wchar_t * reparsetarget;
BOOL isVolume = FALSE;
2017-01-21 01:17:06 +00:00
#if VIRTUAL_CWD_DEBUG
char *printname = NULL;
#endif
char *substitutename = NULL;
size_t substitutename_len;
int substitutename_off = 0;
wchar_t tmpsubstname[MAXPATHLEN];
if(++(*ll) > LINK_MAX) {
Fixed the UTF-8 and long path support in the streams on Windows. Since long the default PHP charset is UTF-8, however the Windows part is out of step with this important point. The current implementation in PHP doesn't technically permit to handle UTF-8 filepath and several other things. Till now, only the ANSI compatible APIs are being used. Here is more about it https://msdn.microsoft.com/en-us/library/windows/desktop/dd317752%28v=vs.85%29.aspx The patch fixes not only issues with multibyte filenames under incompatible codepages, but indirectly also issues with some other multibyte encodings like BIG5, Shift-JIS, etc. by providing a clean way to access filenames in UTF-8. Below is a small list of issues from the bug tracker, that are getting fixed: https://bugs.php.net/63401 https://bugs.php.net/41199 https://bugs.php.net/50203 https://bugs.php.net/71509 https://bugs.php.net/64699 https://bugs.php.net/64506 https://bugs.php.net/30195 https://bugs.php.net/65358 https://bugs.php.net/61315 https://bugs.php.net/70943 https://bugs.php.net/70903 https://bugs.php.net/63593 https://bugs.php.net/54977 https://bugs.php.net/54028 https://bugs.php.net/43148 https://bugs.php.net/30730 https://bugs.php.net/33350 https://bugs.php.net/35300 https://bugs.php.net/46990 https://bugs.php.net/61309 https://bugs.php.net/69333 https://bugs.php.net/45517 https://bugs.php.net/70551 https://bugs.php.net/50197 https://bugs.php.net/72200 https://bugs.php.net/37672 Yet more related tickets can for sure be found - on bugs.php.net, Stackoverflow and Github. Some of the bugs are pretty recent, some descend to early 2000th, but the user comments in there last even till today. Just for example, bug #30195 was opened in 2004, the latest comment in there was made in 2014. It is certain, that these bugs descend not only to pure PHP use cases, but get also redirected from the popular PHP based projects. Given the modern systems (and those supported by PHP) are always based on NTFS, there is no excuse to keep these issues unresolved. The internalization approach on Windows is in many ways different from UNIX and Linux, while it supports and is based on Unicode. It depends on the current system code page, APIs used and exact kind how the binary was compiled The locale doesn't affect the way Unicode or ANSI API work. PHP in particular is being compiled without _UNICODE defined and this is conditioned by the way we handle strings. Here is more about it https://msdn.microsoft.com/en-us/library/tsbaswba.aspx However, with any system code page ANSI functions automatically convert paths to UTF-16. Paths in some encodings incompatible with the current system code page, won't work correctly with ANSI APIs. PHP till now only uses the ANSI Windows APIs. For example, on a system with the current code page 1252, the paths in cp1252 are supported and transparently converted to UTF-16 by the ANSI functions. Once one wants to handle a filepath encoded with cp932 on that particular system, an ANSI or a POSIX compatible function used in PHP will produce an erroneous result. When trying to convert that cp932 path to UTF-8 and passing to the ANSI functions, an ANSI function would likely interpret the UTF-8 string as some string in the current code page and create a filepath that represents every single byte of the UTF-8 string. These behaviors are not only broken but also disregard the documented INI settings. This patch solves the issies with the multibyte paths on Windows by intelligently enforcing the usage of the Unicode aware APIs. For functions expect Unicode (fe CreateFileW, FindFirstFileW, etc.), arguments will be converted to UTF-16 wide chars. For functions returning Unicode aware data (fe GetCurrentDirectoryW, etc.), resulting wide string is converted back to char's depending on the current PHP charset settings, either to the current ANSI codepage (this is the behavior prior to this patch) or to UTF-8 (the default behavior). In a particular case, users might have to explicitly set internal_encoding or default_charset, if filenames in ANSI codepage are necessary. Current tests show no regressions and witness that this will be an exotic case, the current default UTF-8 encoding is compatible with any supported system. The dependency libraries are long switching to Unicode APIs, so some tests were also added for extensions not directly related to streams. At large, the patch brings over 150 related tests into the core. Those target and was run on various environments with European, Asian, etc. codepages. General PHP frameworks was tested and showed no regressions. The impact on the current C code base is low, the most places affected are the Windows only places in the three files tsrm_win32.c, zend_virtual_cwd.c and plain_wrapper.c. The actual implementation of the most of the wide char supporting functionality is in win32/ioutil.* and win32/codepage.*, several low level functionsare extended in place to avoid reimplementation for now. No performance impact was sighted. As previously mentioned, the ANSI APIs used prior the patch perform Unicode conversions internally. Using the Unicode APIs directly while doing custom conversions just retains the status quo. The ways to optimize it are open (fe. by implementing caching for the strings converted to wide variants). The long path implementation is user transparent. If a path exceeds the length of _MAX_PATH, it'll be automatically prefixed with \\?\. The MAXPATHLEN is set to 2048 bytes. Appreciation to Pierre Joye, Matt Ficken, @algo13 and others for tips, ideas and testing. Thanks.
2016-06-20 07:32:19 +00:00
free_alloca(tmp, use_heap);
FREE_PATHW()
return -1;
}
Fixed the UTF-8 and long path support in the streams on Windows. Since long the default PHP charset is UTF-8, however the Windows part is out of step with this important point. The current implementation in PHP doesn't technically permit to handle UTF-8 filepath and several other things. Till now, only the ANSI compatible APIs are being used. Here is more about it https://msdn.microsoft.com/en-us/library/windows/desktop/dd317752%28v=vs.85%29.aspx The patch fixes not only issues with multibyte filenames under incompatible codepages, but indirectly also issues with some other multibyte encodings like BIG5, Shift-JIS, etc. by providing a clean way to access filenames in UTF-8. Below is a small list of issues from the bug tracker, that are getting fixed: https://bugs.php.net/63401 https://bugs.php.net/41199 https://bugs.php.net/50203 https://bugs.php.net/71509 https://bugs.php.net/64699 https://bugs.php.net/64506 https://bugs.php.net/30195 https://bugs.php.net/65358 https://bugs.php.net/61315 https://bugs.php.net/70943 https://bugs.php.net/70903 https://bugs.php.net/63593 https://bugs.php.net/54977 https://bugs.php.net/54028 https://bugs.php.net/43148 https://bugs.php.net/30730 https://bugs.php.net/33350 https://bugs.php.net/35300 https://bugs.php.net/46990 https://bugs.php.net/61309 https://bugs.php.net/69333 https://bugs.php.net/45517 https://bugs.php.net/70551 https://bugs.php.net/50197 https://bugs.php.net/72200 https://bugs.php.net/37672 Yet more related tickets can for sure be found - on bugs.php.net, Stackoverflow and Github. Some of the bugs are pretty recent, some descend to early 2000th, but the user comments in there last even till today. Just for example, bug #30195 was opened in 2004, the latest comment in there was made in 2014. It is certain, that these bugs descend not only to pure PHP use cases, but get also redirected from the popular PHP based projects. Given the modern systems (and those supported by PHP) are always based on NTFS, there is no excuse to keep these issues unresolved. The internalization approach on Windows is in many ways different from UNIX and Linux, while it supports and is based on Unicode. It depends on the current system code page, APIs used and exact kind how the binary was compiled The locale doesn't affect the way Unicode or ANSI API work. PHP in particular is being compiled without _UNICODE defined and this is conditioned by the way we handle strings. Here is more about it https://msdn.microsoft.com/en-us/library/tsbaswba.aspx However, with any system code page ANSI functions automatically convert paths to UTF-16. Paths in some encodings incompatible with the current system code page, won't work correctly with ANSI APIs. PHP till now only uses the ANSI Windows APIs. For example, on a system with the current code page 1252, the paths in cp1252 are supported and transparently converted to UTF-16 by the ANSI functions. Once one wants to handle a filepath encoded with cp932 on that particular system, an ANSI or a POSIX compatible function used in PHP will produce an erroneous result. When trying to convert that cp932 path to UTF-8 and passing to the ANSI functions, an ANSI function would likely interpret the UTF-8 string as some string in the current code page and create a filepath that represents every single byte of the UTF-8 string. These behaviors are not only broken but also disregard the documented INI settings. This patch solves the issies with the multibyte paths on Windows by intelligently enforcing the usage of the Unicode aware APIs. For functions expect Unicode (fe CreateFileW, FindFirstFileW, etc.), arguments will be converted to UTF-16 wide chars. For functions returning Unicode aware data (fe GetCurrentDirectoryW, etc.), resulting wide string is converted back to char's depending on the current PHP charset settings, either to the current ANSI codepage (this is the behavior prior to this patch) or to UTF-8 (the default behavior). In a particular case, users might have to explicitly set internal_encoding or default_charset, if filenames in ANSI codepage are necessary. Current tests show no regressions and witness that this will be an exotic case, the current default UTF-8 encoding is compatible with any supported system. The dependency libraries are long switching to Unicode APIs, so some tests were also added for extensions not directly related to streams. At large, the patch brings over 150 related tests into the core. Those target and was run on various environments with European, Asian, etc. codepages. General PHP frameworks was tested and showed no regressions. The impact on the current C code base is low, the most places affected are the Windows only places in the three files tsrm_win32.c, zend_virtual_cwd.c and plain_wrapper.c. The actual implementation of the most of the wide char supporting functionality is in win32/ioutil.* and win32/codepage.*, several low level functionsare extended in place to avoid reimplementation for now. No performance impact was sighted. As previously mentioned, the ANSI APIs used prior the patch perform Unicode conversions internally. Using the Unicode APIs directly while doing custom conversions just retains the status quo. The ways to optimize it are open (fe. by implementing caching for the strings converted to wide variants). The long path implementation is user transparent. If a path exceeds the length of _MAX_PATH, it'll be automatically prefixed with \\?\. The MAXPATHLEN is set to 2048 bytes. Appreciation to Pierre Joye, Matt Ficken, @algo13 and others for tips, ideas and testing. Thanks.
2016-06-20 07:32:19 +00:00
hLink = CreateFileW(pathw, GENERIC_READ, 0, NULL, OPEN_EXISTING, FILE_FLAG_OPEN_REPARSE_POINT|FILE_FLAG_BACKUP_SEMANTICS, NULL);
if(hLink == INVALID_HANDLE_VALUE) {
Fixed the UTF-8 and long path support in the streams on Windows. Since long the default PHP charset is UTF-8, however the Windows part is out of step with this important point. The current implementation in PHP doesn't technically permit to handle UTF-8 filepath and several other things. Till now, only the ANSI compatible APIs are being used. Here is more about it https://msdn.microsoft.com/en-us/library/windows/desktop/dd317752%28v=vs.85%29.aspx The patch fixes not only issues with multibyte filenames under incompatible codepages, but indirectly also issues with some other multibyte encodings like BIG5, Shift-JIS, etc. by providing a clean way to access filenames in UTF-8. Below is a small list of issues from the bug tracker, that are getting fixed: https://bugs.php.net/63401 https://bugs.php.net/41199 https://bugs.php.net/50203 https://bugs.php.net/71509 https://bugs.php.net/64699 https://bugs.php.net/64506 https://bugs.php.net/30195 https://bugs.php.net/65358 https://bugs.php.net/61315 https://bugs.php.net/70943 https://bugs.php.net/70903 https://bugs.php.net/63593 https://bugs.php.net/54977 https://bugs.php.net/54028 https://bugs.php.net/43148 https://bugs.php.net/30730 https://bugs.php.net/33350 https://bugs.php.net/35300 https://bugs.php.net/46990 https://bugs.php.net/61309 https://bugs.php.net/69333 https://bugs.php.net/45517 https://bugs.php.net/70551 https://bugs.php.net/50197 https://bugs.php.net/72200 https://bugs.php.net/37672 Yet more related tickets can for sure be found - on bugs.php.net, Stackoverflow and Github. Some of the bugs are pretty recent, some descend to early 2000th, but the user comments in there last even till today. Just for example, bug #30195 was opened in 2004, the latest comment in there was made in 2014. It is certain, that these bugs descend not only to pure PHP use cases, but get also redirected from the popular PHP based projects. Given the modern systems (and those supported by PHP) are always based on NTFS, there is no excuse to keep these issues unresolved. The internalization approach on Windows is in many ways different from UNIX and Linux, while it supports and is based on Unicode. It depends on the current system code page, APIs used and exact kind how the binary was compiled The locale doesn't affect the way Unicode or ANSI API work. PHP in particular is being compiled without _UNICODE defined and this is conditioned by the way we handle strings. Here is more about it https://msdn.microsoft.com/en-us/library/tsbaswba.aspx However, with any system code page ANSI functions automatically convert paths to UTF-16. Paths in some encodings incompatible with the current system code page, won't work correctly with ANSI APIs. PHP till now only uses the ANSI Windows APIs. For example, on a system with the current code page 1252, the paths in cp1252 are supported and transparently converted to UTF-16 by the ANSI functions. Once one wants to handle a filepath encoded with cp932 on that particular system, an ANSI or a POSIX compatible function used in PHP will produce an erroneous result. When trying to convert that cp932 path to UTF-8 and passing to the ANSI functions, an ANSI function would likely interpret the UTF-8 string as some string in the current code page and create a filepath that represents every single byte of the UTF-8 string. These behaviors are not only broken but also disregard the documented INI settings. This patch solves the issies with the multibyte paths on Windows by intelligently enforcing the usage of the Unicode aware APIs. For functions expect Unicode (fe CreateFileW, FindFirstFileW, etc.), arguments will be converted to UTF-16 wide chars. For functions returning Unicode aware data (fe GetCurrentDirectoryW, etc.), resulting wide string is converted back to char's depending on the current PHP charset settings, either to the current ANSI codepage (this is the behavior prior to this patch) or to UTF-8 (the default behavior). In a particular case, users might have to explicitly set internal_encoding or default_charset, if filenames in ANSI codepage are necessary. Current tests show no regressions and witness that this will be an exotic case, the current default UTF-8 encoding is compatible with any supported system. The dependency libraries are long switching to Unicode APIs, so some tests were also added for extensions not directly related to streams. At large, the patch brings over 150 related tests into the core. Those target and was run on various environments with European, Asian, etc. codepages. General PHP frameworks was tested and showed no regressions. The impact on the current C code base is low, the most places affected are the Windows only places in the three files tsrm_win32.c, zend_virtual_cwd.c and plain_wrapper.c. The actual implementation of the most of the wide char supporting functionality is in win32/ioutil.* and win32/codepage.*, several low level functionsare extended in place to avoid reimplementation for now. No performance impact was sighted. As previously mentioned, the ANSI APIs used prior the patch perform Unicode conversions internally. Using the Unicode APIs directly while doing custom conversions just retains the status quo. The ways to optimize it are open (fe. by implementing caching for the strings converted to wide variants). The long path implementation is user transparent. If a path exceeds the length of _MAX_PATH, it'll be automatically prefixed with \\?\. The MAXPATHLEN is set to 2048 bytes. Appreciation to Pierre Joye, Matt Ficken, @algo13 and others for tips, ideas and testing. Thanks.
2016-06-20 07:32:19 +00:00
free_alloca(tmp, use_heap);
FREE_PATHW()
return -1;
}
pbuffer = (REPARSE_DATA_BUFFER *)do_alloca(MAXIMUM_REPARSE_DATA_BUFFER_SIZE, use_heap_large);
2011-01-10 00:43:08 +00:00
if (pbuffer == NULL) {
2016-05-10 17:59:21 +00:00
CloseHandle(hLink);
Fixed the UTF-8 and long path support in the streams on Windows. Since long the default PHP charset is UTF-8, however the Windows part is out of step with this important point. The current implementation in PHP doesn't technically permit to handle UTF-8 filepath and several other things. Till now, only the ANSI compatible APIs are being used. Here is more about it https://msdn.microsoft.com/en-us/library/windows/desktop/dd317752%28v=vs.85%29.aspx The patch fixes not only issues with multibyte filenames under incompatible codepages, but indirectly also issues with some other multibyte encodings like BIG5, Shift-JIS, etc. by providing a clean way to access filenames in UTF-8. Below is a small list of issues from the bug tracker, that are getting fixed: https://bugs.php.net/63401 https://bugs.php.net/41199 https://bugs.php.net/50203 https://bugs.php.net/71509 https://bugs.php.net/64699 https://bugs.php.net/64506 https://bugs.php.net/30195 https://bugs.php.net/65358 https://bugs.php.net/61315 https://bugs.php.net/70943 https://bugs.php.net/70903 https://bugs.php.net/63593 https://bugs.php.net/54977 https://bugs.php.net/54028 https://bugs.php.net/43148 https://bugs.php.net/30730 https://bugs.php.net/33350 https://bugs.php.net/35300 https://bugs.php.net/46990 https://bugs.php.net/61309 https://bugs.php.net/69333 https://bugs.php.net/45517 https://bugs.php.net/70551 https://bugs.php.net/50197 https://bugs.php.net/72200 https://bugs.php.net/37672 Yet more related tickets can for sure be found - on bugs.php.net, Stackoverflow and Github. Some of the bugs are pretty recent, some descend to early 2000th, but the user comments in there last even till today. Just for example, bug #30195 was opened in 2004, the latest comment in there was made in 2014. It is certain, that these bugs descend not only to pure PHP use cases, but get also redirected from the popular PHP based projects. Given the modern systems (and those supported by PHP) are always based on NTFS, there is no excuse to keep these issues unresolved. The internalization approach on Windows is in many ways different from UNIX and Linux, while it supports and is based on Unicode. It depends on the current system code page, APIs used and exact kind how the binary was compiled The locale doesn't affect the way Unicode or ANSI API work. PHP in particular is being compiled without _UNICODE defined and this is conditioned by the way we handle strings. Here is more about it https://msdn.microsoft.com/en-us/library/tsbaswba.aspx However, with any system code page ANSI functions automatically convert paths to UTF-16. Paths in some encodings incompatible with the current system code page, won't work correctly with ANSI APIs. PHP till now only uses the ANSI Windows APIs. For example, on a system with the current code page 1252, the paths in cp1252 are supported and transparently converted to UTF-16 by the ANSI functions. Once one wants to handle a filepath encoded with cp932 on that particular system, an ANSI or a POSIX compatible function used in PHP will produce an erroneous result. When trying to convert that cp932 path to UTF-8 and passing to the ANSI functions, an ANSI function would likely interpret the UTF-8 string as some string in the current code page and create a filepath that represents every single byte of the UTF-8 string. These behaviors are not only broken but also disregard the documented INI settings. This patch solves the issies with the multibyte paths on Windows by intelligently enforcing the usage of the Unicode aware APIs. For functions expect Unicode (fe CreateFileW, FindFirstFileW, etc.), arguments will be converted to UTF-16 wide chars. For functions returning Unicode aware data (fe GetCurrentDirectoryW, etc.), resulting wide string is converted back to char's depending on the current PHP charset settings, either to the current ANSI codepage (this is the behavior prior to this patch) or to UTF-8 (the default behavior). In a particular case, users might have to explicitly set internal_encoding or default_charset, if filenames in ANSI codepage are necessary. Current tests show no regressions and witness that this will be an exotic case, the current default UTF-8 encoding is compatible with any supported system. The dependency libraries are long switching to Unicode APIs, so some tests were also added for extensions not directly related to streams. At large, the patch brings over 150 related tests into the core. Those target and was run on various environments with European, Asian, etc. codepages. General PHP frameworks was tested and showed no regressions. The impact on the current C code base is low, the most places affected are the Windows only places in the three files tsrm_win32.c, zend_virtual_cwd.c and plain_wrapper.c. The actual implementation of the most of the wide char supporting functionality is in win32/ioutil.* and win32/codepage.*, several low level functionsare extended in place to avoid reimplementation for now. No performance impact was sighted. As previously mentioned, the ANSI APIs used prior the patch perform Unicode conversions internally. Using the Unicode APIs directly while doing custom conversions just retains the status quo. The ways to optimize it are open (fe. by implementing caching for the strings converted to wide variants). The long path implementation is user transparent. If a path exceeds the length of _MAX_PATH, it'll be automatically prefixed with \\?\. The MAXPATHLEN is set to 2048 bytes. Appreciation to Pierre Joye, Matt Ficken, @algo13 and others for tips, ideas and testing. Thanks.
2016-06-20 07:32:19 +00:00
free_alloca(tmp, use_heap);
FREE_PATHW()
2011-01-10 00:43:08 +00:00
return -1;
}
if(!DeviceIoControl(hLink, FSCTL_GET_REPARSE_POINT, NULL, 0, pbuffer, MAXIMUM_REPARSE_DATA_BUFFER_SIZE, &retlength, NULL)) {
free_alloca(pbuffer, use_heap_large);
Fixed the UTF-8 and long path support in the streams on Windows. Since long the default PHP charset is UTF-8, however the Windows part is out of step with this important point. The current implementation in PHP doesn't technically permit to handle UTF-8 filepath and several other things. Till now, only the ANSI compatible APIs are being used. Here is more about it https://msdn.microsoft.com/en-us/library/windows/desktop/dd317752%28v=vs.85%29.aspx The patch fixes not only issues with multibyte filenames under incompatible codepages, but indirectly also issues with some other multibyte encodings like BIG5, Shift-JIS, etc. by providing a clean way to access filenames in UTF-8. Below is a small list of issues from the bug tracker, that are getting fixed: https://bugs.php.net/63401 https://bugs.php.net/41199 https://bugs.php.net/50203 https://bugs.php.net/71509 https://bugs.php.net/64699 https://bugs.php.net/64506 https://bugs.php.net/30195 https://bugs.php.net/65358 https://bugs.php.net/61315 https://bugs.php.net/70943 https://bugs.php.net/70903 https://bugs.php.net/63593 https://bugs.php.net/54977 https://bugs.php.net/54028 https://bugs.php.net/43148 https://bugs.php.net/30730 https://bugs.php.net/33350 https://bugs.php.net/35300 https://bugs.php.net/46990 https://bugs.php.net/61309 https://bugs.php.net/69333 https://bugs.php.net/45517 https://bugs.php.net/70551 https://bugs.php.net/50197 https://bugs.php.net/72200 https://bugs.php.net/37672 Yet more related tickets can for sure be found - on bugs.php.net, Stackoverflow and Github. Some of the bugs are pretty recent, some descend to early 2000th, but the user comments in there last even till today. Just for example, bug #30195 was opened in 2004, the latest comment in there was made in 2014. It is certain, that these bugs descend not only to pure PHP use cases, but get also redirected from the popular PHP based projects. Given the modern systems (and those supported by PHP) are always based on NTFS, there is no excuse to keep these issues unresolved. The internalization approach on Windows is in many ways different from UNIX and Linux, while it supports and is based on Unicode. It depends on the current system code page, APIs used and exact kind how the binary was compiled The locale doesn't affect the way Unicode or ANSI API work. PHP in particular is being compiled without _UNICODE defined and this is conditioned by the way we handle strings. Here is more about it https://msdn.microsoft.com/en-us/library/tsbaswba.aspx However, with any system code page ANSI functions automatically convert paths to UTF-16. Paths in some encodings incompatible with the current system code page, won't work correctly with ANSI APIs. PHP till now only uses the ANSI Windows APIs. For example, on a system with the current code page 1252, the paths in cp1252 are supported and transparently converted to UTF-16 by the ANSI functions. Once one wants to handle a filepath encoded with cp932 on that particular system, an ANSI or a POSIX compatible function used in PHP will produce an erroneous result. When trying to convert that cp932 path to UTF-8 and passing to the ANSI functions, an ANSI function would likely interpret the UTF-8 string as some string in the current code page and create a filepath that represents every single byte of the UTF-8 string. These behaviors are not only broken but also disregard the documented INI settings. This patch solves the issies with the multibyte paths on Windows by intelligently enforcing the usage of the Unicode aware APIs. For functions expect Unicode (fe CreateFileW, FindFirstFileW, etc.), arguments will be converted to UTF-16 wide chars. For functions returning Unicode aware data (fe GetCurrentDirectoryW, etc.), resulting wide string is converted back to char's depending on the current PHP charset settings, either to the current ANSI codepage (this is the behavior prior to this patch) or to UTF-8 (the default behavior). In a particular case, users might have to explicitly set internal_encoding or default_charset, if filenames in ANSI codepage are necessary. Current tests show no regressions and witness that this will be an exotic case, the current default UTF-8 encoding is compatible with any supported system. The dependency libraries are long switching to Unicode APIs, so some tests were also added for extensions not directly related to streams. At large, the patch brings over 150 related tests into the core. Those target and was run on various environments with European, Asian, etc. codepages. General PHP frameworks was tested and showed no regressions. The impact on the current C code base is low, the most places affected are the Windows only places in the three files tsrm_win32.c, zend_virtual_cwd.c and plain_wrapper.c. The actual implementation of the most of the wide char supporting functionality is in win32/ioutil.* and win32/codepage.*, several low level functionsare extended in place to avoid reimplementation for now. No performance impact was sighted. As previously mentioned, the ANSI APIs used prior the patch perform Unicode conversions internally. Using the Unicode APIs directly while doing custom conversions just retains the status quo. The ways to optimize it are open (fe. by implementing caching for the strings converted to wide variants). The long path implementation is user transparent. If a path exceeds the length of _MAX_PATH, it'll be automatically prefixed with \\?\. The MAXPATHLEN is set to 2048 bytes. Appreciation to Pierre Joye, Matt Ficken, @algo13 and others for tips, ideas and testing. Thanks.
2016-06-20 07:32:19 +00:00
free_alloca(tmp, use_heap);
CloseHandle(hLink);
Fixed the UTF-8 and long path support in the streams on Windows. Since long the default PHP charset is UTF-8, however the Windows part is out of step with this important point. The current implementation in PHP doesn't technically permit to handle UTF-8 filepath and several other things. Till now, only the ANSI compatible APIs are being used. Here is more about it https://msdn.microsoft.com/en-us/library/windows/desktop/dd317752%28v=vs.85%29.aspx The patch fixes not only issues with multibyte filenames under incompatible codepages, but indirectly also issues with some other multibyte encodings like BIG5, Shift-JIS, etc. by providing a clean way to access filenames in UTF-8. Below is a small list of issues from the bug tracker, that are getting fixed: https://bugs.php.net/63401 https://bugs.php.net/41199 https://bugs.php.net/50203 https://bugs.php.net/71509 https://bugs.php.net/64699 https://bugs.php.net/64506 https://bugs.php.net/30195 https://bugs.php.net/65358 https://bugs.php.net/61315 https://bugs.php.net/70943 https://bugs.php.net/70903 https://bugs.php.net/63593 https://bugs.php.net/54977 https://bugs.php.net/54028 https://bugs.php.net/43148 https://bugs.php.net/30730 https://bugs.php.net/33350 https://bugs.php.net/35300 https://bugs.php.net/46990 https://bugs.php.net/61309 https://bugs.php.net/69333 https://bugs.php.net/45517 https://bugs.php.net/70551 https://bugs.php.net/50197 https://bugs.php.net/72200 https://bugs.php.net/37672 Yet more related tickets can for sure be found - on bugs.php.net, Stackoverflow and Github. Some of the bugs are pretty recent, some descend to early 2000th, but the user comments in there last even till today. Just for example, bug #30195 was opened in 2004, the latest comment in there was made in 2014. It is certain, that these bugs descend not only to pure PHP use cases, but get also redirected from the popular PHP based projects. Given the modern systems (and those supported by PHP) are always based on NTFS, there is no excuse to keep these issues unresolved. The internalization approach on Windows is in many ways different from UNIX and Linux, while it supports and is based on Unicode. It depends on the current system code page, APIs used and exact kind how the binary was compiled The locale doesn't affect the way Unicode or ANSI API work. PHP in particular is being compiled without _UNICODE defined and this is conditioned by the way we handle strings. Here is more about it https://msdn.microsoft.com/en-us/library/tsbaswba.aspx However, with any system code page ANSI functions automatically convert paths to UTF-16. Paths in some encodings incompatible with the current system code page, won't work correctly with ANSI APIs. PHP till now only uses the ANSI Windows APIs. For example, on a system with the current code page 1252, the paths in cp1252 are supported and transparently converted to UTF-16 by the ANSI functions. Once one wants to handle a filepath encoded with cp932 on that particular system, an ANSI or a POSIX compatible function used in PHP will produce an erroneous result. When trying to convert that cp932 path to UTF-8 and passing to the ANSI functions, an ANSI function would likely interpret the UTF-8 string as some string in the current code page and create a filepath that represents every single byte of the UTF-8 string. These behaviors are not only broken but also disregard the documented INI settings. This patch solves the issies with the multibyte paths on Windows by intelligently enforcing the usage of the Unicode aware APIs. For functions expect Unicode (fe CreateFileW, FindFirstFileW, etc.), arguments will be converted to UTF-16 wide chars. For functions returning Unicode aware data (fe GetCurrentDirectoryW, etc.), resulting wide string is converted back to char's depending on the current PHP charset settings, either to the current ANSI codepage (this is the behavior prior to this patch) or to UTF-8 (the default behavior). In a particular case, users might have to explicitly set internal_encoding or default_charset, if filenames in ANSI codepage are necessary. Current tests show no regressions and witness that this will be an exotic case, the current default UTF-8 encoding is compatible with any supported system. The dependency libraries are long switching to Unicode APIs, so some tests were also added for extensions not directly related to streams. At large, the patch brings over 150 related tests into the core. Those target and was run on various environments with European, Asian, etc. codepages. General PHP frameworks was tested and showed no regressions. The impact on the current C code base is low, the most places affected are the Windows only places in the three files tsrm_win32.c, zend_virtual_cwd.c and plain_wrapper.c. The actual implementation of the most of the wide char supporting functionality is in win32/ioutil.* and win32/codepage.*, several low level functionsare extended in place to avoid reimplementation for now. No performance impact was sighted. As previously mentioned, the ANSI APIs used prior the patch perform Unicode conversions internally. Using the Unicode APIs directly while doing custom conversions just retains the status quo. The ways to optimize it are open (fe. by implementing caching for the strings converted to wide variants). The long path implementation is user transparent. If a path exceeds the length of _MAX_PATH, it'll be automatically prefixed with \\?\. The MAXPATHLEN is set to 2048 bytes. Appreciation to Pierre Joye, Matt Ficken, @algo13 and others for tips, ideas and testing. Thanks.
2016-06-20 07:32:19 +00:00
FREE_PATHW()
return -1;
}
CloseHandle(hLink);
if(pbuffer->ReparseTag == IO_REPARSE_TAG_SYMLINK) {
reparsetarget = pbuffer->SymbolicLinkReparseBuffer.ReparseTarget;
isabsolute = (pbuffer->SymbolicLinkReparseBuffer.Flags == 0) ? 1 : 0;
2017-01-21 01:17:06 +00:00
#if VIRTUAL_CWD_DEBUG
Fixed the UTF-8 and long path support in the streams on Windows. Since long the default PHP charset is UTF-8, however the Windows part is out of step with this important point. The current implementation in PHP doesn't technically permit to handle UTF-8 filepath and several other things. Till now, only the ANSI compatible APIs are being used. Here is more about it https://msdn.microsoft.com/en-us/library/windows/desktop/dd317752%28v=vs.85%29.aspx The patch fixes not only issues with multibyte filenames under incompatible codepages, but indirectly also issues with some other multibyte encodings like BIG5, Shift-JIS, etc. by providing a clean way to access filenames in UTF-8. Below is a small list of issues from the bug tracker, that are getting fixed: https://bugs.php.net/63401 https://bugs.php.net/41199 https://bugs.php.net/50203 https://bugs.php.net/71509 https://bugs.php.net/64699 https://bugs.php.net/64506 https://bugs.php.net/30195 https://bugs.php.net/65358 https://bugs.php.net/61315 https://bugs.php.net/70943 https://bugs.php.net/70903 https://bugs.php.net/63593 https://bugs.php.net/54977 https://bugs.php.net/54028 https://bugs.php.net/43148 https://bugs.php.net/30730 https://bugs.php.net/33350 https://bugs.php.net/35300 https://bugs.php.net/46990 https://bugs.php.net/61309 https://bugs.php.net/69333 https://bugs.php.net/45517 https://bugs.php.net/70551 https://bugs.php.net/50197 https://bugs.php.net/72200 https://bugs.php.net/37672 Yet more related tickets can for sure be found - on bugs.php.net, Stackoverflow and Github. Some of the bugs are pretty recent, some descend to early 2000th, but the user comments in there last even till today. Just for example, bug #30195 was opened in 2004, the latest comment in there was made in 2014. It is certain, that these bugs descend not only to pure PHP use cases, but get also redirected from the popular PHP based projects. Given the modern systems (and those supported by PHP) are always based on NTFS, there is no excuse to keep these issues unresolved. The internalization approach on Windows is in many ways different from UNIX and Linux, while it supports and is based on Unicode. It depends on the current system code page, APIs used and exact kind how the binary was compiled The locale doesn't affect the way Unicode or ANSI API work. PHP in particular is being compiled without _UNICODE defined and this is conditioned by the way we handle strings. Here is more about it https://msdn.microsoft.com/en-us/library/tsbaswba.aspx However, with any system code page ANSI functions automatically convert paths to UTF-16. Paths in some encodings incompatible with the current system code page, won't work correctly with ANSI APIs. PHP till now only uses the ANSI Windows APIs. For example, on a system with the current code page 1252, the paths in cp1252 are supported and transparently converted to UTF-16 by the ANSI functions. Once one wants to handle a filepath encoded with cp932 on that particular system, an ANSI or a POSIX compatible function used in PHP will produce an erroneous result. When trying to convert that cp932 path to UTF-8 and passing to the ANSI functions, an ANSI function would likely interpret the UTF-8 string as some string in the current code page and create a filepath that represents every single byte of the UTF-8 string. These behaviors are not only broken but also disregard the documented INI settings. This patch solves the issies with the multibyte paths on Windows by intelligently enforcing the usage of the Unicode aware APIs. For functions expect Unicode (fe CreateFileW, FindFirstFileW, etc.), arguments will be converted to UTF-16 wide chars. For functions returning Unicode aware data (fe GetCurrentDirectoryW, etc.), resulting wide string is converted back to char's depending on the current PHP charset settings, either to the current ANSI codepage (this is the behavior prior to this patch) or to UTF-8 (the default behavior). In a particular case, users might have to explicitly set internal_encoding or default_charset, if filenames in ANSI codepage are necessary. Current tests show no regressions and witness that this will be an exotic case, the current default UTF-8 encoding is compatible with any supported system. The dependency libraries are long switching to Unicode APIs, so some tests were also added for extensions not directly related to streams. At large, the patch brings over 150 related tests into the core. Those target and was run on various environments with European, Asian, etc. codepages. General PHP frameworks was tested and showed no regressions. The impact on the current C code base is low, the most places affected are the Windows only places in the three files tsrm_win32.c, zend_virtual_cwd.c and plain_wrapper.c. The actual implementation of the most of the wide char supporting functionality is in win32/ioutil.* and win32/codepage.*, several low level functionsare extended in place to avoid reimplementation for now. No performance impact was sighted. As previously mentioned, the ANSI APIs used prior the patch perform Unicode conversions internally. Using the Unicode APIs directly while doing custom conversions just retains the status quo. The ways to optimize it are open (fe. by implementing caching for the strings converted to wide variants). The long path implementation is user transparent. If a path exceeds the length of _MAX_PATH, it'll be automatically prefixed with \\?\. The MAXPATHLEN is set to 2048 bytes. Appreciation to Pierre Joye, Matt Ficken, @algo13 and others for tips, ideas and testing. Thanks.
2016-06-20 07:32:19 +00:00
printname = php_win32_ioutil_w_to_any(reparsetarget + pbuffer->MountPointReparseBuffer.PrintNameOffset / sizeof(WCHAR));
if (!printname) {
free_alloca(pbuffer, use_heap_large);
Fixed the UTF-8 and long path support in the streams on Windows. Since long the default PHP charset is UTF-8, however the Windows part is out of step with this important point. The current implementation in PHP doesn't technically permit to handle UTF-8 filepath and several other things. Till now, only the ANSI compatible APIs are being used. Here is more about it https://msdn.microsoft.com/en-us/library/windows/desktop/dd317752%28v=vs.85%29.aspx The patch fixes not only issues with multibyte filenames under incompatible codepages, but indirectly also issues with some other multibyte encodings like BIG5, Shift-JIS, etc. by providing a clean way to access filenames in UTF-8. Below is a small list of issues from the bug tracker, that are getting fixed: https://bugs.php.net/63401 https://bugs.php.net/41199 https://bugs.php.net/50203 https://bugs.php.net/71509 https://bugs.php.net/64699 https://bugs.php.net/64506 https://bugs.php.net/30195 https://bugs.php.net/65358 https://bugs.php.net/61315 https://bugs.php.net/70943 https://bugs.php.net/70903 https://bugs.php.net/63593 https://bugs.php.net/54977 https://bugs.php.net/54028 https://bugs.php.net/43148 https://bugs.php.net/30730 https://bugs.php.net/33350 https://bugs.php.net/35300 https://bugs.php.net/46990 https://bugs.php.net/61309 https://bugs.php.net/69333 https://bugs.php.net/45517 https://bugs.php.net/70551 https://bugs.php.net/50197 https://bugs.php.net/72200 https://bugs.php.net/37672 Yet more related tickets can for sure be found - on bugs.php.net, Stackoverflow and Github. Some of the bugs are pretty recent, some descend to early 2000th, but the user comments in there last even till today. Just for example, bug #30195 was opened in 2004, the latest comment in there was made in 2014. It is certain, that these bugs descend not only to pure PHP use cases, but get also redirected from the popular PHP based projects. Given the modern systems (and those supported by PHP) are always based on NTFS, there is no excuse to keep these issues unresolved. The internalization approach on Windows is in many ways different from UNIX and Linux, while it supports and is based on Unicode. It depends on the current system code page, APIs used and exact kind how the binary was compiled The locale doesn't affect the way Unicode or ANSI API work. PHP in particular is being compiled without _UNICODE defined and this is conditioned by the way we handle strings. Here is more about it https://msdn.microsoft.com/en-us/library/tsbaswba.aspx However, with any system code page ANSI functions automatically convert paths to UTF-16. Paths in some encodings incompatible with the current system code page, won't work correctly with ANSI APIs. PHP till now only uses the ANSI Windows APIs. For example, on a system with the current code page 1252, the paths in cp1252 are supported and transparently converted to UTF-16 by the ANSI functions. Once one wants to handle a filepath encoded with cp932 on that particular system, an ANSI or a POSIX compatible function used in PHP will produce an erroneous result. When trying to convert that cp932 path to UTF-8 and passing to the ANSI functions, an ANSI function would likely interpret the UTF-8 string as some string in the current code page and create a filepath that represents every single byte of the UTF-8 string. These behaviors are not only broken but also disregard the documented INI settings. This patch solves the issies with the multibyte paths on Windows by intelligently enforcing the usage of the Unicode aware APIs. For functions expect Unicode (fe CreateFileW, FindFirstFileW, etc.), arguments will be converted to UTF-16 wide chars. For functions returning Unicode aware data (fe GetCurrentDirectoryW, etc.), resulting wide string is converted back to char's depending on the current PHP charset settings, either to the current ANSI codepage (this is the behavior prior to this patch) or to UTF-8 (the default behavior). In a particular case, users might have to explicitly set internal_encoding or default_charset, if filenames in ANSI codepage are necessary. Current tests show no regressions and witness that this will be an exotic case, the current default UTF-8 encoding is compatible with any supported system. The dependency libraries are long switching to Unicode APIs, so some tests were also added for extensions not directly related to streams. At large, the patch brings over 150 related tests into the core. Those target and was run on various environments with European, Asian, etc. codepages. General PHP frameworks was tested and showed no regressions. The impact on the current C code base is low, the most places affected are the Windows only places in the three files tsrm_win32.c, zend_virtual_cwd.c and plain_wrapper.c. The actual implementation of the most of the wide char supporting functionality is in win32/ioutil.* and win32/codepage.*, several low level functionsare extended in place to avoid reimplementation for now. No performance impact was sighted. As previously mentioned, the ANSI APIs used prior the patch perform Unicode conversions internally. Using the Unicode APIs directly while doing custom conversions just retains the status quo. The ways to optimize it are open (fe. by implementing caching for the strings converted to wide variants). The long path implementation is user transparent. If a path exceeds the length of _MAX_PATH, it'll be automatically prefixed with \\?\. The MAXPATHLEN is set to 2048 bytes. Appreciation to Pierre Joye, Matt Ficken, @algo13 and others for tips, ideas and testing. Thanks.
2016-06-20 07:32:19 +00:00
free_alloca(tmp, use_heap);
FREE_PATHW()
return -1;
Fixed the UTF-8 and long path support in the streams on Windows. Since long the default PHP charset is UTF-8, however the Windows part is out of step with this important point. The current implementation in PHP doesn't technically permit to handle UTF-8 filepath and several other things. Till now, only the ANSI compatible APIs are being used. Here is more about it https://msdn.microsoft.com/en-us/library/windows/desktop/dd317752%28v=vs.85%29.aspx The patch fixes not only issues with multibyte filenames under incompatible codepages, but indirectly also issues with some other multibyte encodings like BIG5, Shift-JIS, etc. by providing a clean way to access filenames in UTF-8. Below is a small list of issues from the bug tracker, that are getting fixed: https://bugs.php.net/63401 https://bugs.php.net/41199 https://bugs.php.net/50203 https://bugs.php.net/71509 https://bugs.php.net/64699 https://bugs.php.net/64506 https://bugs.php.net/30195 https://bugs.php.net/65358 https://bugs.php.net/61315 https://bugs.php.net/70943 https://bugs.php.net/70903 https://bugs.php.net/63593 https://bugs.php.net/54977 https://bugs.php.net/54028 https://bugs.php.net/43148 https://bugs.php.net/30730 https://bugs.php.net/33350 https://bugs.php.net/35300 https://bugs.php.net/46990 https://bugs.php.net/61309 https://bugs.php.net/69333 https://bugs.php.net/45517 https://bugs.php.net/70551 https://bugs.php.net/50197 https://bugs.php.net/72200 https://bugs.php.net/37672 Yet more related tickets can for sure be found - on bugs.php.net, Stackoverflow and Github. Some of the bugs are pretty recent, some descend to early 2000th, but the user comments in there last even till today. Just for example, bug #30195 was opened in 2004, the latest comment in there was made in 2014. It is certain, that these bugs descend not only to pure PHP use cases, but get also redirected from the popular PHP based projects. Given the modern systems (and those supported by PHP) are always based on NTFS, there is no excuse to keep these issues unresolved. The internalization approach on Windows is in many ways different from UNIX and Linux, while it supports and is based on Unicode. It depends on the current system code page, APIs used and exact kind how the binary was compiled The locale doesn't affect the way Unicode or ANSI API work. PHP in particular is being compiled without _UNICODE defined and this is conditioned by the way we handle strings. Here is more about it https://msdn.microsoft.com/en-us/library/tsbaswba.aspx However, with any system code page ANSI functions automatically convert paths to UTF-16. Paths in some encodings incompatible with the current system code page, won't work correctly with ANSI APIs. PHP till now only uses the ANSI Windows APIs. For example, on a system with the current code page 1252, the paths in cp1252 are supported and transparently converted to UTF-16 by the ANSI functions. Once one wants to handle a filepath encoded with cp932 on that particular system, an ANSI or a POSIX compatible function used in PHP will produce an erroneous result. When trying to convert that cp932 path to UTF-8 and passing to the ANSI functions, an ANSI function would likely interpret the UTF-8 string as some string in the current code page and create a filepath that represents every single byte of the UTF-8 string. These behaviors are not only broken but also disregard the documented INI settings. This patch solves the issies with the multibyte paths on Windows by intelligently enforcing the usage of the Unicode aware APIs. For functions expect Unicode (fe CreateFileW, FindFirstFileW, etc.), arguments will be converted to UTF-16 wide chars. For functions returning Unicode aware data (fe GetCurrentDirectoryW, etc.), resulting wide string is converted back to char's depending on the current PHP charset settings, either to the current ANSI codepage (this is the behavior prior to this patch) or to UTF-8 (the default behavior). In a particular case, users might have to explicitly set internal_encoding or default_charset, if filenames in ANSI codepage are necessary. Current tests show no regressions and witness that this will be an exotic case, the current default UTF-8 encoding is compatible with any supported system. The dependency libraries are long switching to Unicode APIs, so some tests were also added for extensions not directly related to streams. At large, the patch brings over 150 related tests into the core. Those target and was run on various environments with European, Asian, etc. codepages. General PHP frameworks was tested and showed no regressions. The impact on the current C code base is low, the most places affected are the Windows only places in the three files tsrm_win32.c, zend_virtual_cwd.c and plain_wrapper.c. The actual implementation of the most of the wide char supporting functionality is in win32/ioutil.* and win32/codepage.*, several low level functionsare extended in place to avoid reimplementation for now. No performance impact was sighted. As previously mentioned, the ANSI APIs used prior the patch perform Unicode conversions internally. Using the Unicode APIs directly while doing custom conversions just retains the status quo. The ways to optimize it are open (fe. by implementing caching for the strings converted to wide variants). The long path implementation is user transparent. If a path exceeds the length of _MAX_PATH, it'll be automatically prefixed with \\?\. The MAXPATHLEN is set to 2048 bytes. Appreciation to Pierre Joye, Matt Ficken, @algo13 and others for tips, ideas and testing. Thanks.
2016-06-20 07:32:19 +00:00
}
2017-01-21 01:17:06 +00:00
#endif
substitutename_len = pbuffer->MountPointReparseBuffer.SubstituteNameLength / sizeof(WCHAR);
2017-01-24 12:24:11 +00:00
if (substitutename_len >= MAXPATHLEN) {
free_alloca(pbuffer, use_heap_large);
free_alloca(tmp, use_heap);
FREE_PATHW()
return -1;
}
memmove(tmpsubstname, reparsetarget + pbuffer->MountPointReparseBuffer.SubstituteNameOffset / sizeof(WCHAR), pbuffer->MountPointReparseBuffer.SubstituteNameLength);
tmpsubstname[substitutename_len] = L'\0';
substitutename = php_win32_cp_conv_w_to_any(tmpsubstname, substitutename_len, &substitutename_len);
2017-01-24 12:24:11 +00:00
if (!substitutename || substitutename_len >= MAXPATHLEN) {
free_alloca(pbuffer, use_heap_large);
Fixed the UTF-8 and long path support in the streams on Windows. Since long the default PHP charset is UTF-8, however the Windows part is out of step with this important point. The current implementation in PHP doesn't technically permit to handle UTF-8 filepath and several other things. Till now, only the ANSI compatible APIs are being used. Here is more about it https://msdn.microsoft.com/en-us/library/windows/desktop/dd317752%28v=vs.85%29.aspx The patch fixes not only issues with multibyte filenames under incompatible codepages, but indirectly also issues with some other multibyte encodings like BIG5, Shift-JIS, etc. by providing a clean way to access filenames in UTF-8. Below is a small list of issues from the bug tracker, that are getting fixed: https://bugs.php.net/63401 https://bugs.php.net/41199 https://bugs.php.net/50203 https://bugs.php.net/71509 https://bugs.php.net/64699 https://bugs.php.net/64506 https://bugs.php.net/30195 https://bugs.php.net/65358 https://bugs.php.net/61315 https://bugs.php.net/70943 https://bugs.php.net/70903 https://bugs.php.net/63593 https://bugs.php.net/54977 https://bugs.php.net/54028 https://bugs.php.net/43148 https://bugs.php.net/30730 https://bugs.php.net/33350 https://bugs.php.net/35300 https://bugs.php.net/46990 https://bugs.php.net/61309 https://bugs.php.net/69333 https://bugs.php.net/45517 https://bugs.php.net/70551 https://bugs.php.net/50197 https://bugs.php.net/72200 https://bugs.php.net/37672 Yet more related tickets can for sure be found - on bugs.php.net, Stackoverflow and Github. Some of the bugs are pretty recent, some descend to early 2000th, but the user comments in there last even till today. Just for example, bug #30195 was opened in 2004, the latest comment in there was made in 2014. It is certain, that these bugs descend not only to pure PHP use cases, but get also redirected from the popular PHP based projects. Given the modern systems (and those supported by PHP) are always based on NTFS, there is no excuse to keep these issues unresolved. The internalization approach on Windows is in many ways different from UNIX and Linux, while it supports and is based on Unicode. It depends on the current system code page, APIs used and exact kind how the binary was compiled The locale doesn't affect the way Unicode or ANSI API work. PHP in particular is being compiled without _UNICODE defined and this is conditioned by the way we handle strings. Here is more about it https://msdn.microsoft.com/en-us/library/tsbaswba.aspx However, with any system code page ANSI functions automatically convert paths to UTF-16. Paths in some encodings incompatible with the current system code page, won't work correctly with ANSI APIs. PHP till now only uses the ANSI Windows APIs. For example, on a system with the current code page 1252, the paths in cp1252 are supported and transparently converted to UTF-16 by the ANSI functions. Once one wants to handle a filepath encoded with cp932 on that particular system, an ANSI or a POSIX compatible function used in PHP will produce an erroneous result. When trying to convert that cp932 path to UTF-8 and passing to the ANSI functions, an ANSI function would likely interpret the UTF-8 string as some string in the current code page and create a filepath that represents every single byte of the UTF-8 string. These behaviors are not only broken but also disregard the documented INI settings. This patch solves the issies with the multibyte paths on Windows by intelligently enforcing the usage of the Unicode aware APIs. For functions expect Unicode (fe CreateFileW, FindFirstFileW, etc.), arguments will be converted to UTF-16 wide chars. For functions returning Unicode aware data (fe GetCurrentDirectoryW, etc.), resulting wide string is converted back to char's depending on the current PHP charset settings, either to the current ANSI codepage (this is the behavior prior to this patch) or to UTF-8 (the default behavior). In a particular case, users might have to explicitly set internal_encoding or default_charset, if filenames in ANSI codepage are necessary. Current tests show no regressions and witness that this will be an exotic case, the current default UTF-8 encoding is compatible with any supported system. The dependency libraries are long switching to Unicode APIs, so some tests were also added for extensions not directly related to streams. At large, the patch brings over 150 related tests into the core. Those target and was run on various environments with European, Asian, etc. codepages. General PHP frameworks was tested and showed no regressions. The impact on the current C code base is low, the most places affected are the Windows only places in the three files tsrm_win32.c, zend_virtual_cwd.c and plain_wrapper.c. The actual implementation of the most of the wide char supporting functionality is in win32/ioutil.* and win32/codepage.*, several low level functionsare extended in place to avoid reimplementation for now. No performance impact was sighted. As previously mentioned, the ANSI APIs used prior the patch perform Unicode conversions internally. Using the Unicode APIs directly while doing custom conversions just retains the status quo. The ways to optimize it are open (fe. by implementing caching for the strings converted to wide variants). The long path implementation is user transparent. If a path exceeds the length of _MAX_PATH, it'll be automatically prefixed with \\?\. The MAXPATHLEN is set to 2048 bytes. Appreciation to Pierre Joye, Matt Ficken, @algo13 and others for tips, ideas and testing. Thanks.
2016-06-20 07:32:19 +00:00
free_alloca(tmp, use_heap);
2017-01-24 12:24:11 +00:00
free(substitutename);
2017-01-21 01:17:06 +00:00
#if VIRTUAL_CWD_DEBUG
Fixed the UTF-8 and long path support in the streams on Windows. Since long the default PHP charset is UTF-8, however the Windows part is out of step with this important point. The current implementation in PHP doesn't technically permit to handle UTF-8 filepath and several other things. Till now, only the ANSI compatible APIs are being used. Here is more about it https://msdn.microsoft.com/en-us/library/windows/desktop/dd317752%28v=vs.85%29.aspx The patch fixes not only issues with multibyte filenames under incompatible codepages, but indirectly also issues with some other multibyte encodings like BIG5, Shift-JIS, etc. by providing a clean way to access filenames in UTF-8. Below is a small list of issues from the bug tracker, that are getting fixed: https://bugs.php.net/63401 https://bugs.php.net/41199 https://bugs.php.net/50203 https://bugs.php.net/71509 https://bugs.php.net/64699 https://bugs.php.net/64506 https://bugs.php.net/30195 https://bugs.php.net/65358 https://bugs.php.net/61315 https://bugs.php.net/70943 https://bugs.php.net/70903 https://bugs.php.net/63593 https://bugs.php.net/54977 https://bugs.php.net/54028 https://bugs.php.net/43148 https://bugs.php.net/30730 https://bugs.php.net/33350 https://bugs.php.net/35300 https://bugs.php.net/46990 https://bugs.php.net/61309 https://bugs.php.net/69333 https://bugs.php.net/45517 https://bugs.php.net/70551 https://bugs.php.net/50197 https://bugs.php.net/72200 https://bugs.php.net/37672 Yet more related tickets can for sure be found - on bugs.php.net, Stackoverflow and Github. Some of the bugs are pretty recent, some descend to early 2000th, but the user comments in there last even till today. Just for example, bug #30195 was opened in 2004, the latest comment in there was made in 2014. It is certain, that these bugs descend not only to pure PHP use cases, but get also redirected from the popular PHP based projects. Given the modern systems (and those supported by PHP) are always based on NTFS, there is no excuse to keep these issues unresolved. The internalization approach on Windows is in many ways different from UNIX and Linux, while it supports and is based on Unicode. It depends on the current system code page, APIs used and exact kind how the binary was compiled The locale doesn't affect the way Unicode or ANSI API work. PHP in particular is being compiled without _UNICODE defined and this is conditioned by the way we handle strings. Here is more about it https://msdn.microsoft.com/en-us/library/tsbaswba.aspx However, with any system code page ANSI functions automatically convert paths to UTF-16. Paths in some encodings incompatible with the current system code page, won't work correctly with ANSI APIs. PHP till now only uses the ANSI Windows APIs. For example, on a system with the current code page 1252, the paths in cp1252 are supported and transparently converted to UTF-16 by the ANSI functions. Once one wants to handle a filepath encoded with cp932 on that particular system, an ANSI or a POSIX compatible function used in PHP will produce an erroneous result. When trying to convert that cp932 path to UTF-8 and passing to the ANSI functions, an ANSI function would likely interpret the UTF-8 string as some string in the current code page and create a filepath that represents every single byte of the UTF-8 string. These behaviors are not only broken but also disregard the documented INI settings. This patch solves the issies with the multibyte paths on Windows by intelligently enforcing the usage of the Unicode aware APIs. For functions expect Unicode (fe CreateFileW, FindFirstFileW, etc.), arguments will be converted to UTF-16 wide chars. For functions returning Unicode aware data (fe GetCurrentDirectoryW, etc.), resulting wide string is converted back to char's depending on the current PHP charset settings, either to the current ANSI codepage (this is the behavior prior to this patch) or to UTF-8 (the default behavior). In a particular case, users might have to explicitly set internal_encoding or default_charset, if filenames in ANSI codepage are necessary. Current tests show no regressions and witness that this will be an exotic case, the current default UTF-8 encoding is compatible with any supported system. The dependency libraries are long switching to Unicode APIs, so some tests were also added for extensions not directly related to streams. At large, the patch brings over 150 related tests into the core. Those target and was run on various environments with European, Asian, etc. codepages. General PHP frameworks was tested and showed no regressions. The impact on the current C code base is low, the most places affected are the Windows only places in the three files tsrm_win32.c, zend_virtual_cwd.c and plain_wrapper.c. The actual implementation of the most of the wide char supporting functionality is in win32/ioutil.* and win32/codepage.*, several low level functionsare extended in place to avoid reimplementation for now. No performance impact was sighted. As previously mentioned, the ANSI APIs used prior the patch perform Unicode conversions internally. Using the Unicode APIs directly while doing custom conversions just retains the status quo. The ways to optimize it are open (fe. by implementing caching for the strings converted to wide variants). The long path implementation is user transparent. If a path exceeds the length of _MAX_PATH, it'll be automatically prefixed with \\?\. The MAXPATHLEN is set to 2048 bytes. Appreciation to Pierre Joye, Matt Ficken, @algo13 and others for tips, ideas and testing. Thanks.
2016-06-20 07:32:19 +00:00
free(printname);
2017-01-21 01:17:06 +00:00
#endif
Fixed the UTF-8 and long path support in the streams on Windows. Since long the default PHP charset is UTF-8, however the Windows part is out of step with this important point. The current implementation in PHP doesn't technically permit to handle UTF-8 filepath and several other things. Till now, only the ANSI compatible APIs are being used. Here is more about it https://msdn.microsoft.com/en-us/library/windows/desktop/dd317752%28v=vs.85%29.aspx The patch fixes not only issues with multibyte filenames under incompatible codepages, but indirectly also issues with some other multibyte encodings like BIG5, Shift-JIS, etc. by providing a clean way to access filenames in UTF-8. Below is a small list of issues from the bug tracker, that are getting fixed: https://bugs.php.net/63401 https://bugs.php.net/41199 https://bugs.php.net/50203 https://bugs.php.net/71509 https://bugs.php.net/64699 https://bugs.php.net/64506 https://bugs.php.net/30195 https://bugs.php.net/65358 https://bugs.php.net/61315 https://bugs.php.net/70943 https://bugs.php.net/70903 https://bugs.php.net/63593 https://bugs.php.net/54977 https://bugs.php.net/54028 https://bugs.php.net/43148 https://bugs.php.net/30730 https://bugs.php.net/33350 https://bugs.php.net/35300 https://bugs.php.net/46990 https://bugs.php.net/61309 https://bugs.php.net/69333 https://bugs.php.net/45517 https://bugs.php.net/70551 https://bugs.php.net/50197 https://bugs.php.net/72200 https://bugs.php.net/37672 Yet more related tickets can for sure be found - on bugs.php.net, Stackoverflow and Github. Some of the bugs are pretty recent, some descend to early 2000th, but the user comments in there last even till today. Just for example, bug #30195 was opened in 2004, the latest comment in there was made in 2014. It is certain, that these bugs descend not only to pure PHP use cases, but get also redirected from the popular PHP based projects. Given the modern systems (and those supported by PHP) are always based on NTFS, there is no excuse to keep these issues unresolved. The internalization approach on Windows is in many ways different from UNIX and Linux, while it supports and is based on Unicode. It depends on the current system code page, APIs used and exact kind how the binary was compiled The locale doesn't affect the way Unicode or ANSI API work. PHP in particular is being compiled without _UNICODE defined and this is conditioned by the way we handle strings. Here is more about it https://msdn.microsoft.com/en-us/library/tsbaswba.aspx However, with any system code page ANSI functions automatically convert paths to UTF-16. Paths in some encodings incompatible with the current system code page, won't work correctly with ANSI APIs. PHP till now only uses the ANSI Windows APIs. For example, on a system with the current code page 1252, the paths in cp1252 are supported and transparently converted to UTF-16 by the ANSI functions. Once one wants to handle a filepath encoded with cp932 on that particular system, an ANSI or a POSIX compatible function used in PHP will produce an erroneous result. When trying to convert that cp932 path to UTF-8 and passing to the ANSI functions, an ANSI function would likely interpret the UTF-8 string as some string in the current code page and create a filepath that represents every single byte of the UTF-8 string. These behaviors are not only broken but also disregard the documented INI settings. This patch solves the issies with the multibyte paths on Windows by intelligently enforcing the usage of the Unicode aware APIs. For functions expect Unicode (fe CreateFileW, FindFirstFileW, etc.), arguments will be converted to UTF-16 wide chars. For functions returning Unicode aware data (fe GetCurrentDirectoryW, etc.), resulting wide string is converted back to char's depending on the current PHP charset settings, either to the current ANSI codepage (this is the behavior prior to this patch) or to UTF-8 (the default behavior). In a particular case, users might have to explicitly set internal_encoding or default_charset, if filenames in ANSI codepage are necessary. Current tests show no regressions and witness that this will be an exotic case, the current default UTF-8 encoding is compatible with any supported system. The dependency libraries are long switching to Unicode APIs, so some tests were also added for extensions not directly related to streams. At large, the patch brings over 150 related tests into the core. Those target and was run on various environments with European, Asian, etc. codepages. General PHP frameworks was tested and showed no regressions. The impact on the current C code base is low, the most places affected are the Windows only places in the three files tsrm_win32.c, zend_virtual_cwd.c and plain_wrapper.c. The actual implementation of the most of the wide char supporting functionality is in win32/ioutil.* and win32/codepage.*, several low level functionsare extended in place to avoid reimplementation for now. No performance impact was sighted. As previously mentioned, the ANSI APIs used prior the patch perform Unicode conversions internally. Using the Unicode APIs directly while doing custom conversions just retains the status quo. The ways to optimize it are open (fe. by implementing caching for the strings converted to wide variants). The long path implementation is user transparent. If a path exceeds the length of _MAX_PATH, it'll be automatically prefixed with \\?\. The MAXPATHLEN is set to 2048 bytes. Appreciation to Pierre Joye, Matt Ficken, @algo13 and others for tips, ideas and testing. Thanks.
2016-06-20 07:32:19 +00:00
FREE_PATHW()
return -1;
Fixed the UTF-8 and long path support in the streams on Windows. Since long the default PHP charset is UTF-8, however the Windows part is out of step with this important point. The current implementation in PHP doesn't technically permit to handle UTF-8 filepath and several other things. Till now, only the ANSI compatible APIs are being used. Here is more about it https://msdn.microsoft.com/en-us/library/windows/desktop/dd317752%28v=vs.85%29.aspx The patch fixes not only issues with multibyte filenames under incompatible codepages, but indirectly also issues with some other multibyte encodings like BIG5, Shift-JIS, etc. by providing a clean way to access filenames in UTF-8. Below is a small list of issues from the bug tracker, that are getting fixed: https://bugs.php.net/63401 https://bugs.php.net/41199 https://bugs.php.net/50203 https://bugs.php.net/71509 https://bugs.php.net/64699 https://bugs.php.net/64506 https://bugs.php.net/30195 https://bugs.php.net/65358 https://bugs.php.net/61315 https://bugs.php.net/70943 https://bugs.php.net/70903 https://bugs.php.net/63593 https://bugs.php.net/54977 https://bugs.php.net/54028 https://bugs.php.net/43148 https://bugs.php.net/30730 https://bugs.php.net/33350 https://bugs.php.net/35300 https://bugs.php.net/46990 https://bugs.php.net/61309 https://bugs.php.net/69333 https://bugs.php.net/45517 https://bugs.php.net/70551 https://bugs.php.net/50197 https://bugs.php.net/72200 https://bugs.php.net/37672 Yet more related tickets can for sure be found - on bugs.php.net, Stackoverflow and Github. Some of the bugs are pretty recent, some descend to early 2000th, but the user comments in there last even till today. Just for example, bug #30195 was opened in 2004, the latest comment in there was made in 2014. It is certain, that these bugs descend not only to pure PHP use cases, but get also redirected from the popular PHP based projects. Given the modern systems (and those supported by PHP) are always based on NTFS, there is no excuse to keep these issues unresolved. The internalization approach on Windows is in many ways different from UNIX and Linux, while it supports and is based on Unicode. It depends on the current system code page, APIs used and exact kind how the binary was compiled The locale doesn't affect the way Unicode or ANSI API work. PHP in particular is being compiled without _UNICODE defined and this is conditioned by the way we handle strings. Here is more about it https://msdn.microsoft.com/en-us/library/tsbaswba.aspx However, with any system code page ANSI functions automatically convert paths to UTF-16. Paths in some encodings incompatible with the current system code page, won't work correctly with ANSI APIs. PHP till now only uses the ANSI Windows APIs. For example, on a system with the current code page 1252, the paths in cp1252 are supported and transparently converted to UTF-16 by the ANSI functions. Once one wants to handle a filepath encoded with cp932 on that particular system, an ANSI or a POSIX compatible function used in PHP will produce an erroneous result. When trying to convert that cp932 path to UTF-8 and passing to the ANSI functions, an ANSI function would likely interpret the UTF-8 string as some string in the current code page and create a filepath that represents every single byte of the UTF-8 string. These behaviors are not only broken but also disregard the documented INI settings. This patch solves the issies with the multibyte paths on Windows by intelligently enforcing the usage of the Unicode aware APIs. For functions expect Unicode (fe CreateFileW, FindFirstFileW, etc.), arguments will be converted to UTF-16 wide chars. For functions returning Unicode aware data (fe GetCurrentDirectoryW, etc.), resulting wide string is converted back to char's depending on the current PHP charset settings, either to the current ANSI codepage (this is the behavior prior to this patch) or to UTF-8 (the default behavior). In a particular case, users might have to explicitly set internal_encoding or default_charset, if filenames in ANSI codepage are necessary. Current tests show no regressions and witness that this will be an exotic case, the current default UTF-8 encoding is compatible with any supported system. The dependency libraries are long switching to Unicode APIs, so some tests were also added for extensions not directly related to streams. At large, the patch brings over 150 related tests into the core. Those target and was run on various environments with European, Asian, etc. codepages. General PHP frameworks was tested and showed no regressions. The impact on the current C code base is low, the most places affected are the Windows only places in the three files tsrm_win32.c, zend_virtual_cwd.c and plain_wrapper.c. The actual implementation of the most of the wide char supporting functionality is in win32/ioutil.* and win32/codepage.*, several low level functionsare extended in place to avoid reimplementation for now. No performance impact was sighted. As previously mentioned, the ANSI APIs used prior the patch perform Unicode conversions internally. Using the Unicode APIs directly while doing custom conversions just retains the status quo. The ways to optimize it are open (fe. by implementing caching for the strings converted to wide variants). The long path implementation is user transparent. If a path exceeds the length of _MAX_PATH, it'll be automatically prefixed with \\?\. The MAXPATHLEN is set to 2048 bytes. Appreciation to Pierre Joye, Matt Ficken, @algo13 and others for tips, ideas and testing. Thanks.
2016-06-20 07:32:19 +00:00
}
}
else if(pbuffer->ReparseTag == IO_REPARSE_TAG_MOUNT_POINT) {
isabsolute = 1;
reparsetarget = pbuffer->MountPointReparseBuffer.ReparseTarget;
2017-01-21 01:17:06 +00:00
#if VIRTUAL_CWD_DEBUG
Fixed the UTF-8 and long path support in the streams on Windows. Since long the default PHP charset is UTF-8, however the Windows part is out of step with this important point. The current implementation in PHP doesn't technically permit to handle UTF-8 filepath and several other things. Till now, only the ANSI compatible APIs are being used. Here is more about it https://msdn.microsoft.com/en-us/library/windows/desktop/dd317752%28v=vs.85%29.aspx The patch fixes not only issues with multibyte filenames under incompatible codepages, but indirectly also issues with some other multibyte encodings like BIG5, Shift-JIS, etc. by providing a clean way to access filenames in UTF-8. Below is a small list of issues from the bug tracker, that are getting fixed: https://bugs.php.net/63401 https://bugs.php.net/41199 https://bugs.php.net/50203 https://bugs.php.net/71509 https://bugs.php.net/64699 https://bugs.php.net/64506 https://bugs.php.net/30195 https://bugs.php.net/65358 https://bugs.php.net/61315 https://bugs.php.net/70943 https://bugs.php.net/70903 https://bugs.php.net/63593 https://bugs.php.net/54977 https://bugs.php.net/54028 https://bugs.php.net/43148 https://bugs.php.net/30730 https://bugs.php.net/33350 https://bugs.php.net/35300 https://bugs.php.net/46990 https://bugs.php.net/61309 https://bugs.php.net/69333 https://bugs.php.net/45517 https://bugs.php.net/70551 https://bugs.php.net/50197 https://bugs.php.net/72200 https://bugs.php.net/37672 Yet more related tickets can for sure be found - on bugs.php.net, Stackoverflow and Github. Some of the bugs are pretty recent, some descend to early 2000th, but the user comments in there last even till today. Just for example, bug #30195 was opened in 2004, the latest comment in there was made in 2014. It is certain, that these bugs descend not only to pure PHP use cases, but get also redirected from the popular PHP based projects. Given the modern systems (and those supported by PHP) are always based on NTFS, there is no excuse to keep these issues unresolved. The internalization approach on Windows is in many ways different from UNIX and Linux, while it supports and is based on Unicode. It depends on the current system code page, APIs used and exact kind how the binary was compiled The locale doesn't affect the way Unicode or ANSI API work. PHP in particular is being compiled without _UNICODE defined and this is conditioned by the way we handle strings. Here is more about it https://msdn.microsoft.com/en-us/library/tsbaswba.aspx However, with any system code page ANSI functions automatically convert paths to UTF-16. Paths in some encodings incompatible with the current system code page, won't work correctly with ANSI APIs. PHP till now only uses the ANSI Windows APIs. For example, on a system with the current code page 1252, the paths in cp1252 are supported and transparently converted to UTF-16 by the ANSI functions. Once one wants to handle a filepath encoded with cp932 on that particular system, an ANSI or a POSIX compatible function used in PHP will produce an erroneous result. When trying to convert that cp932 path to UTF-8 and passing to the ANSI functions, an ANSI function would likely interpret the UTF-8 string as some string in the current code page and create a filepath that represents every single byte of the UTF-8 string. These behaviors are not only broken but also disregard the documented INI settings. This patch solves the issies with the multibyte paths on Windows by intelligently enforcing the usage of the Unicode aware APIs. For functions expect Unicode (fe CreateFileW, FindFirstFileW, etc.), arguments will be converted to UTF-16 wide chars. For functions returning Unicode aware data (fe GetCurrentDirectoryW, etc.), resulting wide string is converted back to char's depending on the current PHP charset settings, either to the current ANSI codepage (this is the behavior prior to this patch) or to UTF-8 (the default behavior). In a particular case, users might have to explicitly set internal_encoding or default_charset, if filenames in ANSI codepage are necessary. Current tests show no regressions and witness that this will be an exotic case, the current default UTF-8 encoding is compatible with any supported system. The dependency libraries are long switching to Unicode APIs, so some tests were also added for extensions not directly related to streams. At large, the patch brings over 150 related tests into the core. Those target and was run on various environments with European, Asian, etc. codepages. General PHP frameworks was tested and showed no regressions. The impact on the current C code base is low, the most places affected are the Windows only places in the three files tsrm_win32.c, zend_virtual_cwd.c and plain_wrapper.c. The actual implementation of the most of the wide char supporting functionality is in win32/ioutil.* and win32/codepage.*, several low level functionsare extended in place to avoid reimplementation for now. No performance impact was sighted. As previously mentioned, the ANSI APIs used prior the patch perform Unicode conversions internally. Using the Unicode APIs directly while doing custom conversions just retains the status quo. The ways to optimize it are open (fe. by implementing caching for the strings converted to wide variants). The long path implementation is user transparent. If a path exceeds the length of _MAX_PATH, it'll be automatically prefixed with \\?\. The MAXPATHLEN is set to 2048 bytes. Appreciation to Pierre Joye, Matt Ficken, @algo13 and others for tips, ideas and testing. Thanks.
2016-06-20 07:32:19 +00:00
printname = php_win32_ioutil_w_to_any(reparsetarget + pbuffer->MountPointReparseBuffer.PrintNameOffset / sizeof(WCHAR));
if (!printname) {
free_alloca(pbuffer, use_heap_large);
Fixed the UTF-8 and long path support in the streams on Windows. Since long the default PHP charset is UTF-8, however the Windows part is out of step with this important point. The current implementation in PHP doesn't technically permit to handle UTF-8 filepath and several other things. Till now, only the ANSI compatible APIs are being used. Here is more about it https://msdn.microsoft.com/en-us/library/windows/desktop/dd317752%28v=vs.85%29.aspx The patch fixes not only issues with multibyte filenames under incompatible codepages, but indirectly also issues with some other multibyte encodings like BIG5, Shift-JIS, etc. by providing a clean way to access filenames in UTF-8. Below is a small list of issues from the bug tracker, that are getting fixed: https://bugs.php.net/63401 https://bugs.php.net/41199 https://bugs.php.net/50203 https://bugs.php.net/71509 https://bugs.php.net/64699 https://bugs.php.net/64506 https://bugs.php.net/30195 https://bugs.php.net/65358 https://bugs.php.net/61315 https://bugs.php.net/70943 https://bugs.php.net/70903 https://bugs.php.net/63593 https://bugs.php.net/54977 https://bugs.php.net/54028 https://bugs.php.net/43148 https://bugs.php.net/30730 https://bugs.php.net/33350 https://bugs.php.net/35300 https://bugs.php.net/46990 https://bugs.php.net/61309 https://bugs.php.net/69333 https://bugs.php.net/45517 https://bugs.php.net/70551 https://bugs.php.net/50197 https://bugs.php.net/72200 https://bugs.php.net/37672 Yet more related tickets can for sure be found - on bugs.php.net, Stackoverflow and Github. Some of the bugs are pretty recent, some descend to early 2000th, but the user comments in there last even till today. Just for example, bug #30195 was opened in 2004, the latest comment in there was made in 2014. It is certain, that these bugs descend not only to pure PHP use cases, but get also redirected from the popular PHP based projects. Given the modern systems (and those supported by PHP) are always based on NTFS, there is no excuse to keep these issues unresolved. The internalization approach on Windows is in many ways different from UNIX and Linux, while it supports and is based on Unicode. It depends on the current system code page, APIs used and exact kind how the binary was compiled The locale doesn't affect the way Unicode or ANSI API work. PHP in particular is being compiled without _UNICODE defined and this is conditioned by the way we handle strings. Here is more about it https://msdn.microsoft.com/en-us/library/tsbaswba.aspx However, with any system code page ANSI functions automatically convert paths to UTF-16. Paths in some encodings incompatible with the current system code page, won't work correctly with ANSI APIs. PHP till now only uses the ANSI Windows APIs. For example, on a system with the current code page 1252, the paths in cp1252 are supported and transparently converted to UTF-16 by the ANSI functions. Once one wants to handle a filepath encoded with cp932 on that particular system, an ANSI or a POSIX compatible function used in PHP will produce an erroneous result. When trying to convert that cp932 path to UTF-8 and passing to the ANSI functions, an ANSI function would likely interpret the UTF-8 string as some string in the current code page and create a filepath that represents every single byte of the UTF-8 string. These behaviors are not only broken but also disregard the documented INI settings. This patch solves the issies with the multibyte paths on Windows by intelligently enforcing the usage of the Unicode aware APIs. For functions expect Unicode (fe CreateFileW, FindFirstFileW, etc.), arguments will be converted to UTF-16 wide chars. For functions returning Unicode aware data (fe GetCurrentDirectoryW, etc.), resulting wide string is converted back to char's depending on the current PHP charset settings, either to the current ANSI codepage (this is the behavior prior to this patch) or to UTF-8 (the default behavior). In a particular case, users might have to explicitly set internal_encoding or default_charset, if filenames in ANSI codepage are necessary. Current tests show no regressions and witness that this will be an exotic case, the current default UTF-8 encoding is compatible with any supported system. The dependency libraries are long switching to Unicode APIs, so some tests were also added for extensions not directly related to streams. At large, the patch brings over 150 related tests into the core. Those target and was run on various environments with European, Asian, etc. codepages. General PHP frameworks was tested and showed no regressions. The impact on the current C code base is low, the most places affected are the Windows only places in the three files tsrm_win32.c, zend_virtual_cwd.c and plain_wrapper.c. The actual implementation of the most of the wide char supporting functionality is in win32/ioutil.* and win32/codepage.*, several low level functionsare extended in place to avoid reimplementation for now. No performance impact was sighted. As previously mentioned, the ANSI APIs used prior the patch perform Unicode conversions internally. Using the Unicode APIs directly while doing custom conversions just retains the status quo. The ways to optimize it are open (fe. by implementing caching for the strings converted to wide variants). The long path implementation is user transparent. If a path exceeds the length of _MAX_PATH, it'll be automatically prefixed with \\?\. The MAXPATHLEN is set to 2048 bytes. Appreciation to Pierre Joye, Matt Ficken, @algo13 and others for tips, ideas and testing. Thanks.
2016-06-20 07:32:19 +00:00
free_alloca(tmp, use_heap);
FREE_PATHW()
return -1;
Fixed the UTF-8 and long path support in the streams on Windows. Since long the default PHP charset is UTF-8, however the Windows part is out of step with this important point. The current implementation in PHP doesn't technically permit to handle UTF-8 filepath and several other things. Till now, only the ANSI compatible APIs are being used. Here is more about it https://msdn.microsoft.com/en-us/library/windows/desktop/dd317752%28v=vs.85%29.aspx The patch fixes not only issues with multibyte filenames under incompatible codepages, but indirectly also issues with some other multibyte encodings like BIG5, Shift-JIS, etc. by providing a clean way to access filenames in UTF-8. Below is a small list of issues from the bug tracker, that are getting fixed: https://bugs.php.net/63401 https://bugs.php.net/41199 https://bugs.php.net/50203 https://bugs.php.net/71509 https://bugs.php.net/64699 https://bugs.php.net/64506 https://bugs.php.net/30195 https://bugs.php.net/65358 https://bugs.php.net/61315 https://bugs.php.net/70943 https://bugs.php.net/70903 https://bugs.php.net/63593 https://bugs.php.net/54977 https://bugs.php.net/54028 https://bugs.php.net/43148 https://bugs.php.net/30730 https://bugs.php.net/33350 https://bugs.php.net/35300 https://bugs.php.net/46990 https://bugs.php.net/61309 https://bugs.php.net/69333 https://bugs.php.net/45517 https://bugs.php.net/70551 https://bugs.php.net/50197 https://bugs.php.net/72200 https://bugs.php.net/37672 Yet more related tickets can for sure be found - on bugs.php.net, Stackoverflow and Github. Some of the bugs are pretty recent, some descend to early 2000th, but the user comments in there last even till today. Just for example, bug #30195 was opened in 2004, the latest comment in there was made in 2014. It is certain, that these bugs descend not only to pure PHP use cases, but get also redirected from the popular PHP based projects. Given the modern systems (and those supported by PHP) are always based on NTFS, there is no excuse to keep these issues unresolved. The internalization approach on Windows is in many ways different from UNIX and Linux, while it supports and is based on Unicode. It depends on the current system code page, APIs used and exact kind how the binary was compiled The locale doesn't affect the way Unicode or ANSI API work. PHP in particular is being compiled without _UNICODE defined and this is conditioned by the way we handle strings. Here is more about it https://msdn.microsoft.com/en-us/library/tsbaswba.aspx However, with any system code page ANSI functions automatically convert paths to UTF-16. Paths in some encodings incompatible with the current system code page, won't work correctly with ANSI APIs. PHP till now only uses the ANSI Windows APIs. For example, on a system with the current code page 1252, the paths in cp1252 are supported and transparently converted to UTF-16 by the ANSI functions. Once one wants to handle a filepath encoded with cp932 on that particular system, an ANSI or a POSIX compatible function used in PHP will produce an erroneous result. When trying to convert that cp932 path to UTF-8 and passing to the ANSI functions, an ANSI function would likely interpret the UTF-8 string as some string in the current code page and create a filepath that represents every single byte of the UTF-8 string. These behaviors are not only broken but also disregard the documented INI settings. This patch solves the issies with the multibyte paths on Windows by intelligently enforcing the usage of the Unicode aware APIs. For functions expect Unicode (fe CreateFileW, FindFirstFileW, etc.), arguments will be converted to UTF-16 wide chars. For functions returning Unicode aware data (fe GetCurrentDirectoryW, etc.), resulting wide string is converted back to char's depending on the current PHP charset settings, either to the current ANSI codepage (this is the behavior prior to this patch) or to UTF-8 (the default behavior). In a particular case, users might have to explicitly set internal_encoding or default_charset, if filenames in ANSI codepage are necessary. Current tests show no regressions and witness that this will be an exotic case, the current default UTF-8 encoding is compatible with any supported system. The dependency libraries are long switching to Unicode APIs, so some tests were also added for extensions not directly related to streams. At large, the patch brings over 150 related tests into the core. Those target and was run on various environments with European, Asian, etc. codepages. General PHP frameworks was tested and showed no regressions. The impact on the current C code base is low, the most places affected are the Windows only places in the three files tsrm_win32.c, zend_virtual_cwd.c and plain_wrapper.c. The actual implementation of the most of the wide char supporting functionality is in win32/ioutil.* and win32/codepage.*, several low level functionsare extended in place to avoid reimplementation for now. No performance impact was sighted. As previously mentioned, the ANSI APIs used prior the patch perform Unicode conversions internally. Using the Unicode APIs directly while doing custom conversions just retains the status quo. The ways to optimize it are open (fe. by implementing caching for the strings converted to wide variants). The long path implementation is user transparent. If a path exceeds the length of _MAX_PATH, it'll be automatically prefixed with \\?\. The MAXPATHLEN is set to 2048 bytes. Appreciation to Pierre Joye, Matt Ficken, @algo13 and others for tips, ideas and testing. Thanks.
2016-06-20 07:32:19 +00:00
}
2017-01-21 01:17:06 +00:00
#endif
Fixed the UTF-8 and long path support in the streams on Windows. Since long the default PHP charset is UTF-8, however the Windows part is out of step with this important point. The current implementation in PHP doesn't technically permit to handle UTF-8 filepath and several other things. Till now, only the ANSI compatible APIs are being used. Here is more about it https://msdn.microsoft.com/en-us/library/windows/desktop/dd317752%28v=vs.85%29.aspx The patch fixes not only issues with multibyte filenames under incompatible codepages, but indirectly also issues with some other multibyte encodings like BIG5, Shift-JIS, etc. by providing a clean way to access filenames in UTF-8. Below is a small list of issues from the bug tracker, that are getting fixed: https://bugs.php.net/63401 https://bugs.php.net/41199 https://bugs.php.net/50203 https://bugs.php.net/71509 https://bugs.php.net/64699 https://bugs.php.net/64506 https://bugs.php.net/30195 https://bugs.php.net/65358 https://bugs.php.net/61315 https://bugs.php.net/70943 https://bugs.php.net/70903 https://bugs.php.net/63593 https://bugs.php.net/54977 https://bugs.php.net/54028 https://bugs.php.net/43148 https://bugs.php.net/30730 https://bugs.php.net/33350 https://bugs.php.net/35300 https://bugs.php.net/46990 https://bugs.php.net/61309 https://bugs.php.net/69333 https://bugs.php.net/45517 https://bugs.php.net/70551 https://bugs.php.net/50197 https://bugs.php.net/72200 https://bugs.php.net/37672 Yet more related tickets can for sure be found - on bugs.php.net, Stackoverflow and Github. Some of the bugs are pretty recent, some descend to early 2000th, but the user comments in there last even till today. Just for example, bug #30195 was opened in 2004, the latest comment in there was made in 2014. It is certain, that these bugs descend not only to pure PHP use cases, but get also redirected from the popular PHP based projects. Given the modern systems (and those supported by PHP) are always based on NTFS, there is no excuse to keep these issues unresolved. The internalization approach on Windows is in many ways different from UNIX and Linux, while it supports and is based on Unicode. It depends on the current system code page, APIs used and exact kind how the binary was compiled The locale doesn't affect the way Unicode or ANSI API work. PHP in particular is being compiled without _UNICODE defined and this is conditioned by the way we handle strings. Here is more about it https://msdn.microsoft.com/en-us/library/tsbaswba.aspx However, with any system code page ANSI functions automatically convert paths to UTF-16. Paths in some encodings incompatible with the current system code page, won't work correctly with ANSI APIs. PHP till now only uses the ANSI Windows APIs. For example, on a system with the current code page 1252, the paths in cp1252 are supported and transparently converted to UTF-16 by the ANSI functions. Once one wants to handle a filepath encoded with cp932 on that particular system, an ANSI or a POSIX compatible function used in PHP will produce an erroneous result. When trying to convert that cp932 path to UTF-8 and passing to the ANSI functions, an ANSI function would likely interpret the UTF-8 string as some string in the current code page and create a filepath that represents every single byte of the UTF-8 string. These behaviors are not only broken but also disregard the documented INI settings. This patch solves the issies with the multibyte paths on Windows by intelligently enforcing the usage of the Unicode aware APIs. For functions expect Unicode (fe CreateFileW, FindFirstFileW, etc.), arguments will be converted to UTF-16 wide chars. For functions returning Unicode aware data (fe GetCurrentDirectoryW, etc.), resulting wide string is converted back to char's depending on the current PHP charset settings, either to the current ANSI codepage (this is the behavior prior to this patch) or to UTF-8 (the default behavior). In a particular case, users might have to explicitly set internal_encoding or default_charset, if filenames in ANSI codepage are necessary. Current tests show no regressions and witness that this will be an exotic case, the current default UTF-8 encoding is compatible with any supported system. The dependency libraries are long switching to Unicode APIs, so some tests were also added for extensions not directly related to streams. At large, the patch brings over 150 related tests into the core. Those target and was run on various environments with European, Asian, etc. codepages. General PHP frameworks was tested and showed no regressions. The impact on the current C code base is low, the most places affected are the Windows only places in the three files tsrm_win32.c, zend_virtual_cwd.c and plain_wrapper.c. The actual implementation of the most of the wide char supporting functionality is in win32/ioutil.* and win32/codepage.*, several low level functionsare extended in place to avoid reimplementation for now. No performance impact was sighted. As previously mentioned, the ANSI APIs used prior the patch perform Unicode conversions internally. Using the Unicode APIs directly while doing custom conversions just retains the status quo. The ways to optimize it are open (fe. by implementing caching for the strings converted to wide variants). The long path implementation is user transparent. If a path exceeds the length of _MAX_PATH, it'll be automatically prefixed with \\?\. The MAXPATHLEN is set to 2048 bytes. Appreciation to Pierre Joye, Matt Ficken, @algo13 and others for tips, ideas and testing. Thanks.
2016-06-20 07:32:19 +00:00
substitutename_len = pbuffer->MountPointReparseBuffer.SubstituteNameLength / sizeof(WCHAR);
2017-01-24 12:24:11 +00:00
if (substitutename_len >= MAXPATHLEN) {
free_alloca(pbuffer, use_heap_large);
free_alloca(tmp, use_heap);
FREE_PATHW()
return -1;
}
memmove(tmpsubstname, reparsetarget + pbuffer->MountPointReparseBuffer.SubstituteNameOffset / sizeof(WCHAR), pbuffer->MountPointReparseBuffer.SubstituteNameLength);
tmpsubstname[substitutename_len] = L'\0';
substitutename = php_win32_cp_conv_w_to_any(tmpsubstname, substitutename_len, &substitutename_len);
2017-01-24 12:24:11 +00:00
if (!substitutename || substitutename_len >= MAXPATHLEN) {
free_alloca(pbuffer, use_heap_large);
Fixed the UTF-8 and long path support in the streams on Windows. Since long the default PHP charset is UTF-8, however the Windows part is out of step with this important point. The current implementation in PHP doesn't technically permit to handle UTF-8 filepath and several other things. Till now, only the ANSI compatible APIs are being used. Here is more about it https://msdn.microsoft.com/en-us/library/windows/desktop/dd317752%28v=vs.85%29.aspx The patch fixes not only issues with multibyte filenames under incompatible codepages, but indirectly also issues with some other multibyte encodings like BIG5, Shift-JIS, etc. by providing a clean way to access filenames in UTF-8. Below is a small list of issues from the bug tracker, that are getting fixed: https://bugs.php.net/63401 https://bugs.php.net/41199 https://bugs.php.net/50203 https://bugs.php.net/71509 https://bugs.php.net/64699 https://bugs.php.net/64506 https://bugs.php.net/30195 https://bugs.php.net/65358 https://bugs.php.net/61315 https://bugs.php.net/70943 https://bugs.php.net/70903 https://bugs.php.net/63593 https://bugs.php.net/54977 https://bugs.php.net/54028 https://bugs.php.net/43148 https://bugs.php.net/30730 https://bugs.php.net/33350 https://bugs.php.net/35300 https://bugs.php.net/46990 https://bugs.php.net/61309 https://bugs.php.net/69333 https://bugs.php.net/45517 https://bugs.php.net/70551 https://bugs.php.net/50197 https://bugs.php.net/72200 https://bugs.php.net/37672 Yet more related tickets can for sure be found - on bugs.php.net, Stackoverflow and Github. Some of the bugs are pretty recent, some descend to early 2000th, but the user comments in there last even till today. Just for example, bug #30195 was opened in 2004, the latest comment in there was made in 2014. It is certain, that these bugs descend not only to pure PHP use cases, but get also redirected from the popular PHP based projects. Given the modern systems (and those supported by PHP) are always based on NTFS, there is no excuse to keep these issues unresolved. The internalization approach on Windows is in many ways different from UNIX and Linux, while it supports and is based on Unicode. It depends on the current system code page, APIs used and exact kind how the binary was compiled The locale doesn't affect the way Unicode or ANSI API work. PHP in particular is being compiled without _UNICODE defined and this is conditioned by the way we handle strings. Here is more about it https://msdn.microsoft.com/en-us/library/tsbaswba.aspx However, with any system code page ANSI functions automatically convert paths to UTF-16. Paths in some encodings incompatible with the current system code page, won't work correctly with ANSI APIs. PHP till now only uses the ANSI Windows APIs. For example, on a system with the current code page 1252, the paths in cp1252 are supported and transparently converted to UTF-16 by the ANSI functions. Once one wants to handle a filepath encoded with cp932 on that particular system, an ANSI or a POSIX compatible function used in PHP will produce an erroneous result. When trying to convert that cp932 path to UTF-8 and passing to the ANSI functions, an ANSI function would likely interpret the UTF-8 string as some string in the current code page and create a filepath that represents every single byte of the UTF-8 string. These behaviors are not only broken but also disregard the documented INI settings. This patch solves the issies with the multibyte paths on Windows by intelligently enforcing the usage of the Unicode aware APIs. For functions expect Unicode (fe CreateFileW, FindFirstFileW, etc.), arguments will be converted to UTF-16 wide chars. For functions returning Unicode aware data (fe GetCurrentDirectoryW, etc.), resulting wide string is converted back to char's depending on the current PHP charset settings, either to the current ANSI codepage (this is the behavior prior to this patch) or to UTF-8 (the default behavior). In a particular case, users might have to explicitly set internal_encoding or default_charset, if filenames in ANSI codepage are necessary. Current tests show no regressions and witness that this will be an exotic case, the current default UTF-8 encoding is compatible with any supported system. The dependency libraries are long switching to Unicode APIs, so some tests were also added for extensions not directly related to streams. At large, the patch brings over 150 related tests into the core. Those target and was run on various environments with European, Asian, etc. codepages. General PHP frameworks was tested and showed no regressions. The impact on the current C code base is low, the most places affected are the Windows only places in the three files tsrm_win32.c, zend_virtual_cwd.c and plain_wrapper.c. The actual implementation of the most of the wide char supporting functionality is in win32/ioutil.* and win32/codepage.*, several low level functionsare extended in place to avoid reimplementation for now. No performance impact was sighted. As previously mentioned, the ANSI APIs used prior the patch perform Unicode conversions internally. Using the Unicode APIs directly while doing custom conversions just retains the status quo. The ways to optimize it are open (fe. by implementing caching for the strings converted to wide variants). The long path implementation is user transparent. If a path exceeds the length of _MAX_PATH, it'll be automatically prefixed with \\?\. The MAXPATHLEN is set to 2048 bytes. Appreciation to Pierre Joye, Matt Ficken, @algo13 and others for tips, ideas and testing. Thanks.
2016-06-20 07:32:19 +00:00
free_alloca(tmp, use_heap);
2017-01-24 12:24:11 +00:00
free(substitutename);
2017-01-21 01:17:06 +00:00
#if VIRTUAL_CWD_DEBUG
Fixed the UTF-8 and long path support in the streams on Windows. Since long the default PHP charset is UTF-8, however the Windows part is out of step with this important point. The current implementation in PHP doesn't technically permit to handle UTF-8 filepath and several other things. Till now, only the ANSI compatible APIs are being used. Here is more about it https://msdn.microsoft.com/en-us/library/windows/desktop/dd317752%28v=vs.85%29.aspx The patch fixes not only issues with multibyte filenames under incompatible codepages, but indirectly also issues with some other multibyte encodings like BIG5, Shift-JIS, etc. by providing a clean way to access filenames in UTF-8. Below is a small list of issues from the bug tracker, that are getting fixed: https://bugs.php.net/63401 https://bugs.php.net/41199 https://bugs.php.net/50203 https://bugs.php.net/71509 https://bugs.php.net/64699 https://bugs.php.net/64506 https://bugs.php.net/30195 https://bugs.php.net/65358 https://bugs.php.net/61315 https://bugs.php.net/70943 https://bugs.php.net/70903 https://bugs.php.net/63593 https://bugs.php.net/54977 https://bugs.php.net/54028 https://bugs.php.net/43148 https://bugs.php.net/30730 https://bugs.php.net/33350 https://bugs.php.net/35300 https://bugs.php.net/46990 https://bugs.php.net/61309 https://bugs.php.net/69333 https://bugs.php.net/45517 https://bugs.php.net/70551 https://bugs.php.net/50197 https://bugs.php.net/72200 https://bugs.php.net/37672 Yet more related tickets can for sure be found - on bugs.php.net, Stackoverflow and Github. Some of the bugs are pretty recent, some descend to early 2000th, but the user comments in there last even till today. Just for example, bug #30195 was opened in 2004, the latest comment in there was made in 2014. It is certain, that these bugs descend not only to pure PHP use cases, but get also redirected from the popular PHP based projects. Given the modern systems (and those supported by PHP) are always based on NTFS, there is no excuse to keep these issues unresolved. The internalization approach on Windows is in many ways different from UNIX and Linux, while it supports and is based on Unicode. It depends on the current system code page, APIs used and exact kind how the binary was compiled The locale doesn't affect the way Unicode or ANSI API work. PHP in particular is being compiled without _UNICODE defined and this is conditioned by the way we handle strings. Here is more about it https://msdn.microsoft.com/en-us/library/tsbaswba.aspx However, with any system code page ANSI functions automatically convert paths to UTF-16. Paths in some encodings incompatible with the current system code page, won't work correctly with ANSI APIs. PHP till now only uses the ANSI Windows APIs. For example, on a system with the current code page 1252, the paths in cp1252 are supported and transparently converted to UTF-16 by the ANSI functions. Once one wants to handle a filepath encoded with cp932 on that particular system, an ANSI or a POSIX compatible function used in PHP will produce an erroneous result. When trying to convert that cp932 path to UTF-8 and passing to the ANSI functions, an ANSI function would likely interpret the UTF-8 string as some string in the current code page and create a filepath that represents every single byte of the UTF-8 string. These behaviors are not only broken but also disregard the documented INI settings. This patch solves the issies with the multibyte paths on Windows by intelligently enforcing the usage of the Unicode aware APIs. For functions expect Unicode (fe CreateFileW, FindFirstFileW, etc.), arguments will be converted to UTF-16 wide chars. For functions returning Unicode aware data (fe GetCurrentDirectoryW, etc.), resulting wide string is converted back to char's depending on the current PHP charset settings, either to the current ANSI codepage (this is the behavior prior to this patch) or to UTF-8 (the default behavior). In a particular case, users might have to explicitly set internal_encoding or default_charset, if filenames in ANSI codepage are necessary. Current tests show no regressions and witness that this will be an exotic case, the current default UTF-8 encoding is compatible with any supported system. The dependency libraries are long switching to Unicode APIs, so some tests were also added for extensions not directly related to streams. At large, the patch brings over 150 related tests into the core. Those target and was run on various environments with European, Asian, etc. codepages. General PHP frameworks was tested and showed no regressions. The impact on the current C code base is low, the most places affected are the Windows only places in the three files tsrm_win32.c, zend_virtual_cwd.c and plain_wrapper.c. The actual implementation of the most of the wide char supporting functionality is in win32/ioutil.* and win32/codepage.*, several low level functionsare extended in place to avoid reimplementation for now. No performance impact was sighted. As previously mentioned, the ANSI APIs used prior the patch perform Unicode conversions internally. Using the Unicode APIs directly while doing custom conversions just retains the status quo. The ways to optimize it are open (fe. by implementing caching for the strings converted to wide variants). The long path implementation is user transparent. If a path exceeds the length of _MAX_PATH, it'll be automatically prefixed with \\?\. The MAXPATHLEN is set to 2048 bytes. Appreciation to Pierre Joye, Matt Ficken, @algo13 and others for tips, ideas and testing. Thanks.
2016-06-20 07:32:19 +00:00
free(printname);
2017-01-21 01:17:06 +00:00
#endif
Fixed the UTF-8 and long path support in the streams on Windows. Since long the default PHP charset is UTF-8, however the Windows part is out of step with this important point. The current implementation in PHP doesn't technically permit to handle UTF-8 filepath and several other things. Till now, only the ANSI compatible APIs are being used. Here is more about it https://msdn.microsoft.com/en-us/library/windows/desktop/dd317752%28v=vs.85%29.aspx The patch fixes not only issues with multibyte filenames under incompatible codepages, but indirectly also issues with some other multibyte encodings like BIG5, Shift-JIS, etc. by providing a clean way to access filenames in UTF-8. Below is a small list of issues from the bug tracker, that are getting fixed: https://bugs.php.net/63401 https://bugs.php.net/41199 https://bugs.php.net/50203 https://bugs.php.net/71509 https://bugs.php.net/64699 https://bugs.php.net/64506 https://bugs.php.net/30195 https://bugs.php.net/65358 https://bugs.php.net/61315 https://bugs.php.net/70943 https://bugs.php.net/70903 https://bugs.php.net/63593 https://bugs.php.net/54977 https://bugs.php.net/54028 https://bugs.php.net/43148 https://bugs.php.net/30730 https://bugs.php.net/33350 https://bugs.php.net/35300 https://bugs.php.net/46990 https://bugs.php.net/61309 https://bugs.php.net/69333 https://bugs.php.net/45517 https://bugs.php.net/70551 https://bugs.php.net/50197 https://bugs.php.net/72200 https://bugs.php.net/37672 Yet more related tickets can for sure be found - on bugs.php.net, Stackoverflow and Github. Some of the bugs are pretty recent, some descend to early 2000th, but the user comments in there last even till today. Just for example, bug #30195 was opened in 2004, the latest comment in there was made in 2014. It is certain, that these bugs descend not only to pure PHP use cases, but get also redirected from the popular PHP based projects. Given the modern systems (and those supported by PHP) are always based on NTFS, there is no excuse to keep these issues unresolved. The internalization approach on Windows is in many ways different from UNIX and Linux, while it supports and is based on Unicode. It depends on the current system code page, APIs used and exact kind how the binary was compiled The locale doesn't affect the way Unicode or ANSI API work. PHP in particular is being compiled without _UNICODE defined and this is conditioned by the way we handle strings. Here is more about it https://msdn.microsoft.com/en-us/library/tsbaswba.aspx However, with any system code page ANSI functions automatically convert paths to UTF-16. Paths in some encodings incompatible with the current system code page, won't work correctly with ANSI APIs. PHP till now only uses the ANSI Windows APIs. For example, on a system with the current code page 1252, the paths in cp1252 are supported and transparently converted to UTF-16 by the ANSI functions. Once one wants to handle a filepath encoded with cp932 on that particular system, an ANSI or a POSIX compatible function used in PHP will produce an erroneous result. When trying to convert that cp932 path to UTF-8 and passing to the ANSI functions, an ANSI function would likely interpret the UTF-8 string as some string in the current code page and create a filepath that represents every single byte of the UTF-8 string. These behaviors are not only broken but also disregard the documented INI settings. This patch solves the issies with the multibyte paths on Windows by intelligently enforcing the usage of the Unicode aware APIs. For functions expect Unicode (fe CreateFileW, FindFirstFileW, etc.), arguments will be converted to UTF-16 wide chars. For functions returning Unicode aware data (fe GetCurrentDirectoryW, etc.), resulting wide string is converted back to char's depending on the current PHP charset settings, either to the current ANSI codepage (this is the behavior prior to this patch) or to UTF-8 (the default behavior). In a particular case, users might have to explicitly set internal_encoding or default_charset, if filenames in ANSI codepage are necessary. Current tests show no regressions and witness that this will be an exotic case, the current default UTF-8 encoding is compatible with any supported system. The dependency libraries are long switching to Unicode APIs, so some tests were also added for extensions not directly related to streams. At large, the patch brings over 150 related tests into the core. Those target and was run on various environments with European, Asian, etc. codepages. General PHP frameworks was tested and showed no regressions. The impact on the current C code base is low, the most places affected are the Windows only places in the three files tsrm_win32.c, zend_virtual_cwd.c and plain_wrapper.c. The actual implementation of the most of the wide char supporting functionality is in win32/ioutil.* and win32/codepage.*, several low level functionsare extended in place to avoid reimplementation for now. No performance impact was sighted. As previously mentioned, the ANSI APIs used prior the patch perform Unicode conversions internally. Using the Unicode APIs directly while doing custom conversions just retains the status quo. The ways to optimize it are open (fe. by implementing caching for the strings converted to wide variants). The long path implementation is user transparent. If a path exceeds the length of _MAX_PATH, it'll be automatically prefixed with \\?\. The MAXPATHLEN is set to 2048 bytes. Appreciation to Pierre Joye, Matt Ficken, @algo13 and others for tips, ideas and testing. Thanks.
2016-06-20 07:32:19 +00:00
FREE_PATHW()
return -1;
Fixed the UTF-8 and long path support in the streams on Windows. Since long the default PHP charset is UTF-8, however the Windows part is out of step with this important point. The current implementation in PHP doesn't technically permit to handle UTF-8 filepath and several other things. Till now, only the ANSI compatible APIs are being used. Here is more about it https://msdn.microsoft.com/en-us/library/windows/desktop/dd317752%28v=vs.85%29.aspx The patch fixes not only issues with multibyte filenames under incompatible codepages, but indirectly also issues with some other multibyte encodings like BIG5, Shift-JIS, etc. by providing a clean way to access filenames in UTF-8. Below is a small list of issues from the bug tracker, that are getting fixed: https://bugs.php.net/63401 https://bugs.php.net/41199 https://bugs.php.net/50203 https://bugs.php.net/71509 https://bugs.php.net/64699 https://bugs.php.net/64506 https://bugs.php.net/30195 https://bugs.php.net/65358 https://bugs.php.net/61315 https://bugs.php.net/70943 https://bugs.php.net/70903 https://bugs.php.net/63593 https://bugs.php.net/54977 https://bugs.php.net/54028 https://bugs.php.net/43148 https://bugs.php.net/30730 https://bugs.php.net/33350 https://bugs.php.net/35300 https://bugs.php.net/46990 https://bugs.php.net/61309 https://bugs.php.net/69333 https://bugs.php.net/45517 https://bugs.php.net/70551 https://bugs.php.net/50197 https://bugs.php.net/72200 https://bugs.php.net/37672 Yet more related tickets can for sure be found - on bugs.php.net, Stackoverflow and Github. Some of the bugs are pretty recent, some descend to early 2000th, but the user comments in there last even till today. Just for example, bug #30195 was opened in 2004, the latest comment in there was made in 2014. It is certain, that these bugs descend not only to pure PHP use cases, but get also redirected from the popular PHP based projects. Given the modern systems (and those supported by PHP) are always based on NTFS, there is no excuse to keep these issues unresolved. The internalization approach on Windows is in many ways different from UNIX and Linux, while it supports and is based on Unicode. It depends on the current system code page, APIs used and exact kind how the binary was compiled The locale doesn't affect the way Unicode or ANSI API work. PHP in particular is being compiled without _UNICODE defined and this is conditioned by the way we handle strings. Here is more about it https://msdn.microsoft.com/en-us/library/tsbaswba.aspx However, with any system code page ANSI functions automatically convert paths to UTF-16. Paths in some encodings incompatible with the current system code page, won't work correctly with ANSI APIs. PHP till now only uses the ANSI Windows APIs. For example, on a system with the current code page 1252, the paths in cp1252 are supported and transparently converted to UTF-16 by the ANSI functions. Once one wants to handle a filepath encoded with cp932 on that particular system, an ANSI or a POSIX compatible function used in PHP will produce an erroneous result. When trying to convert that cp932 path to UTF-8 and passing to the ANSI functions, an ANSI function would likely interpret the UTF-8 string as some string in the current code page and create a filepath that represents every single byte of the UTF-8 string. These behaviors are not only broken but also disregard the documented INI settings. This patch solves the issies with the multibyte paths on Windows by intelligently enforcing the usage of the Unicode aware APIs. For functions expect Unicode (fe CreateFileW, FindFirstFileW, etc.), arguments will be converted to UTF-16 wide chars. For functions returning Unicode aware data (fe GetCurrentDirectoryW, etc.), resulting wide string is converted back to char's depending on the current PHP charset settings, either to the current ANSI codepage (this is the behavior prior to this patch) or to UTF-8 (the default behavior). In a particular case, users might have to explicitly set internal_encoding or default_charset, if filenames in ANSI codepage are necessary. Current tests show no regressions and witness that this will be an exotic case, the current default UTF-8 encoding is compatible with any supported system. The dependency libraries are long switching to Unicode APIs, so some tests were also added for extensions not directly related to streams. At large, the patch brings over 150 related tests into the core. Those target and was run on various environments with European, Asian, etc. codepages. General PHP frameworks was tested and showed no regressions. The impact on the current C code base is low, the most places affected are the Windows only places in the three files tsrm_win32.c, zend_virtual_cwd.c and plain_wrapper.c. The actual implementation of the most of the wide char supporting functionality is in win32/ioutil.* and win32/codepage.*, several low level functionsare extended in place to avoid reimplementation for now. No performance impact was sighted. As previously mentioned, the ANSI APIs used prior the patch perform Unicode conversions internally. Using the Unicode APIs directly while doing custom conversions just retains the status quo. The ways to optimize it are open (fe. by implementing caching for the strings converted to wide variants). The long path implementation is user transparent. If a path exceeds the length of _MAX_PATH, it'll be automatically prefixed with \\?\. The MAXPATHLEN is set to 2048 bytes. Appreciation to Pierre Joye, Matt Ficken, @algo13 and others for tips, ideas and testing. Thanks.
2016-06-20 07:32:19 +00:00
}
}
else if (pbuffer->ReparseTag == IO_REPARSE_TAG_DEDUP) {
isabsolute = 1;
Fixed the UTF-8 and long path support in the streams on Windows. Since long the default PHP charset is UTF-8, however the Windows part is out of step with this important point. The current implementation in PHP doesn't technically permit to handle UTF-8 filepath and several other things. Till now, only the ANSI compatible APIs are being used. Here is more about it https://msdn.microsoft.com/en-us/library/windows/desktop/dd317752%28v=vs.85%29.aspx The patch fixes not only issues with multibyte filenames under incompatible codepages, but indirectly also issues with some other multibyte encodings like BIG5, Shift-JIS, etc. by providing a clean way to access filenames in UTF-8. Below is a small list of issues from the bug tracker, that are getting fixed: https://bugs.php.net/63401 https://bugs.php.net/41199 https://bugs.php.net/50203 https://bugs.php.net/71509 https://bugs.php.net/64699 https://bugs.php.net/64506 https://bugs.php.net/30195 https://bugs.php.net/65358 https://bugs.php.net/61315 https://bugs.php.net/70943 https://bugs.php.net/70903 https://bugs.php.net/63593 https://bugs.php.net/54977 https://bugs.php.net/54028 https://bugs.php.net/43148 https://bugs.php.net/30730 https://bugs.php.net/33350 https://bugs.php.net/35300 https://bugs.php.net/46990 https://bugs.php.net/61309 https://bugs.php.net/69333 https://bugs.php.net/45517 https://bugs.php.net/70551 https://bugs.php.net/50197 https://bugs.php.net/72200 https://bugs.php.net/37672 Yet more related tickets can for sure be found - on bugs.php.net, Stackoverflow and Github. Some of the bugs are pretty recent, some descend to early 2000th, but the user comments in there last even till today. Just for example, bug #30195 was opened in 2004, the latest comment in there was made in 2014. It is certain, that these bugs descend not only to pure PHP use cases, but get also redirected from the popular PHP based projects. Given the modern systems (and those supported by PHP) are always based on NTFS, there is no excuse to keep these issues unresolved. The internalization approach on Windows is in many ways different from UNIX and Linux, while it supports and is based on Unicode. It depends on the current system code page, APIs used and exact kind how the binary was compiled The locale doesn't affect the way Unicode or ANSI API work. PHP in particular is being compiled without _UNICODE defined and this is conditioned by the way we handle strings. Here is more about it https://msdn.microsoft.com/en-us/library/tsbaswba.aspx However, with any system code page ANSI functions automatically convert paths to UTF-16. Paths in some encodings incompatible with the current system code page, won't work correctly with ANSI APIs. PHP till now only uses the ANSI Windows APIs. For example, on a system with the current code page 1252, the paths in cp1252 are supported and transparently converted to UTF-16 by the ANSI functions. Once one wants to handle a filepath encoded with cp932 on that particular system, an ANSI or a POSIX compatible function used in PHP will produce an erroneous result. When trying to convert that cp932 path to UTF-8 and passing to the ANSI functions, an ANSI function would likely interpret the UTF-8 string as some string in the current code page and create a filepath that represents every single byte of the UTF-8 string. These behaviors are not only broken but also disregard the documented INI settings. This patch solves the issies with the multibyte paths on Windows by intelligently enforcing the usage of the Unicode aware APIs. For functions expect Unicode (fe CreateFileW, FindFirstFileW, etc.), arguments will be converted to UTF-16 wide chars. For functions returning Unicode aware data (fe GetCurrentDirectoryW, etc.), resulting wide string is converted back to char's depending on the current PHP charset settings, either to the current ANSI codepage (this is the behavior prior to this patch) or to UTF-8 (the default behavior). In a particular case, users might have to explicitly set internal_encoding or default_charset, if filenames in ANSI codepage are necessary. Current tests show no regressions and witness that this will be an exotic case, the current default UTF-8 encoding is compatible with any supported system. The dependency libraries are long switching to Unicode APIs, so some tests were also added for extensions not directly related to streams. At large, the patch brings over 150 related tests into the core. Those target and was run on various environments with European, Asian, etc. codepages. General PHP frameworks was tested and showed no regressions. The impact on the current C code base is low, the most places affected are the Windows only places in the three files tsrm_win32.c, zend_virtual_cwd.c and plain_wrapper.c. The actual implementation of the most of the wide char supporting functionality is in win32/ioutil.* and win32/codepage.*, several low level functionsare extended in place to avoid reimplementation for now. No performance impact was sighted. As previously mentioned, the ANSI APIs used prior the patch perform Unicode conversions internally. Using the Unicode APIs directly while doing custom conversions just retains the status quo. The ways to optimize it are open (fe. by implementing caching for the strings converted to wide variants). The long path implementation is user transparent. If a path exceeds the length of _MAX_PATH, it'll be automatically prefixed with \\?\. The MAXPATHLEN is set to 2048 bytes. Appreciation to Pierre Joye, Matt Ficken, @algo13 and others for tips, ideas and testing. Thanks.
2016-06-20 07:32:19 +00:00
substitutename = malloc((len + 1) * sizeof(char));
if (!substitutename) {
free_alloca(pbuffer, use_heap_large);
free_alloca(tmp, use_heap);
FREE_PATHW()
return -1;
}
memcpy(substitutename, path, len + 1);
substitutename_len = len;
} else {
2014-09-22 07:37:40 +00:00
/* XXX this might be not the end, restart handling with REPARSE_GUID_DATA_BUFFER should be implemented. */
free_alloca(pbuffer, use_heap_large);
Fixed the UTF-8 and long path support in the streams on Windows. Since long the default PHP charset is UTF-8, however the Windows part is out of step with this important point. The current implementation in PHP doesn't technically permit to handle UTF-8 filepath and several other things. Till now, only the ANSI compatible APIs are being used. Here is more about it https://msdn.microsoft.com/en-us/library/windows/desktop/dd317752%28v=vs.85%29.aspx The patch fixes not only issues with multibyte filenames under incompatible codepages, but indirectly also issues with some other multibyte encodings like BIG5, Shift-JIS, etc. by providing a clean way to access filenames in UTF-8. Below is a small list of issues from the bug tracker, that are getting fixed: https://bugs.php.net/63401 https://bugs.php.net/41199 https://bugs.php.net/50203 https://bugs.php.net/71509 https://bugs.php.net/64699 https://bugs.php.net/64506 https://bugs.php.net/30195 https://bugs.php.net/65358 https://bugs.php.net/61315 https://bugs.php.net/70943 https://bugs.php.net/70903 https://bugs.php.net/63593 https://bugs.php.net/54977 https://bugs.php.net/54028 https://bugs.php.net/43148 https://bugs.php.net/30730 https://bugs.php.net/33350 https://bugs.php.net/35300 https://bugs.php.net/46990 https://bugs.php.net/61309 https://bugs.php.net/69333 https://bugs.php.net/45517 https://bugs.php.net/70551 https://bugs.php.net/50197 https://bugs.php.net/72200 https://bugs.php.net/37672 Yet more related tickets can for sure be found - on bugs.php.net, Stackoverflow and Github. Some of the bugs are pretty recent, some descend to early 2000th, but the user comments in there last even till today. Just for example, bug #30195 was opened in 2004, the latest comment in there was made in 2014. It is certain, that these bugs descend not only to pure PHP use cases, but get also redirected from the popular PHP based projects. Given the modern systems (and those supported by PHP) are always based on NTFS, there is no excuse to keep these issues unresolved. The internalization approach on Windows is in many ways different from UNIX and Linux, while it supports and is based on Unicode. It depends on the current system code page, APIs used and exact kind how the binary was compiled The locale doesn't affect the way Unicode or ANSI API work. PHP in particular is being compiled without _UNICODE defined and this is conditioned by the way we handle strings. Here is more about it https://msdn.microsoft.com/en-us/library/tsbaswba.aspx However, with any system code page ANSI functions automatically convert paths to UTF-16. Paths in some encodings incompatible with the current system code page, won't work correctly with ANSI APIs. PHP till now only uses the ANSI Windows APIs. For example, on a system with the current code page 1252, the paths in cp1252 are supported and transparently converted to UTF-16 by the ANSI functions. Once one wants to handle a filepath encoded with cp932 on that particular system, an ANSI or a POSIX compatible function used in PHP will produce an erroneous result. When trying to convert that cp932 path to UTF-8 and passing to the ANSI functions, an ANSI function would likely interpret the UTF-8 string as some string in the current code page and create a filepath that represents every single byte of the UTF-8 string. These behaviors are not only broken but also disregard the documented INI settings. This patch solves the issies with the multibyte paths on Windows by intelligently enforcing the usage of the Unicode aware APIs. For functions expect Unicode (fe CreateFileW, FindFirstFileW, etc.), arguments will be converted to UTF-16 wide chars. For functions returning Unicode aware data (fe GetCurrentDirectoryW, etc.), resulting wide string is converted back to char's depending on the current PHP charset settings, either to the current ANSI codepage (this is the behavior prior to this patch) or to UTF-8 (the default behavior). In a particular case, users might have to explicitly set internal_encoding or default_charset, if filenames in ANSI codepage are necessary. Current tests show no regressions and witness that this will be an exotic case, the current default UTF-8 encoding is compatible with any supported system. The dependency libraries are long switching to Unicode APIs, so some tests were also added for extensions not directly related to streams. At large, the patch brings over 150 related tests into the core. Those target and was run on various environments with European, Asian, etc. codepages. General PHP frameworks was tested and showed no regressions. The impact on the current C code base is low, the most places affected are the Windows only places in the three files tsrm_win32.c, zend_virtual_cwd.c and plain_wrapper.c. The actual implementation of the most of the wide char supporting functionality is in win32/ioutil.* and win32/codepage.*, several low level functionsare extended in place to avoid reimplementation for now. No performance impact was sighted. As previously mentioned, the ANSI APIs used prior the patch perform Unicode conversions internally. Using the Unicode APIs directly while doing custom conversions just retains the status quo. The ways to optimize it are open (fe. by implementing caching for the strings converted to wide variants). The long path implementation is user transparent. If a path exceeds the length of _MAX_PATH, it'll be automatically prefixed with \\?\. The MAXPATHLEN is set to 2048 bytes. Appreciation to Pierre Joye, Matt Ficken, @algo13 and others for tips, ideas and testing. Thanks.
2016-06-20 07:32:19 +00:00
free_alloca(tmp, use_heap);
FREE_PATHW()
return -1;
}
if(isabsolute && substitutename_len > 4) {
2010-09-10 14:02:19 +00:00
/* Do not resolve volumes (for now). A mounted point can
target a volume without a drive, it is not certain that
2010-09-10 14:02:19 +00:00
all IO functions we use in php and its deps support
path with volume GUID instead of the DOS way, like:
d:\test\mnt\foo
\\?\Volume{62d1c3f8-83b9-11de-b108-806e6f6e6963}\foo
*/
2010-09-10 14:02:19 +00:00
if (strncmp(substitutename, "\\??\\Volume{",11) == 0
|| strncmp(substitutename, "\\\\?\\Volume{",11) == 0
|| strncmp(substitutename, "\\??\\UNC\\", 8) == 0
) {
2010-08-26 14:23:48 +00:00
isVolume = TRUE;
substitutename_off = 0;
} else
/* do not use the \??\ and \\?\ prefix*/
2010-09-10 14:02:19 +00:00
if (strncmp(substitutename, "\\??\\", 4) == 0
|| strncmp(substitutename, "\\\\?\\", 4) == 0) {
substitutename_off = 4;
}
}
if (!isVolume) {
2011-01-10 00:43:08 +00:00
char * tmp2 = substitutename + substitutename_off;
for(bufindex = 0; bufindex < (substitutename_len - substitutename_off); bufindex++) {
2011-01-10 00:43:08 +00:00
*(path + bufindex) = *(tmp2 + bufindex);
}
*(path + bufindex) = 0;
j = bufindex;
} else {
2009-09-02 22:59:58 +00:00
j = len;
}
#if VIRTUAL_CWD_DEBUG
fprintf(stderr, "reparse: print: %s ", printname);
fprintf(stderr, "sub: %s ", substitutename);
fprintf(stderr, "resolved: %s ", path);
2017-01-21 01:17:06 +00:00
free(printname);
#endif
free_alloca(pbuffer, use_heap_large);
Fixed the UTF-8 and long path support in the streams on Windows. Since long the default PHP charset is UTF-8, however the Windows part is out of step with this important point. The current implementation in PHP doesn't technically permit to handle UTF-8 filepath and several other things. Till now, only the ANSI compatible APIs are being used. Here is more about it https://msdn.microsoft.com/en-us/library/windows/desktop/dd317752%28v=vs.85%29.aspx The patch fixes not only issues with multibyte filenames under incompatible codepages, but indirectly also issues with some other multibyte encodings like BIG5, Shift-JIS, etc. by providing a clean way to access filenames in UTF-8. Below is a small list of issues from the bug tracker, that are getting fixed: https://bugs.php.net/63401 https://bugs.php.net/41199 https://bugs.php.net/50203 https://bugs.php.net/71509 https://bugs.php.net/64699 https://bugs.php.net/64506 https://bugs.php.net/30195 https://bugs.php.net/65358 https://bugs.php.net/61315 https://bugs.php.net/70943 https://bugs.php.net/70903 https://bugs.php.net/63593 https://bugs.php.net/54977 https://bugs.php.net/54028 https://bugs.php.net/43148 https://bugs.php.net/30730 https://bugs.php.net/33350 https://bugs.php.net/35300 https://bugs.php.net/46990 https://bugs.php.net/61309 https://bugs.php.net/69333 https://bugs.php.net/45517 https://bugs.php.net/70551 https://bugs.php.net/50197 https://bugs.php.net/72200 https://bugs.php.net/37672 Yet more related tickets can for sure be found - on bugs.php.net, Stackoverflow and Github. Some of the bugs are pretty recent, some descend to early 2000th, but the user comments in there last even till today. Just for example, bug #30195 was opened in 2004, the latest comment in there was made in 2014. It is certain, that these bugs descend not only to pure PHP use cases, but get also redirected from the popular PHP based projects. Given the modern systems (and those supported by PHP) are always based on NTFS, there is no excuse to keep these issues unresolved. The internalization approach on Windows is in many ways different from UNIX and Linux, while it supports and is based on Unicode. It depends on the current system code page, APIs used and exact kind how the binary was compiled The locale doesn't affect the way Unicode or ANSI API work. PHP in particular is being compiled without _UNICODE defined and this is conditioned by the way we handle strings. Here is more about it https://msdn.microsoft.com/en-us/library/tsbaswba.aspx However, with any system code page ANSI functions automatically convert paths to UTF-16. Paths in some encodings incompatible with the current system code page, won't work correctly with ANSI APIs. PHP till now only uses the ANSI Windows APIs. For example, on a system with the current code page 1252, the paths in cp1252 are supported and transparently converted to UTF-16 by the ANSI functions. Once one wants to handle a filepath encoded with cp932 on that particular system, an ANSI or a POSIX compatible function used in PHP will produce an erroneous result. When trying to convert that cp932 path to UTF-8 and passing to the ANSI functions, an ANSI function would likely interpret the UTF-8 string as some string in the current code page and create a filepath that represents every single byte of the UTF-8 string. These behaviors are not only broken but also disregard the documented INI settings. This patch solves the issies with the multibyte paths on Windows by intelligently enforcing the usage of the Unicode aware APIs. For functions expect Unicode (fe CreateFileW, FindFirstFileW, etc.), arguments will be converted to UTF-16 wide chars. For functions returning Unicode aware data (fe GetCurrentDirectoryW, etc.), resulting wide string is converted back to char's depending on the current PHP charset settings, either to the current ANSI codepage (this is the behavior prior to this patch) or to UTF-8 (the default behavior). In a particular case, users might have to explicitly set internal_encoding or default_charset, if filenames in ANSI codepage are necessary. Current tests show no regressions and witness that this will be an exotic case, the current default UTF-8 encoding is compatible with any supported system. The dependency libraries are long switching to Unicode APIs, so some tests were also added for extensions not directly related to streams. At large, the patch brings over 150 related tests into the core. Those target and was run on various environments with European, Asian, etc. codepages. General PHP frameworks was tested and showed no regressions. The impact on the current C code base is low, the most places affected are the Windows only places in the three files tsrm_win32.c, zend_virtual_cwd.c and plain_wrapper.c. The actual implementation of the most of the wide char supporting functionality is in win32/ioutil.* and win32/codepage.*, several low level functionsare extended in place to avoid reimplementation for now. No performance impact was sighted. As previously mentioned, the ANSI APIs used prior the patch perform Unicode conversions internally. Using the Unicode APIs directly while doing custom conversions just retains the status quo. The ways to optimize it are open (fe. by implementing caching for the strings converted to wide variants). The long path implementation is user transparent. If a path exceeds the length of _MAX_PATH, it'll be automatically prefixed with \\?\. The MAXPATHLEN is set to 2048 bytes. Appreciation to Pierre Joye, Matt Ficken, @algo13 and others for tips, ideas and testing. Thanks.
2016-06-20 07:32:19 +00:00
free(substitutename);
if(isabsolute == 1) {
if (!((j == 3) && (path[1] == ':') && (path[2] == '\\'))) {
/* use_realpath is 0 in the call below coz path is absolute*/
2014-12-13 22:06:14 +00:00
j = tsrm_realpath_r(path, 0, j, ll, t, 0, is_dir, &directory);
if(j < 0) {
free_alloca(tmp, use_heap);
Fixed the UTF-8 and long path support in the streams on Windows. Since long the default PHP charset is UTF-8, however the Windows part is out of step with this important point. The current implementation in PHP doesn't technically permit to handle UTF-8 filepath and several other things. Till now, only the ANSI compatible APIs are being used. Here is more about it https://msdn.microsoft.com/en-us/library/windows/desktop/dd317752%28v=vs.85%29.aspx The patch fixes not only issues with multibyte filenames under incompatible codepages, but indirectly also issues with some other multibyte encodings like BIG5, Shift-JIS, etc. by providing a clean way to access filenames in UTF-8. Below is a small list of issues from the bug tracker, that are getting fixed: https://bugs.php.net/63401 https://bugs.php.net/41199 https://bugs.php.net/50203 https://bugs.php.net/71509 https://bugs.php.net/64699 https://bugs.php.net/64506 https://bugs.php.net/30195 https://bugs.php.net/65358 https://bugs.php.net/61315 https://bugs.php.net/70943 https://bugs.php.net/70903 https://bugs.php.net/63593 https://bugs.php.net/54977 https://bugs.php.net/54028 https://bugs.php.net/43148 https://bugs.php.net/30730 https://bugs.php.net/33350 https://bugs.php.net/35300 https://bugs.php.net/46990 https://bugs.php.net/61309 https://bugs.php.net/69333 https://bugs.php.net/45517 https://bugs.php.net/70551 https://bugs.php.net/50197 https://bugs.php.net/72200 https://bugs.php.net/37672 Yet more related tickets can for sure be found - on bugs.php.net, Stackoverflow and Github. Some of the bugs are pretty recent, some descend to early 2000th, but the user comments in there last even till today. Just for example, bug #30195 was opened in 2004, the latest comment in there was made in 2014. It is certain, that these bugs descend not only to pure PHP use cases, but get also redirected from the popular PHP based projects. Given the modern systems (and those supported by PHP) are always based on NTFS, there is no excuse to keep these issues unresolved. The internalization approach on Windows is in many ways different from UNIX and Linux, while it supports and is based on Unicode. It depends on the current system code page, APIs used and exact kind how the binary was compiled The locale doesn't affect the way Unicode or ANSI API work. PHP in particular is being compiled without _UNICODE defined and this is conditioned by the way we handle strings. Here is more about it https://msdn.microsoft.com/en-us/library/tsbaswba.aspx However, with any system code page ANSI functions automatically convert paths to UTF-16. Paths in some encodings incompatible with the current system code page, won't work correctly with ANSI APIs. PHP till now only uses the ANSI Windows APIs. For example, on a system with the current code page 1252, the paths in cp1252 are supported and transparently converted to UTF-16 by the ANSI functions. Once one wants to handle a filepath encoded with cp932 on that particular system, an ANSI or a POSIX compatible function used in PHP will produce an erroneous result. When trying to convert that cp932 path to UTF-8 and passing to the ANSI functions, an ANSI function would likely interpret the UTF-8 string as some string in the current code page and create a filepath that represents every single byte of the UTF-8 string. These behaviors are not only broken but also disregard the documented INI settings. This patch solves the issies with the multibyte paths on Windows by intelligently enforcing the usage of the Unicode aware APIs. For functions expect Unicode (fe CreateFileW, FindFirstFileW, etc.), arguments will be converted to UTF-16 wide chars. For functions returning Unicode aware data (fe GetCurrentDirectoryW, etc.), resulting wide string is converted back to char's depending on the current PHP charset settings, either to the current ANSI codepage (this is the behavior prior to this patch) or to UTF-8 (the default behavior). In a particular case, users might have to explicitly set internal_encoding or default_charset, if filenames in ANSI codepage are necessary. Current tests show no regressions and witness that this will be an exotic case, the current default UTF-8 encoding is compatible with any supported system. The dependency libraries are long switching to Unicode APIs, so some tests were also added for extensions not directly related to streams. At large, the patch brings over 150 related tests into the core. Those target and was run on various environments with European, Asian, etc. codepages. General PHP frameworks was tested and showed no regressions. The impact on the current C code base is low, the most places affected are the Windows only places in the three files tsrm_win32.c, zend_virtual_cwd.c and plain_wrapper.c. The actual implementation of the most of the wide char supporting functionality is in win32/ioutil.* and win32/codepage.*, several low level functionsare extended in place to avoid reimplementation for now. No performance impact was sighted. As previously mentioned, the ANSI APIs used prior the patch perform Unicode conversions internally. Using the Unicode APIs directly while doing custom conversions just retains the status quo. The ways to optimize it are open (fe. by implementing caching for the strings converted to wide variants). The long path implementation is user transparent. If a path exceeds the length of _MAX_PATH, it'll be automatically prefixed with \\?\. The MAXPATHLEN is set to 2048 bytes. Appreciation to Pierre Joye, Matt Ficken, @algo13 and others for tips, ideas and testing. Thanks.
2016-06-20 07:32:19 +00:00
FREE_PATHW()
return -1;
}
}
}
else {
if(i + j >= MAXPATHLEN - 1) {
free_alloca(tmp, use_heap);
Fixed the UTF-8 and long path support in the streams on Windows. Since long the default PHP charset is UTF-8, however the Windows part is out of step with this important point. The current implementation in PHP doesn't technically permit to handle UTF-8 filepath and several other things. Till now, only the ANSI compatible APIs are being used. Here is more about it https://msdn.microsoft.com/en-us/library/windows/desktop/dd317752%28v=vs.85%29.aspx The patch fixes not only issues with multibyte filenames under incompatible codepages, but indirectly also issues with some other multibyte encodings like BIG5, Shift-JIS, etc. by providing a clean way to access filenames in UTF-8. Below is a small list of issues from the bug tracker, that are getting fixed: https://bugs.php.net/63401 https://bugs.php.net/41199 https://bugs.php.net/50203 https://bugs.php.net/71509 https://bugs.php.net/64699 https://bugs.php.net/64506 https://bugs.php.net/30195 https://bugs.php.net/65358 https://bugs.php.net/61315 https://bugs.php.net/70943 https://bugs.php.net/70903 https://bugs.php.net/63593 https://bugs.php.net/54977 https://bugs.php.net/54028 https://bugs.php.net/43148 https://bugs.php.net/30730 https://bugs.php.net/33350 https://bugs.php.net/35300 https://bugs.php.net/46990 https://bugs.php.net/61309 https://bugs.php.net/69333 https://bugs.php.net/45517 https://bugs.php.net/70551 https://bugs.php.net/50197 https://bugs.php.net/72200 https://bugs.php.net/37672 Yet more related tickets can for sure be found - on bugs.php.net, Stackoverflow and Github. Some of the bugs are pretty recent, some descend to early 2000th, but the user comments in there last even till today. Just for example, bug #30195 was opened in 2004, the latest comment in there was made in 2014. It is certain, that these bugs descend not only to pure PHP use cases, but get also redirected from the popular PHP based projects. Given the modern systems (and those supported by PHP) are always based on NTFS, there is no excuse to keep these issues unresolved. The internalization approach on Windows is in many ways different from UNIX and Linux, while it supports and is based on Unicode. It depends on the current system code page, APIs used and exact kind how the binary was compiled The locale doesn't affect the way Unicode or ANSI API work. PHP in particular is being compiled without _UNICODE defined and this is conditioned by the way we handle strings. Here is more about it https://msdn.microsoft.com/en-us/library/tsbaswba.aspx However, with any system code page ANSI functions automatically convert paths to UTF-16. Paths in some encodings incompatible with the current system code page, won't work correctly with ANSI APIs. PHP till now only uses the ANSI Windows APIs. For example, on a system with the current code page 1252, the paths in cp1252 are supported and transparently converted to UTF-16 by the ANSI functions. Once one wants to handle a filepath encoded with cp932 on that particular system, an ANSI or a POSIX compatible function used in PHP will produce an erroneous result. When trying to convert that cp932 path to UTF-8 and passing to the ANSI functions, an ANSI function would likely interpret the UTF-8 string as some string in the current code page and create a filepath that represents every single byte of the UTF-8 string. These behaviors are not only broken but also disregard the documented INI settings. This patch solves the issies with the multibyte paths on Windows by intelligently enforcing the usage of the Unicode aware APIs. For functions expect Unicode (fe CreateFileW, FindFirstFileW, etc.), arguments will be converted to UTF-16 wide chars. For functions returning Unicode aware data (fe GetCurrentDirectoryW, etc.), resulting wide string is converted back to char's depending on the current PHP charset settings, either to the current ANSI codepage (this is the behavior prior to this patch) or to UTF-8 (the default behavior). In a particular case, users might have to explicitly set internal_encoding or default_charset, if filenames in ANSI codepage are necessary. Current tests show no regressions and witness that this will be an exotic case, the current default UTF-8 encoding is compatible with any supported system. The dependency libraries are long switching to Unicode APIs, so some tests were also added for extensions not directly related to streams. At large, the patch brings over 150 related tests into the core. Those target and was run on various environments with European, Asian, etc. codepages. General PHP frameworks was tested and showed no regressions. The impact on the current C code base is low, the most places affected are the Windows only places in the three files tsrm_win32.c, zend_virtual_cwd.c and plain_wrapper.c. The actual implementation of the most of the wide char supporting functionality is in win32/ioutil.* and win32/codepage.*, several low level functionsare extended in place to avoid reimplementation for now. No performance impact was sighted. As previously mentioned, the ANSI APIs used prior the patch perform Unicode conversions internally. Using the Unicode APIs directly while doing custom conversions just retains the status quo. The ways to optimize it are open (fe. by implementing caching for the strings converted to wide variants). The long path implementation is user transparent. If a path exceeds the length of _MAX_PATH, it'll be automatically prefixed with \\?\. The MAXPATHLEN is set to 2048 bytes. Appreciation to Pierre Joye, Matt Ficken, @algo13 and others for tips, ideas and testing. Thanks.
2016-06-20 07:32:19 +00:00
FREE_PATHW()
return -1;
}
memmove(path+i, path, j+1);
memcpy(path, tmp, i-1);
path[i-1] = DEFAULT_SLASH;
2014-12-13 22:06:14 +00:00
j = tsrm_realpath_r(path, start, i + j, ll, t, use_realpath, is_dir, &directory);
if(j < 0) {
free_alloca(tmp, use_heap);
Fixed the UTF-8 and long path support in the streams on Windows. Since long the default PHP charset is UTF-8, however the Windows part is out of step with this important point. The current implementation in PHP doesn't technically permit to handle UTF-8 filepath and several other things. Till now, only the ANSI compatible APIs are being used. Here is more about it https://msdn.microsoft.com/en-us/library/windows/desktop/dd317752%28v=vs.85%29.aspx The patch fixes not only issues with multibyte filenames under incompatible codepages, but indirectly also issues with some other multibyte encodings like BIG5, Shift-JIS, etc. by providing a clean way to access filenames in UTF-8. Below is a small list of issues from the bug tracker, that are getting fixed: https://bugs.php.net/63401 https://bugs.php.net/41199 https://bugs.php.net/50203 https://bugs.php.net/71509 https://bugs.php.net/64699 https://bugs.php.net/64506 https://bugs.php.net/30195 https://bugs.php.net/65358 https://bugs.php.net/61315 https://bugs.php.net/70943 https://bugs.php.net/70903 https://bugs.php.net/63593 https://bugs.php.net/54977 https://bugs.php.net/54028 https://bugs.php.net/43148 https://bugs.php.net/30730 https://bugs.php.net/33350 https://bugs.php.net/35300 https://bugs.php.net/46990 https://bugs.php.net/61309 https://bugs.php.net/69333 https://bugs.php.net/45517 https://bugs.php.net/70551 https://bugs.php.net/50197 https://bugs.php.net/72200 https://bugs.php.net/37672 Yet more related tickets can for sure be found - on bugs.php.net, Stackoverflow and Github. Some of the bugs are pretty recent, some descend to early 2000th, but the user comments in there last even till today. Just for example, bug #30195 was opened in 2004, the latest comment in there was made in 2014. It is certain, that these bugs descend not only to pure PHP use cases, but get also redirected from the popular PHP based projects. Given the modern systems (and those supported by PHP) are always based on NTFS, there is no excuse to keep these issues unresolved. The internalization approach on Windows is in many ways different from UNIX and Linux, while it supports and is based on Unicode. It depends on the current system code page, APIs used and exact kind how the binary was compiled The locale doesn't affect the way Unicode or ANSI API work. PHP in particular is being compiled without _UNICODE defined and this is conditioned by the way we handle strings. Here is more about it https://msdn.microsoft.com/en-us/library/tsbaswba.aspx However, with any system code page ANSI functions automatically convert paths to UTF-16. Paths in some encodings incompatible with the current system code page, won't work correctly with ANSI APIs. PHP till now only uses the ANSI Windows APIs. For example, on a system with the current code page 1252, the paths in cp1252 are supported and transparently converted to UTF-16 by the ANSI functions. Once one wants to handle a filepath encoded with cp932 on that particular system, an ANSI or a POSIX compatible function used in PHP will produce an erroneous result. When trying to convert that cp932 path to UTF-8 and passing to the ANSI functions, an ANSI function would likely interpret the UTF-8 string as some string in the current code page and create a filepath that represents every single byte of the UTF-8 string. These behaviors are not only broken but also disregard the documented INI settings. This patch solves the issies with the multibyte paths on Windows by intelligently enforcing the usage of the Unicode aware APIs. For functions expect Unicode (fe CreateFileW, FindFirstFileW, etc.), arguments will be converted to UTF-16 wide chars. For functions returning Unicode aware data (fe GetCurrentDirectoryW, etc.), resulting wide string is converted back to char's depending on the current PHP charset settings, either to the current ANSI codepage (this is the behavior prior to this patch) or to UTF-8 (the default behavior). In a particular case, users might have to explicitly set internal_encoding or default_charset, if filenames in ANSI codepage are necessary. Current tests show no regressions and witness that this will be an exotic case, the current default UTF-8 encoding is compatible with any supported system. The dependency libraries are long switching to Unicode APIs, so some tests were also added for extensions not directly related to streams. At large, the patch brings over 150 related tests into the core. Those target and was run on various environments with European, Asian, etc. codepages. General PHP frameworks was tested and showed no regressions. The impact on the current C code base is low, the most places affected are the Windows only places in the three files tsrm_win32.c, zend_virtual_cwd.c and plain_wrapper.c. The actual implementation of the most of the wide char supporting functionality is in win32/ioutil.* and win32/codepage.*, several low level functionsare extended in place to avoid reimplementation for now. No performance impact was sighted. As previously mentioned, the ANSI APIs used prior the patch perform Unicode conversions internally. Using the Unicode APIs directly while doing custom conversions just retains the status quo. The ways to optimize it are open (fe. by implementing caching for the strings converted to wide variants). The long path implementation is user transparent. If a path exceeds the length of _MAX_PATH, it'll be automatically prefixed with \\?\. The MAXPATHLEN is set to 2048 bytes. Appreciation to Pierre Joye, Matt Ficken, @algo13 and others for tips, ideas and testing. Thanks.
2016-06-20 07:32:19 +00:00
FREE_PATHW()
return -1;
}
}
Fixed the UTF-8 and long path support in the streams on Windows. Since long the default PHP charset is UTF-8, however the Windows part is out of step with this important point. The current implementation in PHP doesn't technically permit to handle UTF-8 filepath and several other things. Till now, only the ANSI compatible APIs are being used. Here is more about it https://msdn.microsoft.com/en-us/library/windows/desktop/dd317752%28v=vs.85%29.aspx The patch fixes not only issues with multibyte filenames under incompatible codepages, but indirectly also issues with some other multibyte encodings like BIG5, Shift-JIS, etc. by providing a clean way to access filenames in UTF-8. Below is a small list of issues from the bug tracker, that are getting fixed: https://bugs.php.net/63401 https://bugs.php.net/41199 https://bugs.php.net/50203 https://bugs.php.net/71509 https://bugs.php.net/64699 https://bugs.php.net/64506 https://bugs.php.net/30195 https://bugs.php.net/65358 https://bugs.php.net/61315 https://bugs.php.net/70943 https://bugs.php.net/70903 https://bugs.php.net/63593 https://bugs.php.net/54977 https://bugs.php.net/54028 https://bugs.php.net/43148 https://bugs.php.net/30730 https://bugs.php.net/33350 https://bugs.php.net/35300 https://bugs.php.net/46990 https://bugs.php.net/61309 https://bugs.php.net/69333 https://bugs.php.net/45517 https://bugs.php.net/70551 https://bugs.php.net/50197 https://bugs.php.net/72200 https://bugs.php.net/37672 Yet more related tickets can for sure be found - on bugs.php.net, Stackoverflow and Github. Some of the bugs are pretty recent, some descend to early 2000th, but the user comments in there last even till today. Just for example, bug #30195 was opened in 2004, the latest comment in there was made in 2014. It is certain, that these bugs descend not only to pure PHP use cases, but get also redirected from the popular PHP based projects. Given the modern systems (and those supported by PHP) are always based on NTFS, there is no excuse to keep these issues unresolved. The internalization approach on Windows is in many ways different from UNIX and Linux, while it supports and is based on Unicode. It depends on the current system code page, APIs used and exact kind how the binary was compiled The locale doesn't affect the way Unicode or ANSI API work. PHP in particular is being compiled without _UNICODE defined and this is conditioned by the way we handle strings. Here is more about it https://msdn.microsoft.com/en-us/library/tsbaswba.aspx However, with any system code page ANSI functions automatically convert paths to UTF-16. Paths in some encodings incompatible with the current system code page, won't work correctly with ANSI APIs. PHP till now only uses the ANSI Windows APIs. For example, on a system with the current code page 1252, the paths in cp1252 are supported and transparently converted to UTF-16 by the ANSI functions. Once one wants to handle a filepath encoded with cp932 on that particular system, an ANSI or a POSIX compatible function used in PHP will produce an erroneous result. When trying to convert that cp932 path to UTF-8 and passing to the ANSI functions, an ANSI function would likely interpret the UTF-8 string as some string in the current code page and create a filepath that represents every single byte of the UTF-8 string. These behaviors are not only broken but also disregard the documented INI settings. This patch solves the issies with the multibyte paths on Windows by intelligently enforcing the usage of the Unicode aware APIs. For functions expect Unicode (fe CreateFileW, FindFirstFileW, etc.), arguments will be converted to UTF-16 wide chars. For functions returning Unicode aware data (fe GetCurrentDirectoryW, etc.), resulting wide string is converted back to char's depending on the current PHP charset settings, either to the current ANSI codepage (this is the behavior prior to this patch) or to UTF-8 (the default behavior). In a particular case, users might have to explicitly set internal_encoding or default_charset, if filenames in ANSI codepage are necessary. Current tests show no regressions and witness that this will be an exotic case, the current default UTF-8 encoding is compatible with any supported system. The dependency libraries are long switching to Unicode APIs, so some tests were also added for extensions not directly related to streams. At large, the patch brings over 150 related tests into the core. Those target and was run on various environments with European, Asian, etc. codepages. General PHP frameworks was tested and showed no regressions. The impact on the current C code base is low, the most places affected are the Windows only places in the three files tsrm_win32.c, zend_virtual_cwd.c and plain_wrapper.c. The actual implementation of the most of the wide char supporting functionality is in win32/ioutil.* and win32/codepage.*, several low level functionsare extended in place to avoid reimplementation for now. No performance impact was sighted. As previously mentioned, the ANSI APIs used prior the patch perform Unicode conversions internally. Using the Unicode APIs directly while doing custom conversions just retains the status quo. The ways to optimize it are open (fe. by implementing caching for the strings converted to wide variants). The long path implementation is user transparent. If a path exceeds the length of _MAX_PATH, it'll be automatically prefixed with \\?\. The MAXPATHLEN is set to 2048 bytes. Appreciation to Pierre Joye, Matt Ficken, @algo13 and others for tips, ideas and testing. Thanks.
2016-06-20 07:32:19 +00:00
directory = (dataw.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY);
if(link_is_dir) {
*link_is_dir = directory;
}
}
else {
if (save) {
Fixed the UTF-8 and long path support in the streams on Windows. Since long the default PHP charset is UTF-8, however the Windows part is out of step with this important point. The current implementation in PHP doesn't technically permit to handle UTF-8 filepath and several other things. Till now, only the ANSI compatible APIs are being used. Here is more about it https://msdn.microsoft.com/en-us/library/windows/desktop/dd317752%28v=vs.85%29.aspx The patch fixes not only issues with multibyte filenames under incompatible codepages, but indirectly also issues with some other multibyte encodings like BIG5, Shift-JIS, etc. by providing a clean way to access filenames in UTF-8. Below is a small list of issues from the bug tracker, that are getting fixed: https://bugs.php.net/63401 https://bugs.php.net/41199 https://bugs.php.net/50203 https://bugs.php.net/71509 https://bugs.php.net/64699 https://bugs.php.net/64506 https://bugs.php.net/30195 https://bugs.php.net/65358 https://bugs.php.net/61315 https://bugs.php.net/70943 https://bugs.php.net/70903 https://bugs.php.net/63593 https://bugs.php.net/54977 https://bugs.php.net/54028 https://bugs.php.net/43148 https://bugs.php.net/30730 https://bugs.php.net/33350 https://bugs.php.net/35300 https://bugs.php.net/46990 https://bugs.php.net/61309 https://bugs.php.net/69333 https://bugs.php.net/45517 https://bugs.php.net/70551 https://bugs.php.net/50197 https://bugs.php.net/72200 https://bugs.php.net/37672 Yet more related tickets can for sure be found - on bugs.php.net, Stackoverflow and Github. Some of the bugs are pretty recent, some descend to early 2000th, but the user comments in there last even till today. Just for example, bug #30195 was opened in 2004, the latest comment in there was made in 2014. It is certain, that these bugs descend not only to pure PHP use cases, but get also redirected from the popular PHP based projects. Given the modern systems (and those supported by PHP) are always based on NTFS, there is no excuse to keep these issues unresolved. The internalization approach on Windows is in many ways different from UNIX and Linux, while it supports and is based on Unicode. It depends on the current system code page, APIs used and exact kind how the binary was compiled The locale doesn't affect the way Unicode or ANSI API work. PHP in particular is being compiled without _UNICODE defined and this is conditioned by the way we handle strings. Here is more about it https://msdn.microsoft.com/en-us/library/tsbaswba.aspx However, with any system code page ANSI functions automatically convert paths to UTF-16. Paths in some encodings incompatible with the current system code page, won't work correctly with ANSI APIs. PHP till now only uses the ANSI Windows APIs. For example, on a system with the current code page 1252, the paths in cp1252 are supported and transparently converted to UTF-16 by the ANSI functions. Once one wants to handle a filepath encoded with cp932 on that particular system, an ANSI or a POSIX compatible function used in PHP will produce an erroneous result. When trying to convert that cp932 path to UTF-8 and passing to the ANSI functions, an ANSI function would likely interpret the UTF-8 string as some string in the current code page and create a filepath that represents every single byte of the UTF-8 string. These behaviors are not only broken but also disregard the documented INI settings. This patch solves the issies with the multibyte paths on Windows by intelligently enforcing the usage of the Unicode aware APIs. For functions expect Unicode (fe CreateFileW, FindFirstFileW, etc.), arguments will be converted to UTF-16 wide chars. For functions returning Unicode aware data (fe GetCurrentDirectoryW, etc.), resulting wide string is converted back to char's depending on the current PHP charset settings, either to the current ANSI codepage (this is the behavior prior to this patch) or to UTF-8 (the default behavior). In a particular case, users might have to explicitly set internal_encoding or default_charset, if filenames in ANSI codepage are necessary. Current tests show no regressions and witness that this will be an exotic case, the current default UTF-8 encoding is compatible with any supported system. The dependency libraries are long switching to Unicode APIs, so some tests were also added for extensions not directly related to streams. At large, the patch brings over 150 related tests into the core. Those target and was run on various environments with European, Asian, etc. codepages. General PHP frameworks was tested and showed no regressions. The impact on the current C code base is low, the most places affected are the Windows only places in the three files tsrm_win32.c, zend_virtual_cwd.c and plain_wrapper.c. The actual implementation of the most of the wide char supporting functionality is in win32/ioutil.* and win32/codepage.*, several low level functionsare extended in place to avoid reimplementation for now. No performance impact was sighted. As previously mentioned, the ANSI APIs used prior the patch perform Unicode conversions internally. Using the Unicode APIs directly while doing custom conversions just retains the status quo. The ways to optimize it are open (fe. by implementing caching for the strings converted to wide variants). The long path implementation is user transparent. If a path exceeds the length of _MAX_PATH, it'll be automatically prefixed with \\?\. The MAXPATHLEN is set to 2048 bytes. Appreciation to Pierre Joye, Matt Ficken, @algo13 and others for tips, ideas and testing. Thanks.
2016-06-20 07:32:19 +00:00
directory = (dataw.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY) != 0;
if (is_dir && !directory) {
/* not a directory */
Fixed the UTF-8 and long path support in the streams on Windows. Since long the default PHP charset is UTF-8, however the Windows part is out of step with this important point. The current implementation in PHP doesn't technically permit to handle UTF-8 filepath and several other things. Till now, only the ANSI compatible APIs are being used. Here is more about it https://msdn.microsoft.com/en-us/library/windows/desktop/dd317752%28v=vs.85%29.aspx The patch fixes not only issues with multibyte filenames under incompatible codepages, but indirectly also issues with some other multibyte encodings like BIG5, Shift-JIS, etc. by providing a clean way to access filenames in UTF-8. Below is a small list of issues from the bug tracker, that are getting fixed: https://bugs.php.net/63401 https://bugs.php.net/41199 https://bugs.php.net/50203 https://bugs.php.net/71509 https://bugs.php.net/64699 https://bugs.php.net/64506 https://bugs.php.net/30195 https://bugs.php.net/65358 https://bugs.php.net/61315 https://bugs.php.net/70943 https://bugs.php.net/70903 https://bugs.php.net/63593 https://bugs.php.net/54977 https://bugs.php.net/54028 https://bugs.php.net/43148 https://bugs.php.net/30730 https://bugs.php.net/33350 https://bugs.php.net/35300 https://bugs.php.net/46990 https://bugs.php.net/61309 https://bugs.php.net/69333 https://bugs.php.net/45517 https://bugs.php.net/70551 https://bugs.php.net/50197 https://bugs.php.net/72200 https://bugs.php.net/37672 Yet more related tickets can for sure be found - on bugs.php.net, Stackoverflow and Github. Some of the bugs are pretty recent, some descend to early 2000th, but the user comments in there last even till today. Just for example, bug #30195 was opened in 2004, the latest comment in there was made in 2014. It is certain, that these bugs descend not only to pure PHP use cases, but get also redirected from the popular PHP based projects. Given the modern systems (and those supported by PHP) are always based on NTFS, there is no excuse to keep these issues unresolved. The internalization approach on Windows is in many ways different from UNIX and Linux, while it supports and is based on Unicode. It depends on the current system code page, APIs used and exact kind how the binary was compiled The locale doesn't affect the way Unicode or ANSI API work. PHP in particular is being compiled without _UNICODE defined and this is conditioned by the way we handle strings. Here is more about it https://msdn.microsoft.com/en-us/library/tsbaswba.aspx However, with any system code page ANSI functions automatically convert paths to UTF-16. Paths in some encodings incompatible with the current system code page, won't work correctly with ANSI APIs. PHP till now only uses the ANSI Windows APIs. For example, on a system with the current code page 1252, the paths in cp1252 are supported and transparently converted to UTF-16 by the ANSI functions. Once one wants to handle a filepath encoded with cp932 on that particular system, an ANSI or a POSIX compatible function used in PHP will produce an erroneous result. When trying to convert that cp932 path to UTF-8 and passing to the ANSI functions, an ANSI function would likely interpret the UTF-8 string as some string in the current code page and create a filepath that represents every single byte of the UTF-8 string. These behaviors are not only broken but also disregard the documented INI settings. This patch solves the issies with the multibyte paths on Windows by intelligently enforcing the usage of the Unicode aware APIs. For functions expect Unicode (fe CreateFileW, FindFirstFileW, etc.), arguments will be converted to UTF-16 wide chars. For functions returning Unicode aware data (fe GetCurrentDirectoryW, etc.), resulting wide string is converted back to char's depending on the current PHP charset settings, either to the current ANSI codepage (this is the behavior prior to this patch) or to UTF-8 (the default behavior). In a particular case, users might have to explicitly set internal_encoding or default_charset, if filenames in ANSI codepage are necessary. Current tests show no regressions and witness that this will be an exotic case, the current default UTF-8 encoding is compatible with any supported system. The dependency libraries are long switching to Unicode APIs, so some tests were also added for extensions not directly related to streams. At large, the patch brings over 150 related tests into the core. Those target and was run on various environments with European, Asian, etc. codepages. General PHP frameworks was tested and showed no regressions. The impact on the current C code base is low, the most places affected are the Windows only places in the three files tsrm_win32.c, zend_virtual_cwd.c and plain_wrapper.c. The actual implementation of the most of the wide char supporting functionality is in win32/ioutil.* and win32/codepage.*, several low level functionsare extended in place to avoid reimplementation for now. No performance impact was sighted. As previously mentioned, the ANSI APIs used prior the patch perform Unicode conversions internally. Using the Unicode APIs directly while doing custom conversions just retains the status quo. The ways to optimize it are open (fe. by implementing caching for the strings converted to wide variants). The long path implementation is user transparent. If a path exceeds the length of _MAX_PATH, it'll be automatically prefixed with \\?\. The MAXPATHLEN is set to 2048 bytes. Appreciation to Pierre Joye, Matt Ficken, @algo13 and others for tips, ideas and testing. Thanks.
2016-06-20 07:32:19 +00:00
free_alloca(tmp, use_heap);
FREE_PATHW()
return -1;
}
}
#else
2010-09-13 10:27:55 +00:00
if (save && php_sys_lstat(path, &st) < 0) {
if (use_realpath == CWD_REALPATH) {
/* file not found */
return -1;
}
/* continue resolution anyway but don't save result in the cache */
save = 0;
}
tmp = do_alloca(len+1, use_heap);
memcpy(tmp, path, len+1);
if (save && S_ISLNK(st.st_mode)) {
2010-09-13 09:30:07 +00:00
if (++(*ll) > LINK_MAX || (j = php_sys_readlink(tmp, path, MAXPATHLEN)) < 0) {
2010-08-27 10:09:52 +00:00
/* too many links or broken symlinks */
free_alloca(tmp, use_heap);
return -1;
}
path[j] = 0;
if (IS_ABSOLUTE_PATH(path, j)) {
2014-12-13 22:06:14 +00:00
j = tsrm_realpath_r(path, 1, j, ll, t, use_realpath, is_dir, &directory);
if (j < 0) {
free_alloca(tmp, use_heap);
return -1;
}
} else {
2010-08-27 10:09:52 +00:00
if (i + j >= MAXPATHLEN-1) {
free_alloca(tmp, use_heap);
return -1; /* buffer overflow */
2010-08-27 10:09:52 +00:00
}
memmove(path+i, path, j+1);
memcpy(path, tmp, i-1);
path[i-1] = DEFAULT_SLASH;
2014-12-13 22:06:14 +00:00
j = tsrm_realpath_r(path, start, i + j, ll, t, use_realpath, is_dir, &directory);
if (j < 0) {
free_alloca(tmp, use_heap);
return -1;
}
}
if (link_is_dir) {
*link_is_dir = directory;
}
} else {
if (save) {
directory = S_ISDIR(st.st_mode);
2008-08-15 13:31:58 +00:00
if (link_is_dir) {
*link_is_dir = directory;
}
if (is_dir && !directory) {
/* not a directory */
free_alloca(tmp, use_heap);
return -1;
}
}
#endif
if (i - 1 <= start) {
j = start;
} else {
/* some leading directories may be unaccessable */
2014-12-13 22:06:14 +00:00
j = tsrm_realpath_r(path, start, i-1, ll, t, save ? CWD_FILEPATH : use_realpath, 1, NULL);
if (j > start) {
path[j++] = DEFAULT_SLASH;
}
}
#ifdef ZEND_WIN32
if (j < 0 || j + len - i >= MAXPATHLEN-1) {
free_alloca(tmp, use_heap);
Fixed the UTF-8 and long path support in the streams on Windows. Since long the default PHP charset is UTF-8, however the Windows part is out of step with this important point. The current implementation in PHP doesn't technically permit to handle UTF-8 filepath and several other things. Till now, only the ANSI compatible APIs are being used. Here is more about it https://msdn.microsoft.com/en-us/library/windows/desktop/dd317752%28v=vs.85%29.aspx The patch fixes not only issues with multibyte filenames under incompatible codepages, but indirectly also issues with some other multibyte encodings like BIG5, Shift-JIS, etc. by providing a clean way to access filenames in UTF-8. Below is a small list of issues from the bug tracker, that are getting fixed: https://bugs.php.net/63401 https://bugs.php.net/41199 https://bugs.php.net/50203 https://bugs.php.net/71509 https://bugs.php.net/64699 https://bugs.php.net/64506 https://bugs.php.net/30195 https://bugs.php.net/65358 https://bugs.php.net/61315 https://bugs.php.net/70943 https://bugs.php.net/70903 https://bugs.php.net/63593 https://bugs.php.net/54977 https://bugs.php.net/54028 https://bugs.php.net/43148 https://bugs.php.net/30730 https://bugs.php.net/33350 https://bugs.php.net/35300 https://bugs.php.net/46990 https://bugs.php.net/61309 https://bugs.php.net/69333 https://bugs.php.net/45517 https://bugs.php.net/70551 https://bugs.php.net/50197 https://bugs.php.net/72200 https://bugs.php.net/37672 Yet more related tickets can for sure be found - on bugs.php.net, Stackoverflow and Github. Some of the bugs are pretty recent, some descend to early 2000th, but the user comments in there last even till today. Just for example, bug #30195 was opened in 2004, the latest comment in there was made in 2014. It is certain, that these bugs descend not only to pure PHP use cases, but get also redirected from the popular PHP based projects. Given the modern systems (and those supported by PHP) are always based on NTFS, there is no excuse to keep these issues unresolved. The internalization approach on Windows is in many ways different from UNIX and Linux, while it supports and is based on Unicode. It depends on the current system code page, APIs used and exact kind how the binary was compiled The locale doesn't affect the way Unicode or ANSI API work. PHP in particular is being compiled without _UNICODE defined and this is conditioned by the way we handle strings. Here is more about it https://msdn.microsoft.com/en-us/library/tsbaswba.aspx However, with any system code page ANSI functions automatically convert paths to UTF-16. Paths in some encodings incompatible with the current system code page, won't work correctly with ANSI APIs. PHP till now only uses the ANSI Windows APIs. For example, on a system with the current code page 1252, the paths in cp1252 are supported and transparently converted to UTF-16 by the ANSI functions. Once one wants to handle a filepath encoded with cp932 on that particular system, an ANSI or a POSIX compatible function used in PHP will produce an erroneous result. When trying to convert that cp932 path to UTF-8 and passing to the ANSI functions, an ANSI function would likely interpret the UTF-8 string as some string in the current code page and create a filepath that represents every single byte of the UTF-8 string. These behaviors are not only broken but also disregard the documented INI settings. This patch solves the issies with the multibyte paths on Windows by intelligently enforcing the usage of the Unicode aware APIs. For functions expect Unicode (fe CreateFileW, FindFirstFileW, etc.), arguments will be converted to UTF-16 wide chars. For functions returning Unicode aware data (fe GetCurrentDirectoryW, etc.), resulting wide string is converted back to char's depending on the current PHP charset settings, either to the current ANSI codepage (this is the behavior prior to this patch) or to UTF-8 (the default behavior). In a particular case, users might have to explicitly set internal_encoding or default_charset, if filenames in ANSI codepage are necessary. Current tests show no regressions and witness that this will be an exotic case, the current default UTF-8 encoding is compatible with any supported system. The dependency libraries are long switching to Unicode APIs, so some tests were also added for extensions not directly related to streams. At large, the patch brings over 150 related tests into the core. Those target and was run on various environments with European, Asian, etc. codepages. General PHP frameworks was tested and showed no regressions. The impact on the current C code base is low, the most places affected are the Windows only places in the three files tsrm_win32.c, zend_virtual_cwd.c and plain_wrapper.c. The actual implementation of the most of the wide char supporting functionality is in win32/ioutil.* and win32/codepage.*, several low level functionsare extended in place to avoid reimplementation for now. No performance impact was sighted. As previously mentioned, the ANSI APIs used prior the patch perform Unicode conversions internally. Using the Unicode APIs directly while doing custom conversions just retains the status quo. The ways to optimize it are open (fe. by implementing caching for the strings converted to wide variants). The long path implementation is user transparent. If a path exceeds the length of _MAX_PATH, it'll be automatically prefixed with \\?\. The MAXPATHLEN is set to 2048 bytes. Appreciation to Pierre Joye, Matt Ficken, @algo13 and others for tips, ideas and testing. Thanks.
2016-06-20 07:32:19 +00:00
FREE_PATHW()
return -1;
}
if (save) {
Fixed the UTF-8 and long path support in the streams on Windows. Since long the default PHP charset is UTF-8, however the Windows part is out of step with this important point. The current implementation in PHP doesn't technically permit to handle UTF-8 filepath and several other things. Till now, only the ANSI compatible APIs are being used. Here is more about it https://msdn.microsoft.com/en-us/library/windows/desktop/dd317752%28v=vs.85%29.aspx The patch fixes not only issues with multibyte filenames under incompatible codepages, but indirectly also issues with some other multibyte encodings like BIG5, Shift-JIS, etc. by providing a clean way to access filenames in UTF-8. Below is a small list of issues from the bug tracker, that are getting fixed: https://bugs.php.net/63401 https://bugs.php.net/41199 https://bugs.php.net/50203 https://bugs.php.net/71509 https://bugs.php.net/64699 https://bugs.php.net/64506 https://bugs.php.net/30195 https://bugs.php.net/65358 https://bugs.php.net/61315 https://bugs.php.net/70943 https://bugs.php.net/70903 https://bugs.php.net/63593 https://bugs.php.net/54977 https://bugs.php.net/54028 https://bugs.php.net/43148 https://bugs.php.net/30730 https://bugs.php.net/33350 https://bugs.php.net/35300 https://bugs.php.net/46990 https://bugs.php.net/61309 https://bugs.php.net/69333 https://bugs.php.net/45517 https://bugs.php.net/70551 https://bugs.php.net/50197 https://bugs.php.net/72200 https://bugs.php.net/37672 Yet more related tickets can for sure be found - on bugs.php.net, Stackoverflow and Github. Some of the bugs are pretty recent, some descend to early 2000th, but the user comments in there last even till today. Just for example, bug #30195 was opened in 2004, the latest comment in there was made in 2014. It is certain, that these bugs descend not only to pure PHP use cases, but get also redirected from the popular PHP based projects. Given the modern systems (and those supported by PHP) are always based on NTFS, there is no excuse to keep these issues unresolved. The internalization approach on Windows is in many ways different from UNIX and Linux, while it supports and is based on Unicode. It depends on the current system code page, APIs used and exact kind how the binary was compiled The locale doesn't affect the way Unicode or ANSI API work. PHP in particular is being compiled without _UNICODE defined and this is conditioned by the way we handle strings. Here is more about it https://msdn.microsoft.com/en-us/library/tsbaswba.aspx However, with any system code page ANSI functions automatically convert paths to UTF-16. Paths in some encodings incompatible with the current system code page, won't work correctly with ANSI APIs. PHP till now only uses the ANSI Windows APIs. For example, on a system with the current code page 1252, the paths in cp1252 are supported and transparently converted to UTF-16 by the ANSI functions. Once one wants to handle a filepath encoded with cp932 on that particular system, an ANSI or a POSIX compatible function used in PHP will produce an erroneous result. When trying to convert that cp932 path to UTF-8 and passing to the ANSI functions, an ANSI function would likely interpret the UTF-8 string as some string in the current code page and create a filepath that represents every single byte of the UTF-8 string. These behaviors are not only broken but also disregard the documented INI settings. This patch solves the issies with the multibyte paths on Windows by intelligently enforcing the usage of the Unicode aware APIs. For functions expect Unicode (fe CreateFileW, FindFirstFileW, etc.), arguments will be converted to UTF-16 wide chars. For functions returning Unicode aware data (fe GetCurrentDirectoryW, etc.), resulting wide string is converted back to char's depending on the current PHP charset settings, either to the current ANSI codepage (this is the behavior prior to this patch) or to UTF-8 (the default behavior). In a particular case, users might have to explicitly set internal_encoding or default_charset, if filenames in ANSI codepage are necessary. Current tests show no regressions and witness that this will be an exotic case, the current default UTF-8 encoding is compatible with any supported system. The dependency libraries are long switching to Unicode APIs, so some tests were also added for extensions not directly related to streams. At large, the patch brings over 150 related tests into the core. Those target and was run on various environments with European, Asian, etc. codepages. General PHP frameworks was tested and showed no regressions. The impact on the current C code base is low, the most places affected are the Windows only places in the three files tsrm_win32.c, zend_virtual_cwd.c and plain_wrapper.c. The actual implementation of the most of the wide char supporting functionality is in win32/ioutil.* and win32/codepage.*, several low level functionsare extended in place to avoid reimplementation for now. No performance impact was sighted. As previously mentioned, the ANSI APIs used prior the patch perform Unicode conversions internally. Using the Unicode APIs directly while doing custom conversions just retains the status quo. The ways to optimize it are open (fe. by implementing caching for the strings converted to wide variants). The long path implementation is user transparent. If a path exceeds the length of _MAX_PATH, it'll be automatically prefixed with \\?\. The MAXPATHLEN is set to 2048 bytes. Appreciation to Pierre Joye, Matt Ficken, @algo13 and others for tips, ideas and testing. Thanks.
2016-06-20 07:32:19 +00:00
size_t sz;
char *tmp_path = php_win32_ioutil_conv_w_to_any(dataw.cFileName, PHP_WIN32_CP_IGNORE_LEN, &sz);
if (!tmp_path) {
free_alloca(tmp, use_heap);
FREE_PATHW()
return -1;
}
i = (int)sz;
memcpy(path+j, tmp_path, i+1);
free(tmp_path);
j += i;
} else {
/* use the original file or directory name as it wasn't found */
memcpy(path+j, tmp+i, len-i+1);
j += (len-i);
}
}
#else
if (j < 0 || j + len - i >= MAXPATHLEN-1) {
free_alloca(tmp, use_heap);
return -1;
}
memcpy(path+j, tmp+i, len-i+1);
j += (len-i);
}
#endif
if (save && start && CWDG(realpath_cache_size_limit)) {
/* save absolute path in the cache */
2014-12-13 22:06:14 +00:00
realpath_cache_add(tmp, len, path, j, directory, *t);
}
free_alloca(tmp, use_heap);
Fixed the UTF-8 and long path support in the streams on Windows. Since long the default PHP charset is UTF-8, however the Windows part is out of step with this important point. The current implementation in PHP doesn't technically permit to handle UTF-8 filepath and several other things. Till now, only the ANSI compatible APIs are being used. Here is more about it https://msdn.microsoft.com/en-us/library/windows/desktop/dd317752%28v=vs.85%29.aspx The patch fixes not only issues with multibyte filenames under incompatible codepages, but indirectly also issues with some other multibyte encodings like BIG5, Shift-JIS, etc. by providing a clean way to access filenames in UTF-8. Below is a small list of issues from the bug tracker, that are getting fixed: https://bugs.php.net/63401 https://bugs.php.net/41199 https://bugs.php.net/50203 https://bugs.php.net/71509 https://bugs.php.net/64699 https://bugs.php.net/64506 https://bugs.php.net/30195 https://bugs.php.net/65358 https://bugs.php.net/61315 https://bugs.php.net/70943 https://bugs.php.net/70903 https://bugs.php.net/63593 https://bugs.php.net/54977 https://bugs.php.net/54028 https://bugs.php.net/43148 https://bugs.php.net/30730 https://bugs.php.net/33350 https://bugs.php.net/35300 https://bugs.php.net/46990 https://bugs.php.net/61309 https://bugs.php.net/69333 https://bugs.php.net/45517 https://bugs.php.net/70551 https://bugs.php.net/50197 https://bugs.php.net/72200 https://bugs.php.net/37672 Yet more related tickets can for sure be found - on bugs.php.net, Stackoverflow and Github. Some of the bugs are pretty recent, some descend to early 2000th, but the user comments in there last even till today. Just for example, bug #30195 was opened in 2004, the latest comment in there was made in 2014. It is certain, that these bugs descend not only to pure PHP use cases, but get also redirected from the popular PHP based projects. Given the modern systems (and those supported by PHP) are always based on NTFS, there is no excuse to keep these issues unresolved. The internalization approach on Windows is in many ways different from UNIX and Linux, while it supports and is based on Unicode. It depends on the current system code page, APIs used and exact kind how the binary was compiled The locale doesn't affect the way Unicode or ANSI API work. PHP in particular is being compiled without _UNICODE defined and this is conditioned by the way we handle strings. Here is more about it https://msdn.microsoft.com/en-us/library/tsbaswba.aspx However, with any system code page ANSI functions automatically convert paths to UTF-16. Paths in some encodings incompatible with the current system code page, won't work correctly with ANSI APIs. PHP till now only uses the ANSI Windows APIs. For example, on a system with the current code page 1252, the paths in cp1252 are supported and transparently converted to UTF-16 by the ANSI functions. Once one wants to handle a filepath encoded with cp932 on that particular system, an ANSI or a POSIX compatible function used in PHP will produce an erroneous result. When trying to convert that cp932 path to UTF-8 and passing to the ANSI functions, an ANSI function would likely interpret the UTF-8 string as some string in the current code page and create a filepath that represents every single byte of the UTF-8 string. These behaviors are not only broken but also disregard the documented INI settings. This patch solves the issies with the multibyte paths on Windows by intelligently enforcing the usage of the Unicode aware APIs. For functions expect Unicode (fe CreateFileW, FindFirstFileW, etc.), arguments will be converted to UTF-16 wide chars. For functions returning Unicode aware data (fe GetCurrentDirectoryW, etc.), resulting wide string is converted back to char's depending on the current PHP charset settings, either to the current ANSI codepage (this is the behavior prior to this patch) or to UTF-8 (the default behavior). In a particular case, users might have to explicitly set internal_encoding or default_charset, if filenames in ANSI codepage are necessary. Current tests show no regressions and witness that this will be an exotic case, the current default UTF-8 encoding is compatible with any supported system. The dependency libraries are long switching to Unicode APIs, so some tests were also added for extensions not directly related to streams. At large, the patch brings over 150 related tests into the core. Those target and was run on various environments with European, Asian, etc. codepages. General PHP frameworks was tested and showed no regressions. The impact on the current C code base is low, the most places affected are the Windows only places in the three files tsrm_win32.c, zend_virtual_cwd.c and plain_wrapper.c. The actual implementation of the most of the wide char supporting functionality is in win32/ioutil.* and win32/codepage.*, several low level functionsare extended in place to avoid reimplementation for now. No performance impact was sighted. As previously mentioned, the ANSI APIs used prior the patch perform Unicode conversions internally. Using the Unicode APIs directly while doing custom conversions just retains the status quo. The ways to optimize it are open (fe. by implementing caching for the strings converted to wide variants). The long path implementation is user transparent. If a path exceeds the length of _MAX_PATH, it'll be automatically prefixed with \\?\. The MAXPATHLEN is set to 2048 bytes. Appreciation to Pierre Joye, Matt Ficken, @algo13 and others for tips, ideas and testing. Thanks.
2016-06-20 07:32:19 +00:00
#ifdef ZEND_WIN32
FREE_PATHW()
#undef FREE_PATHW
#endif
return j;
}
}
/* }}} */
/* Resolve path relatively to state and put the real path into state */
/* returns 0 for ok, 1 for error */
2014-12-13 22:06:14 +00:00
CWD_API int virtual_file_ex(cwd_state *state, const char *path, verify_path_func verify_path, int use_realpath) /* {{{ */
{
2014-10-24 18:57:38 +00:00
int path_length = (int)strlen(path);
char resolved_path[MAXPATHLEN];
int start = 1;
int ll = 0;
time_t t;
int ret;
int add_slash;
2009-10-19 23:41:14 +00:00
void *tmp;
if (path_length <= 0 || path_length >= MAXPATHLEN-1) {
#ifdef ZEND_WIN32
_set_errno(EINVAL);
#else
2010-02-01 15:31:58 +00:00
errno = EINVAL;
#endif
return 1;
}
#if VIRTUAL_CWD_DEBUG
fprintf(stderr,"cwd = %s path = %s\n", state->cwd, path);
2001-05-03 15:50:37 +00:00
#endif
/* cwd_length can be 0 when getcwd() fails.
* This can happen under solaris when a dir does not have read permissions
* but *does* have execute permissions */
if (!IS_ABSOLUTE_PATH(path, path_length)) {
if (state->cwd_length == 0) {
/* resolve relative path */
start = 0;
memcpy(resolved_path , path, path_length + 1);
} else {
int state_cwd_length = state->cwd_length;
#ifdef ZEND_WIN32
if (IS_SLASH(path[0])) {
if (state->cwd[1] == ':') {
/* Copy only the drive name */
state_cwd_length = 2;
} else if (IS_UNC_PATH(state->cwd, state->cwd_length)) {
/* Copy only the share name */
state_cwd_length = 2;
while (IS_SLASH(state->cwd[state_cwd_length])) {
state_cwd_length++;
2010-09-10 14:02:19 +00:00
}
while (state->cwd[state_cwd_length] &&
2010-08-27 10:09:52 +00:00
!IS_SLASH(state->cwd[state_cwd_length])) {
state_cwd_length++;
2010-09-10 14:02:19 +00:00
}
while (IS_SLASH(state->cwd[state_cwd_length])) {
state_cwd_length++;
2010-09-10 14:02:19 +00:00
}
while (state->cwd[state_cwd_length] &&
2010-08-27 10:09:52 +00:00
!IS_SLASH(state->cwd[state_cwd_length])) {
state_cwd_length++;
2010-09-10 14:02:19 +00:00
}
}
}
#endif
if (path_length + state_cwd_length + 1 >= MAXPATHLEN-1) {
return 1;
}
memcpy(resolved_path, state->cwd, state_cwd_length);
if (resolved_path[state_cwd_length-1] == DEFAULT_SLASH) {
memcpy(resolved_path + state_cwd_length, path, path_length + 1);
path_length += state_cwd_length;
} else {
resolved_path[state_cwd_length] = DEFAULT_SLASH;
memcpy(resolved_path + state_cwd_length + 1, path, path_length + 1);
path_length += state_cwd_length + 1;
}
2001-05-05 16:05:19 +00:00
}
2010-09-10 14:02:19 +00:00
} else {
#ifdef ZEND_WIN32
if (path_length > 2 && path[1] == ':' && !IS_SLASH(path[2])) {
resolved_path[0] = path[0];
resolved_path[1] = ':';
resolved_path[2] = DEFAULT_SLASH;
memcpy(resolved_path + 3, path + 2, path_length - 1);
path_length++;
} else
#endif
memcpy(resolved_path, path, path_length + 1);
2010-09-10 14:02:19 +00:00
}
#ifdef ZEND_WIN32
if (memchr(resolved_path, '*', path_length) ||
2010-08-27 10:09:52 +00:00
memchr(resolved_path, '?', path_length)) {
return 1;
}
#endif
#ifdef ZEND_WIN32
if (IS_UNC_PATH(resolved_path, path_length)) {
/* skip UNC name */
resolved_path[0] = DEFAULT_SLASH;
resolved_path[1] = DEFAULT_SLASH;
start = 2;
while (!IS_SLASH(resolved_path[start])) {
if (resolved_path[start] == 0) {
goto verify;
}
resolved_path[start] = toupper(resolved_path[start]);
start++;
}
resolved_path[start++] = DEFAULT_SLASH;
while (!IS_SLASH(resolved_path[start])) {
if (resolved_path[start] == 0) {
goto verify;
}
resolved_path[start] = toupper(resolved_path[start]);
start++;
}
resolved_path[start++] = DEFAULT_SLASH;
} else if (IS_ABSOLUTE_PATH(resolved_path, path_length)) {
/* skip DRIVE name */
resolved_path[0] = toupper(resolved_path[0]);
resolved_path[2] = DEFAULT_SLASH;
start = 3;
}
#endif
add_slash = (use_realpath != CWD_REALPATH) && path_length > 0 && IS_SLASH(resolved_path[path_length-1]);
t = CWDG(realpath_cache_ttl) ? 0 : -1;
2014-12-13 22:06:14 +00:00
path_length = tsrm_realpath_r(resolved_path, start, path_length, &ll, &t, use_realpath, 0, NULL);
2010-09-10 14:02:19 +00:00
if (path_length < 0) {
errno = ENOENT;
return 1;
}
2010-09-10 14:02:19 +00:00
if (!start && !path_length) {
resolved_path[path_length++] = '.';
}
if (add_slash && path_length && !IS_SLASH(resolved_path[path_length-1])) {
if (path_length >= MAXPATHLEN-1) {
return -1;
}
resolved_path[path_length++] = DEFAULT_SLASH;
}
resolved_path[path_length] = 0;
#ifdef ZEND_WIN32
verify:
#endif
if (verify_path) {
cwd_state old_state;
CWD_STATE_COPY(&old_state, state);
state->cwd_length = path_length;
2009-10-19 23:41:14 +00:00
tmp = erealloc(state->cwd, state->cwd_length+1);
2009-10-19 23:41:14 +00:00
state->cwd = (char *) tmp;
memcpy(state->cwd, resolved_path, state->cwd_length+1);
if (verify_path(state)) {
CWD_STATE_FREE(state);
*state = old_state;
ret = 1;
} else {
CWD_STATE_FREE(&old_state);
ret = 0;
}
} else {
state->cwd_length = path_length;
tmp = erealloc(state->cwd, state->cwd_length+1);
2009-10-19 23:41:14 +00:00
state->cwd = (char *) tmp;
memcpy(state->cwd, resolved_path, state->cwd_length+1);
ret = 0;
}
2010-09-10 14:02:19 +00:00
#if VIRTUAL_CWD_DEBUG
fprintf (stderr, "virtual_file_ex() = %s\n",state->cwd);
#endif
return (ret);
}
2007-08-10 09:09:46 +00:00
/* }}} */
2014-12-13 22:06:14 +00:00
CWD_API int virtual_chdir(const char *path) /* {{{ */
{
2014-12-13 22:06:14 +00:00
return virtual_file_ex(&CWDG(cwd), path, php_is_dir_ok, CWD_REALPATH)?-1:0;
}
2007-08-10 09:09:46 +00:00
/* }}} */
2014-12-13 22:06:14 +00:00
CWD_API int virtual_chdir_file(const char *path, int (*p_chdir)(const char *path)) /* {{{ */
{
2014-10-31 17:46:38 +00:00
int length = (int)strlen(path);
char *temp;
int retval;
ALLOCA_FLAG(use_heap)
if (length == 0) {
return 1; /* Can't cd to empty string */
2010-09-10 14:02:19 +00:00
}
while(--length >= 0 && !IS_SLASH(path[length])) {
}
if (length == -1) {
2000-10-03 15:08:37 +00:00
/* No directory only file name */
errno = ENOENT;
return -1;
}
2002-05-29 08:41:21 +00:00
if (length == COPY_WHEN_ABSOLUTE(path) && IS_ABSOLUTE_PATH(path, length+1)) { /* Also use trailing slash if this is absolute */
length++;
}
temp = (char *) do_alloca(length+1, use_heap);
memcpy(temp, path, length);
temp[length] = 0;
#if VIRTUAL_CWD_DEBUG
fprintf (stderr, "Changing directory to %s\n", temp);
#endif
2014-12-13 22:06:14 +00:00
retval = p_chdir(temp);
free_alloca(temp, use_heap);
return retval;
}
2007-08-10 09:09:46 +00:00
/* }}} */
2014-12-13 22:06:14 +00:00
CWD_API char *virtual_realpath(const char *path, char *real_path) /* {{{ */
{
cwd_state new_state;
char *retval;
char cwd[MAXPATHLEN];
/* realpath("") returns CWD */
if (!*path) {
new_state.cwd = (char*)emalloc(1);
new_state.cwd[0] = '\0';
2010-09-10 14:02:19 +00:00
new_state.cwd_length = 0;
2010-08-27 10:09:52 +00:00
if (VCWD_GETCWD(cwd, MAXPATHLEN)) {
path = cwd;
}
} else if (!IS_ABSOLUTE_PATH(path, strlen(path))) {
CWD_STATE_COPY(&new_state, &CWDG(cwd));
} else {
new_state.cwd = (char*)emalloc(1);
new_state.cwd[0] = '\0';
new_state.cwd_length = 0;
}
2009-06-26 07:39:42 +00:00
2014-12-13 22:06:14 +00:00
if (virtual_file_ex(&new_state, path, NULL, CWD_REALPATH)==0) {
int len = new_state.cwd_length>MAXPATHLEN-1?MAXPATHLEN-1:new_state.cwd_length;
memcpy(real_path, new_state.cwd, len);
real_path[len] = '\0';
retval = real_path;
} else {
retval = NULL;
}
CWD_STATE_FREE(&new_state);
return retval;
}
2007-08-10 09:09:46 +00:00
/* }}} */
2014-12-13 22:06:14 +00:00
CWD_API int virtual_filepath_ex(const char *path, char **filepath, verify_path_func verify_path) /* {{{ */
{
cwd_state new_state;
int retval;
CWD_STATE_COPY(&new_state, &CWDG(cwd));
2014-12-13 22:06:14 +00:00
retval = virtual_file_ex(&new_state, path, verify_path, CWD_FILEPATH);
*filepath = new_state.cwd;
return retval;
}
2007-08-10 09:09:46 +00:00
/* }}} */
2014-12-13 22:06:14 +00:00
CWD_API int virtual_filepath(const char *path, char **filepath) /* {{{ */
{
2014-12-13 22:06:14 +00:00
return virtual_filepath_ex(path, filepath, php_is_file_ok);
}
2007-08-10 09:09:46 +00:00
/* }}} */
2014-12-13 22:06:14 +00:00
CWD_API FILE *virtual_fopen(const char *path, const char *mode) /* {{{ */
{
cwd_state new_state;
FILE *f;
if (path[0] == '\0') { /* Fail to open empty path */
return NULL;
}
CWD_STATE_COPY(&new_state, &CWDG(cwd));
2014-12-13 22:06:14 +00:00
if (virtual_file_ex(&new_state, path, NULL, CWD_EXPAND)) {
CWD_STATE_FREE_ERR(&new_state);
return NULL;
}
Fixed the UTF-8 and long path support in the streams on Windows. Since long the default PHP charset is UTF-8, however the Windows part is out of step with this important point. The current implementation in PHP doesn't technically permit to handle UTF-8 filepath and several other things. Till now, only the ANSI compatible APIs are being used. Here is more about it https://msdn.microsoft.com/en-us/library/windows/desktop/dd317752%28v=vs.85%29.aspx The patch fixes not only issues with multibyte filenames under incompatible codepages, but indirectly also issues with some other multibyte encodings like BIG5, Shift-JIS, etc. by providing a clean way to access filenames in UTF-8. Below is a small list of issues from the bug tracker, that are getting fixed: https://bugs.php.net/63401 https://bugs.php.net/41199 https://bugs.php.net/50203 https://bugs.php.net/71509 https://bugs.php.net/64699 https://bugs.php.net/64506 https://bugs.php.net/30195 https://bugs.php.net/65358 https://bugs.php.net/61315 https://bugs.php.net/70943 https://bugs.php.net/70903 https://bugs.php.net/63593 https://bugs.php.net/54977 https://bugs.php.net/54028 https://bugs.php.net/43148 https://bugs.php.net/30730 https://bugs.php.net/33350 https://bugs.php.net/35300 https://bugs.php.net/46990 https://bugs.php.net/61309 https://bugs.php.net/69333 https://bugs.php.net/45517 https://bugs.php.net/70551 https://bugs.php.net/50197 https://bugs.php.net/72200 https://bugs.php.net/37672 Yet more related tickets can for sure be found - on bugs.php.net, Stackoverflow and Github. Some of the bugs are pretty recent, some descend to early 2000th, but the user comments in there last even till today. Just for example, bug #30195 was opened in 2004, the latest comment in there was made in 2014. It is certain, that these bugs descend not only to pure PHP use cases, but get also redirected from the popular PHP based projects. Given the modern systems (and those supported by PHP) are always based on NTFS, there is no excuse to keep these issues unresolved. The internalization approach on Windows is in many ways different from UNIX and Linux, while it supports and is based on Unicode. It depends on the current system code page, APIs used and exact kind how the binary was compiled The locale doesn't affect the way Unicode or ANSI API work. PHP in particular is being compiled without _UNICODE defined and this is conditioned by the way we handle strings. Here is more about it https://msdn.microsoft.com/en-us/library/tsbaswba.aspx However, with any system code page ANSI functions automatically convert paths to UTF-16. Paths in some encodings incompatible with the current system code page, won't work correctly with ANSI APIs. PHP till now only uses the ANSI Windows APIs. For example, on a system with the current code page 1252, the paths in cp1252 are supported and transparently converted to UTF-16 by the ANSI functions. Once one wants to handle a filepath encoded with cp932 on that particular system, an ANSI or a POSIX compatible function used in PHP will produce an erroneous result. When trying to convert that cp932 path to UTF-8 and passing to the ANSI functions, an ANSI function would likely interpret the UTF-8 string as some string in the current code page and create a filepath that represents every single byte of the UTF-8 string. These behaviors are not only broken but also disregard the documented INI settings. This patch solves the issies with the multibyte paths on Windows by intelligently enforcing the usage of the Unicode aware APIs. For functions expect Unicode (fe CreateFileW, FindFirstFileW, etc.), arguments will be converted to UTF-16 wide chars. For functions returning Unicode aware data (fe GetCurrentDirectoryW, etc.), resulting wide string is converted back to char's depending on the current PHP charset settings, either to the current ANSI codepage (this is the behavior prior to this patch) or to UTF-8 (the default behavior). In a particular case, users might have to explicitly set internal_encoding or default_charset, if filenames in ANSI codepage are necessary. Current tests show no regressions and witness that this will be an exotic case, the current default UTF-8 encoding is compatible with any supported system. The dependency libraries are long switching to Unicode APIs, so some tests were also added for extensions not directly related to streams. At large, the patch brings over 150 related tests into the core. Those target and was run on various environments with European, Asian, etc. codepages. General PHP frameworks was tested and showed no regressions. The impact on the current C code base is low, the most places affected are the Windows only places in the three files tsrm_win32.c, zend_virtual_cwd.c and plain_wrapper.c. The actual implementation of the most of the wide char supporting functionality is in win32/ioutil.* and win32/codepage.*, several low level functionsare extended in place to avoid reimplementation for now. No performance impact was sighted. As previously mentioned, the ANSI APIs used prior the patch perform Unicode conversions internally. Using the Unicode APIs directly while doing custom conversions just retains the status quo. The ways to optimize it are open (fe. by implementing caching for the strings converted to wide variants). The long path implementation is user transparent. If a path exceeds the length of _MAX_PATH, it'll be automatically prefixed with \\?\. The MAXPATHLEN is set to 2048 bytes. Appreciation to Pierre Joye, Matt Ficken, @algo13 and others for tips, ideas and testing. Thanks.
2016-06-20 07:32:19 +00:00
#ifdef ZEND_WIN32
f = php_win32_ioutil_fopen(new_state.cwd, mode);
#else
f = fopen(new_state.cwd, mode);
Fixed the UTF-8 and long path support in the streams on Windows. Since long the default PHP charset is UTF-8, however the Windows part is out of step with this important point. The current implementation in PHP doesn't technically permit to handle UTF-8 filepath and several other things. Till now, only the ANSI compatible APIs are being used. Here is more about it https://msdn.microsoft.com/en-us/library/windows/desktop/dd317752%28v=vs.85%29.aspx The patch fixes not only issues with multibyte filenames under incompatible codepages, but indirectly also issues with some other multibyte encodings like BIG5, Shift-JIS, etc. by providing a clean way to access filenames in UTF-8. Below is a small list of issues from the bug tracker, that are getting fixed: https://bugs.php.net/63401 https://bugs.php.net/41199 https://bugs.php.net/50203 https://bugs.php.net/71509 https://bugs.php.net/64699 https://bugs.php.net/64506 https://bugs.php.net/30195 https://bugs.php.net/65358 https://bugs.php.net/61315 https://bugs.php.net/70943 https://bugs.php.net/70903 https://bugs.php.net/63593 https://bugs.php.net/54977 https://bugs.php.net/54028 https://bugs.php.net/43148 https://bugs.php.net/30730 https://bugs.php.net/33350 https://bugs.php.net/35300 https://bugs.php.net/46990 https://bugs.php.net/61309 https://bugs.php.net/69333 https://bugs.php.net/45517 https://bugs.php.net/70551 https://bugs.php.net/50197 https://bugs.php.net/72200 https://bugs.php.net/37672 Yet more related tickets can for sure be found - on bugs.php.net, Stackoverflow and Github. Some of the bugs are pretty recent, some descend to early 2000th, but the user comments in there last even till today. Just for example, bug #30195 was opened in 2004, the latest comment in there was made in 2014. It is certain, that these bugs descend not only to pure PHP use cases, but get also redirected from the popular PHP based projects. Given the modern systems (and those supported by PHP) are always based on NTFS, there is no excuse to keep these issues unresolved. The internalization approach on Windows is in many ways different from UNIX and Linux, while it supports and is based on Unicode. It depends on the current system code page, APIs used and exact kind how the binary was compiled The locale doesn't affect the way Unicode or ANSI API work. PHP in particular is being compiled without _UNICODE defined and this is conditioned by the way we handle strings. Here is more about it https://msdn.microsoft.com/en-us/library/tsbaswba.aspx However, with any system code page ANSI functions automatically convert paths to UTF-16. Paths in some encodings incompatible with the current system code page, won't work correctly with ANSI APIs. PHP till now only uses the ANSI Windows APIs. For example, on a system with the current code page 1252, the paths in cp1252 are supported and transparently converted to UTF-16 by the ANSI functions. Once one wants to handle a filepath encoded with cp932 on that particular system, an ANSI or a POSIX compatible function used in PHP will produce an erroneous result. When trying to convert that cp932 path to UTF-8 and passing to the ANSI functions, an ANSI function would likely interpret the UTF-8 string as some string in the current code page and create a filepath that represents every single byte of the UTF-8 string. These behaviors are not only broken but also disregard the documented INI settings. This patch solves the issies with the multibyte paths on Windows by intelligently enforcing the usage of the Unicode aware APIs. For functions expect Unicode (fe CreateFileW, FindFirstFileW, etc.), arguments will be converted to UTF-16 wide chars. For functions returning Unicode aware data (fe GetCurrentDirectoryW, etc.), resulting wide string is converted back to char's depending on the current PHP charset settings, either to the current ANSI codepage (this is the behavior prior to this patch) or to UTF-8 (the default behavior). In a particular case, users might have to explicitly set internal_encoding or default_charset, if filenames in ANSI codepage are necessary. Current tests show no regressions and witness that this will be an exotic case, the current default UTF-8 encoding is compatible with any supported system. The dependency libraries are long switching to Unicode APIs, so some tests were also added for extensions not directly related to streams. At large, the patch brings over 150 related tests into the core. Those target and was run on various environments with European, Asian, etc. codepages. General PHP frameworks was tested and showed no regressions. The impact on the current C code base is low, the most places affected are the Windows only places in the three files tsrm_win32.c, zend_virtual_cwd.c and plain_wrapper.c. The actual implementation of the most of the wide char supporting functionality is in win32/ioutil.* and win32/codepage.*, several low level functionsare extended in place to avoid reimplementation for now. No performance impact was sighted. As previously mentioned, the ANSI APIs used prior the patch perform Unicode conversions internally. Using the Unicode APIs directly while doing custom conversions just retains the status quo. The ways to optimize it are open (fe. by implementing caching for the strings converted to wide variants). The long path implementation is user transparent. If a path exceeds the length of _MAX_PATH, it'll be automatically prefixed with \\?\. The MAXPATHLEN is set to 2048 bytes. Appreciation to Pierre Joye, Matt Ficken, @algo13 and others for tips, ideas and testing. Thanks.
2016-06-20 07:32:19 +00:00
#endif
CWD_STATE_FREE_ERR(&new_state);
return f;
}
2007-08-10 09:09:46 +00:00
/* }}} */
2014-12-13 22:06:14 +00:00
CWD_API int virtual_access(const char *pathname, int mode) /* {{{ */
2002-10-04 01:04:00 +00:00
{
cwd_state new_state;
int ret;
2010-09-10 14:02:19 +00:00
2002-10-04 01:04:00 +00:00
CWD_STATE_COPY(&new_state, &CWDG(cwd));
2014-12-13 22:06:14 +00:00
if (virtual_file_ex(&new_state, pathname, NULL, CWD_REALPATH)) {
CWD_STATE_FREE_ERR(&new_state);
2006-08-05 13:17:50 +00:00
return -1;
}
2002-10-04 01:04:00 +00:00
#if defined(ZEND_WIN32)
2014-12-13 22:06:14 +00:00
ret = tsrm_win32_access(new_state.cwd, mode);
#else
2002-10-04 01:04:00 +00:00
ret = access(new_state.cwd, mode);
#endif
2010-09-10 14:02:19 +00:00
CWD_STATE_FREE_ERR(&new_state);
2010-09-10 14:02:19 +00:00
2002-10-04 01:04:00 +00:00
return ret;
}
2007-08-10 09:09:46 +00:00
/* }}} */
2002-10-04 01:04:00 +00:00
2000-09-03 18:58:46 +00:00
#if HAVE_UTIME
2014-12-13 22:06:14 +00:00
CWD_API int virtual_utime(const char *filename, struct utimbuf *buf) /* {{{ */
{
cwd_state new_state;
int ret;
CWD_STATE_COPY(&new_state, &CWDG(cwd));
2014-12-13 22:06:14 +00:00
if (virtual_file_ex(&new_state, filename, NULL, CWD_REALPATH)) {
CWD_STATE_FREE_ERR(&new_state);
return -1;
}
#ifdef ZEND_WIN32
ret = win32_utime(new_state.cwd, buf);
#else
ret = utime(new_state.cwd, buf);
#endif
CWD_STATE_FREE_ERR(&new_state);
return ret;
}
2007-08-10 09:09:46 +00:00
/* }}} */
#endif
2014-12-13 22:06:14 +00:00
CWD_API int virtual_chmod(const char *filename, mode_t mode) /* {{{ */
{
cwd_state new_state;
int ret;
CWD_STATE_COPY(&new_state, &CWDG(cwd));
2014-12-13 22:06:14 +00:00
if (virtual_file_ex(&new_state, filename, NULL, CWD_REALPATH)) {
CWD_STATE_FREE_ERR(&new_state);
return -1;
}
2015-11-05 10:58:44 +00:00
#ifdef ZEND_WIN32
{
mode_t _tmp = mode;
mode = 0;
if (_tmp & _S_IREAD) {
mode |= _S_IREAD;
}
if (_tmp & _S_IWRITE) {
mode |= _S_IWRITE;
}
Fixed the UTF-8 and long path support in the streams on Windows. Since long the default PHP charset is UTF-8, however the Windows part is out of step with this important point. The current implementation in PHP doesn't technically permit to handle UTF-8 filepath and several other things. Till now, only the ANSI compatible APIs are being used. Here is more about it https://msdn.microsoft.com/en-us/library/windows/desktop/dd317752%28v=vs.85%29.aspx The patch fixes not only issues with multibyte filenames under incompatible codepages, but indirectly also issues with some other multibyte encodings like BIG5, Shift-JIS, etc. by providing a clean way to access filenames in UTF-8. Below is a small list of issues from the bug tracker, that are getting fixed: https://bugs.php.net/63401 https://bugs.php.net/41199 https://bugs.php.net/50203 https://bugs.php.net/71509 https://bugs.php.net/64699 https://bugs.php.net/64506 https://bugs.php.net/30195 https://bugs.php.net/65358 https://bugs.php.net/61315 https://bugs.php.net/70943 https://bugs.php.net/70903 https://bugs.php.net/63593 https://bugs.php.net/54977 https://bugs.php.net/54028 https://bugs.php.net/43148 https://bugs.php.net/30730 https://bugs.php.net/33350 https://bugs.php.net/35300 https://bugs.php.net/46990 https://bugs.php.net/61309 https://bugs.php.net/69333 https://bugs.php.net/45517 https://bugs.php.net/70551 https://bugs.php.net/50197 https://bugs.php.net/72200 https://bugs.php.net/37672 Yet more related tickets can for sure be found - on bugs.php.net, Stackoverflow and Github. Some of the bugs are pretty recent, some descend to early 2000th, but the user comments in there last even till today. Just for example, bug #30195 was opened in 2004, the latest comment in there was made in 2014. It is certain, that these bugs descend not only to pure PHP use cases, but get also redirected from the popular PHP based projects. Given the modern systems (and those supported by PHP) are always based on NTFS, there is no excuse to keep these issues unresolved. The internalization approach on Windows is in many ways different from UNIX and Linux, while it supports and is based on Unicode. It depends on the current system code page, APIs used and exact kind how the binary was compiled The locale doesn't affect the way Unicode or ANSI API work. PHP in particular is being compiled without _UNICODE defined and this is conditioned by the way we handle strings. Here is more about it https://msdn.microsoft.com/en-us/library/tsbaswba.aspx However, with any system code page ANSI functions automatically convert paths to UTF-16. Paths in some encodings incompatible with the current system code page, won't work correctly with ANSI APIs. PHP till now only uses the ANSI Windows APIs. For example, on a system with the current code page 1252, the paths in cp1252 are supported and transparently converted to UTF-16 by the ANSI functions. Once one wants to handle a filepath encoded with cp932 on that particular system, an ANSI or a POSIX compatible function used in PHP will produce an erroneous result. When trying to convert that cp932 path to UTF-8 and passing to the ANSI functions, an ANSI function would likely interpret the UTF-8 string as some string in the current code page and create a filepath that represents every single byte of the UTF-8 string. These behaviors are not only broken but also disregard the documented INI settings. This patch solves the issies with the multibyte paths on Windows by intelligently enforcing the usage of the Unicode aware APIs. For functions expect Unicode (fe CreateFileW, FindFirstFileW, etc.), arguments will be converted to UTF-16 wide chars. For functions returning Unicode aware data (fe GetCurrentDirectoryW, etc.), resulting wide string is converted back to char's depending on the current PHP charset settings, either to the current ANSI codepage (this is the behavior prior to this patch) or to UTF-8 (the default behavior). In a particular case, users might have to explicitly set internal_encoding or default_charset, if filenames in ANSI codepage are necessary. Current tests show no regressions and witness that this will be an exotic case, the current default UTF-8 encoding is compatible with any supported system. The dependency libraries are long switching to Unicode APIs, so some tests were also added for extensions not directly related to streams. At large, the patch brings over 150 related tests into the core. Those target and was run on various environments with European, Asian, etc. codepages. General PHP frameworks was tested and showed no regressions. The impact on the current C code base is low, the most places affected are the Windows only places in the three files tsrm_win32.c, zend_virtual_cwd.c and plain_wrapper.c. The actual implementation of the most of the wide char supporting functionality is in win32/ioutil.* and win32/codepage.*, several low level functionsare extended in place to avoid reimplementation for now. No performance impact was sighted. As previously mentioned, the ANSI APIs used prior the patch perform Unicode conversions internally. Using the Unicode APIs directly while doing custom conversions just retains the status quo. The ways to optimize it are open (fe. by implementing caching for the strings converted to wide variants). The long path implementation is user transparent. If a path exceeds the length of _MAX_PATH, it'll be automatically prefixed with \\?\. The MAXPATHLEN is set to 2048 bytes. Appreciation to Pierre Joye, Matt Ficken, @algo13 and others for tips, ideas and testing. Thanks.
2016-06-20 07:32:19 +00:00
ret = php_win32_ioutil_chmod(new_state.cwd, mode);
2015-11-05 10:58:44 +00:00
}
Fixed the UTF-8 and long path support in the streams on Windows. Since long the default PHP charset is UTF-8, however the Windows part is out of step with this important point. The current implementation in PHP doesn't technically permit to handle UTF-8 filepath and several other things. Till now, only the ANSI compatible APIs are being used. Here is more about it https://msdn.microsoft.com/en-us/library/windows/desktop/dd317752%28v=vs.85%29.aspx The patch fixes not only issues with multibyte filenames under incompatible codepages, but indirectly also issues with some other multibyte encodings like BIG5, Shift-JIS, etc. by providing a clean way to access filenames in UTF-8. Below is a small list of issues from the bug tracker, that are getting fixed: https://bugs.php.net/63401 https://bugs.php.net/41199 https://bugs.php.net/50203 https://bugs.php.net/71509 https://bugs.php.net/64699 https://bugs.php.net/64506 https://bugs.php.net/30195 https://bugs.php.net/65358 https://bugs.php.net/61315 https://bugs.php.net/70943 https://bugs.php.net/70903 https://bugs.php.net/63593 https://bugs.php.net/54977 https://bugs.php.net/54028 https://bugs.php.net/43148 https://bugs.php.net/30730 https://bugs.php.net/33350 https://bugs.php.net/35300 https://bugs.php.net/46990 https://bugs.php.net/61309 https://bugs.php.net/69333 https://bugs.php.net/45517 https://bugs.php.net/70551 https://bugs.php.net/50197 https://bugs.php.net/72200 https://bugs.php.net/37672 Yet more related tickets can for sure be found - on bugs.php.net, Stackoverflow and Github. Some of the bugs are pretty recent, some descend to early 2000th, but the user comments in there last even till today. Just for example, bug #30195 was opened in 2004, the latest comment in there was made in 2014. It is certain, that these bugs descend not only to pure PHP use cases, but get also redirected from the popular PHP based projects. Given the modern systems (and those supported by PHP) are always based on NTFS, there is no excuse to keep these issues unresolved. The internalization approach on Windows is in many ways different from UNIX and Linux, while it supports and is based on Unicode. It depends on the current system code page, APIs used and exact kind how the binary was compiled The locale doesn't affect the way Unicode or ANSI API work. PHP in particular is being compiled without _UNICODE defined and this is conditioned by the way we handle strings. Here is more about it https://msdn.microsoft.com/en-us/library/tsbaswba.aspx However, with any system code page ANSI functions automatically convert paths to UTF-16. Paths in some encodings incompatible with the current system code page, won't work correctly with ANSI APIs. PHP till now only uses the ANSI Windows APIs. For example, on a system with the current code page 1252, the paths in cp1252 are supported and transparently converted to UTF-16 by the ANSI functions. Once one wants to handle a filepath encoded with cp932 on that particular system, an ANSI or a POSIX compatible function used in PHP will produce an erroneous result. When trying to convert that cp932 path to UTF-8 and passing to the ANSI functions, an ANSI function would likely interpret the UTF-8 string as some string in the current code page and create a filepath that represents every single byte of the UTF-8 string. These behaviors are not only broken but also disregard the documented INI settings. This patch solves the issies with the multibyte paths on Windows by intelligently enforcing the usage of the Unicode aware APIs. For functions expect Unicode (fe CreateFileW, FindFirstFileW, etc.), arguments will be converted to UTF-16 wide chars. For functions returning Unicode aware data (fe GetCurrentDirectoryW, etc.), resulting wide string is converted back to char's depending on the current PHP charset settings, either to the current ANSI codepage (this is the behavior prior to this patch) or to UTF-8 (the default behavior). In a particular case, users might have to explicitly set internal_encoding or default_charset, if filenames in ANSI codepage are necessary. Current tests show no regressions and witness that this will be an exotic case, the current default UTF-8 encoding is compatible with any supported system. The dependency libraries are long switching to Unicode APIs, so some tests were also added for extensions not directly related to streams. At large, the patch brings over 150 related tests into the core. Those target and was run on various environments with European, Asian, etc. codepages. General PHP frameworks was tested and showed no regressions. The impact on the current C code base is low, the most places affected are the Windows only places in the three files tsrm_win32.c, zend_virtual_cwd.c and plain_wrapper.c. The actual implementation of the most of the wide char supporting functionality is in win32/ioutil.* and win32/codepage.*, several low level functionsare extended in place to avoid reimplementation for now. No performance impact was sighted. As previously mentioned, the ANSI APIs used prior the patch perform Unicode conversions internally. Using the Unicode APIs directly while doing custom conversions just retains the status quo. The ways to optimize it are open (fe. by implementing caching for the strings converted to wide variants). The long path implementation is user transparent. If a path exceeds the length of _MAX_PATH, it'll be automatically prefixed with \\?\. The MAXPATHLEN is set to 2048 bytes. Appreciation to Pierre Joye, Matt Ficken, @algo13 and others for tips, ideas and testing. Thanks.
2016-06-20 07:32:19 +00:00
#else
ret = chmod(new_state.cwd, mode);
Fixed the UTF-8 and long path support in the streams on Windows. Since long the default PHP charset is UTF-8, however the Windows part is out of step with this important point. The current implementation in PHP doesn't technically permit to handle UTF-8 filepath and several other things. Till now, only the ANSI compatible APIs are being used. Here is more about it https://msdn.microsoft.com/en-us/library/windows/desktop/dd317752%28v=vs.85%29.aspx The patch fixes not only issues with multibyte filenames under incompatible codepages, but indirectly also issues with some other multibyte encodings like BIG5, Shift-JIS, etc. by providing a clean way to access filenames in UTF-8. Below is a small list of issues from the bug tracker, that are getting fixed: https://bugs.php.net/63401 https://bugs.php.net/41199 https://bugs.php.net/50203 https://bugs.php.net/71509 https://bugs.php.net/64699 https://bugs.php.net/64506 https://bugs.php.net/30195 https://bugs.php.net/65358 https://bugs.php.net/61315 https://bugs.php.net/70943 https://bugs.php.net/70903 https://bugs.php.net/63593 https://bugs.php.net/54977 https://bugs.php.net/54028 https://bugs.php.net/43148 https://bugs.php.net/30730 https://bugs.php.net/33350 https://bugs.php.net/35300 https://bugs.php.net/46990 https://bugs.php.net/61309 https://bugs.php.net/69333 https://bugs.php.net/45517 https://bugs.php.net/70551 https://bugs.php.net/50197 https://bugs.php.net/72200 https://bugs.php.net/37672 Yet more related tickets can for sure be found - on bugs.php.net, Stackoverflow and Github. Some of the bugs are pretty recent, some descend to early 2000th, but the user comments in there last even till today. Just for example, bug #30195 was opened in 2004, the latest comment in there was made in 2014. It is certain, that these bugs descend not only to pure PHP use cases, but get also redirected from the popular PHP based projects. Given the modern systems (and those supported by PHP) are always based on NTFS, there is no excuse to keep these issues unresolved. The internalization approach on Windows is in many ways different from UNIX and Linux, while it supports and is based on Unicode. It depends on the current system code page, APIs used and exact kind how the binary was compiled The locale doesn't affect the way Unicode or ANSI API work. PHP in particular is being compiled without _UNICODE defined and this is conditioned by the way we handle strings. Here is more about it https://msdn.microsoft.com/en-us/library/tsbaswba.aspx However, with any system code page ANSI functions automatically convert paths to UTF-16. Paths in some encodings incompatible with the current system code page, won't work correctly with ANSI APIs. PHP till now only uses the ANSI Windows APIs. For example, on a system with the current code page 1252, the paths in cp1252 are supported and transparently converted to UTF-16 by the ANSI functions. Once one wants to handle a filepath encoded with cp932 on that particular system, an ANSI or a POSIX compatible function used in PHP will produce an erroneous result. When trying to convert that cp932 path to UTF-8 and passing to the ANSI functions, an ANSI function would likely interpret the UTF-8 string as some string in the current code page and create a filepath that represents every single byte of the UTF-8 string. These behaviors are not only broken but also disregard the documented INI settings. This patch solves the issies with the multibyte paths on Windows by intelligently enforcing the usage of the Unicode aware APIs. For functions expect Unicode (fe CreateFileW, FindFirstFileW, etc.), arguments will be converted to UTF-16 wide chars. For functions returning Unicode aware data (fe GetCurrentDirectoryW, etc.), resulting wide string is converted back to char's depending on the current PHP charset settings, either to the current ANSI codepage (this is the behavior prior to this patch) or to UTF-8 (the default behavior). In a particular case, users might have to explicitly set internal_encoding or default_charset, if filenames in ANSI codepage are necessary. Current tests show no regressions and witness that this will be an exotic case, the current default UTF-8 encoding is compatible with any supported system. The dependency libraries are long switching to Unicode APIs, so some tests were also added for extensions not directly related to streams. At large, the patch brings over 150 related tests into the core. Those target and was run on various environments with European, Asian, etc. codepages. General PHP frameworks was tested and showed no regressions. The impact on the current C code base is low, the most places affected are the Windows only places in the three files tsrm_win32.c, zend_virtual_cwd.c and plain_wrapper.c. The actual implementation of the most of the wide char supporting functionality is in win32/ioutil.* and win32/codepage.*, several low level functionsare extended in place to avoid reimplementation for now. No performance impact was sighted. As previously mentioned, the ANSI APIs used prior the patch perform Unicode conversions internally. Using the Unicode APIs directly while doing custom conversions just retains the status quo. The ways to optimize it are open (fe. by implementing caching for the strings converted to wide variants). The long path implementation is user transparent. If a path exceeds the length of _MAX_PATH, it'll be automatically prefixed with \\?\. The MAXPATHLEN is set to 2048 bytes. Appreciation to Pierre Joye, Matt Ficken, @algo13 and others for tips, ideas and testing. Thanks.
2016-06-20 07:32:19 +00:00
#endif
CWD_STATE_FREE_ERR(&new_state);
return ret;
}
2007-08-10 09:09:46 +00:00
/* }}} */
#if !defined(ZEND_WIN32)
2014-12-13 22:06:14 +00:00
CWD_API int virtual_chown(const char *filename, uid_t owner, gid_t group, int link) /* {{{ */
{
cwd_state new_state;
int ret;
CWD_STATE_COPY(&new_state, &CWDG(cwd));
2014-12-13 22:06:14 +00:00
if (virtual_file_ex(&new_state, filename, NULL, CWD_REALPATH)) {
CWD_STATE_FREE_ERR(&new_state);
return -1;
}
if (link) {
#if HAVE_LCHOWN
ret = lchown(new_state.cwd, owner, group);
#else
ret = -1;
#endif
} else {
ret = chown(new_state.cwd, owner, group);
}
CWD_STATE_FREE_ERR(&new_state);
return ret;
}
2007-08-10 09:09:46 +00:00
/* }}} */
#endif
2014-12-13 22:06:14 +00:00
CWD_API int virtual_open(const char *path, int flags, ...) /* {{{ */
{
cwd_state new_state;
int f;
CWD_STATE_COPY(&new_state, &CWDG(cwd));
2014-12-13 22:06:14 +00:00
if (virtual_file_ex(&new_state, path, NULL, CWD_FILEPATH)) {
CWD_STATE_FREE_ERR(&new_state);
return -1;
}
if (flags & O_CREAT) {
mode_t mode;
va_list arg;
va_start(arg, flags);
2001-11-17 21:15:38 +00:00
mode = (mode_t) va_arg(arg, int);
va_end(arg);
Fixed the UTF-8 and long path support in the streams on Windows. Since long the default PHP charset is UTF-8, however the Windows part is out of step with this important point. The current implementation in PHP doesn't technically permit to handle UTF-8 filepath and several other things. Till now, only the ANSI compatible APIs are being used. Here is more about it https://msdn.microsoft.com/en-us/library/windows/desktop/dd317752%28v=vs.85%29.aspx The patch fixes not only issues with multibyte filenames under incompatible codepages, but indirectly also issues with some other multibyte encodings like BIG5, Shift-JIS, etc. by providing a clean way to access filenames in UTF-8. Below is a small list of issues from the bug tracker, that are getting fixed: https://bugs.php.net/63401 https://bugs.php.net/41199 https://bugs.php.net/50203 https://bugs.php.net/71509 https://bugs.php.net/64699 https://bugs.php.net/64506 https://bugs.php.net/30195 https://bugs.php.net/65358 https://bugs.php.net/61315 https://bugs.php.net/70943 https://bugs.php.net/70903 https://bugs.php.net/63593 https://bugs.php.net/54977 https://bugs.php.net/54028 https://bugs.php.net/43148 https://bugs.php.net/30730 https://bugs.php.net/33350 https://bugs.php.net/35300 https://bugs.php.net/46990 https://bugs.php.net/61309 https://bugs.php.net/69333 https://bugs.php.net/45517 https://bugs.php.net/70551 https://bugs.php.net/50197 https://bugs.php.net/72200 https://bugs.php.net/37672 Yet more related tickets can for sure be found - on bugs.php.net, Stackoverflow and Github. Some of the bugs are pretty recent, some descend to early 2000th, but the user comments in there last even till today. Just for example, bug #30195 was opened in 2004, the latest comment in there was made in 2014. It is certain, that these bugs descend not only to pure PHP use cases, but get also redirected from the popular PHP based projects. Given the modern systems (and those supported by PHP) are always based on NTFS, there is no excuse to keep these issues unresolved. The internalization approach on Windows is in many ways different from UNIX and Linux, while it supports and is based on Unicode. It depends on the current system code page, APIs used and exact kind how the binary was compiled The locale doesn't affect the way Unicode or ANSI API work. PHP in particular is being compiled without _UNICODE defined and this is conditioned by the way we handle strings. Here is more about it https://msdn.microsoft.com/en-us/library/tsbaswba.aspx However, with any system code page ANSI functions automatically convert paths to UTF-16. Paths in some encodings incompatible with the current system code page, won't work correctly with ANSI APIs. PHP till now only uses the ANSI Windows APIs. For example, on a system with the current code page 1252, the paths in cp1252 are supported and transparently converted to UTF-16 by the ANSI functions. Once one wants to handle a filepath encoded with cp932 on that particular system, an ANSI or a POSIX compatible function used in PHP will produce an erroneous result. When trying to convert that cp932 path to UTF-8 and passing to the ANSI functions, an ANSI function would likely interpret the UTF-8 string as some string in the current code page and create a filepath that represents every single byte of the UTF-8 string. These behaviors are not only broken but also disregard the documented INI settings. This patch solves the issies with the multibyte paths on Windows by intelligently enforcing the usage of the Unicode aware APIs. For functions expect Unicode (fe CreateFileW, FindFirstFileW, etc.), arguments will be converted to UTF-16 wide chars. For functions returning Unicode aware data (fe GetCurrentDirectoryW, etc.), resulting wide string is converted back to char's depending on the current PHP charset settings, either to the current ANSI codepage (this is the behavior prior to this patch) or to UTF-8 (the default behavior). In a particular case, users might have to explicitly set internal_encoding or default_charset, if filenames in ANSI codepage are necessary. Current tests show no regressions and witness that this will be an exotic case, the current default UTF-8 encoding is compatible with any supported system. The dependency libraries are long switching to Unicode APIs, so some tests were also added for extensions not directly related to streams. At large, the patch brings over 150 related tests into the core. Those target and was run on various environments with European, Asian, etc. codepages. General PHP frameworks was tested and showed no regressions. The impact on the current C code base is low, the most places affected are the Windows only places in the three files tsrm_win32.c, zend_virtual_cwd.c and plain_wrapper.c. The actual implementation of the most of the wide char supporting functionality is in win32/ioutil.* and win32/codepage.*, several low level functionsare extended in place to avoid reimplementation for now. No performance impact was sighted. As previously mentioned, the ANSI APIs used prior the patch perform Unicode conversions internally. Using the Unicode APIs directly while doing custom conversions just retains the status quo. The ways to optimize it are open (fe. by implementing caching for the strings converted to wide variants). The long path implementation is user transparent. If a path exceeds the length of _MAX_PATH, it'll be automatically prefixed with \\?\. The MAXPATHLEN is set to 2048 bytes. Appreciation to Pierre Joye, Matt Ficken, @algo13 and others for tips, ideas and testing. Thanks.
2016-06-20 07:32:19 +00:00
#ifdef ZEND_WIN32
f = php_win32_ioutil_open(new_state.cwd, flags, mode);
#else
f = open(new_state.cwd, flags, mode);
Fixed the UTF-8 and long path support in the streams on Windows. Since long the default PHP charset is UTF-8, however the Windows part is out of step with this important point. The current implementation in PHP doesn't technically permit to handle UTF-8 filepath and several other things. Till now, only the ANSI compatible APIs are being used. Here is more about it https://msdn.microsoft.com/en-us/library/windows/desktop/dd317752%28v=vs.85%29.aspx The patch fixes not only issues with multibyte filenames under incompatible codepages, but indirectly also issues with some other multibyte encodings like BIG5, Shift-JIS, etc. by providing a clean way to access filenames in UTF-8. Below is a small list of issues from the bug tracker, that are getting fixed: https://bugs.php.net/63401 https://bugs.php.net/41199 https://bugs.php.net/50203 https://bugs.php.net/71509 https://bugs.php.net/64699 https://bugs.php.net/64506 https://bugs.php.net/30195 https://bugs.php.net/65358 https://bugs.php.net/61315 https://bugs.php.net/70943 https://bugs.php.net/70903 https://bugs.php.net/63593 https://bugs.php.net/54977 https://bugs.php.net/54028 https://bugs.php.net/43148 https://bugs.php.net/30730 https://bugs.php.net/33350 https://bugs.php.net/35300 https://bugs.php.net/46990 https://bugs.php.net/61309 https://bugs.php.net/69333 https://bugs.php.net/45517 https://bugs.php.net/70551 https://bugs.php.net/50197 https://bugs.php.net/72200 https://bugs.php.net/37672 Yet more related tickets can for sure be found - on bugs.php.net, Stackoverflow and Github. Some of the bugs are pretty recent, some descend to early 2000th, but the user comments in there last even till today. Just for example, bug #30195 was opened in 2004, the latest comment in there was made in 2014. It is certain, that these bugs descend not only to pure PHP use cases, but get also redirected from the popular PHP based projects. Given the modern systems (and those supported by PHP) are always based on NTFS, there is no excuse to keep these issues unresolved. The internalization approach on Windows is in many ways different from UNIX and Linux, while it supports and is based on Unicode. It depends on the current system code page, APIs used and exact kind how the binary was compiled The locale doesn't affect the way Unicode or ANSI API work. PHP in particular is being compiled without _UNICODE defined and this is conditioned by the way we handle strings. Here is more about it https://msdn.microsoft.com/en-us/library/tsbaswba.aspx However, with any system code page ANSI functions automatically convert paths to UTF-16. Paths in some encodings incompatible with the current system code page, won't work correctly with ANSI APIs. PHP till now only uses the ANSI Windows APIs. For example, on a system with the current code page 1252, the paths in cp1252 are supported and transparently converted to UTF-16 by the ANSI functions. Once one wants to handle a filepath encoded with cp932 on that particular system, an ANSI or a POSIX compatible function used in PHP will produce an erroneous result. When trying to convert that cp932 path to UTF-8 and passing to the ANSI functions, an ANSI function would likely interpret the UTF-8 string as some string in the current code page and create a filepath that represents every single byte of the UTF-8 string. These behaviors are not only broken but also disregard the documented INI settings. This patch solves the issies with the multibyte paths on Windows by intelligently enforcing the usage of the Unicode aware APIs. For functions expect Unicode (fe CreateFileW, FindFirstFileW, etc.), arguments will be converted to UTF-16 wide chars. For functions returning Unicode aware data (fe GetCurrentDirectoryW, etc.), resulting wide string is converted back to char's depending on the current PHP charset settings, either to the current ANSI codepage (this is the behavior prior to this patch) or to UTF-8 (the default behavior). In a particular case, users might have to explicitly set internal_encoding or default_charset, if filenames in ANSI codepage are necessary. Current tests show no regressions and witness that this will be an exotic case, the current default UTF-8 encoding is compatible with any supported system. The dependency libraries are long switching to Unicode APIs, so some tests were also added for extensions not directly related to streams. At large, the patch brings over 150 related tests into the core. Those target and was run on various environments with European, Asian, etc. codepages. General PHP frameworks was tested and showed no regressions. The impact on the current C code base is low, the most places affected are the Windows only places in the three files tsrm_win32.c, zend_virtual_cwd.c and plain_wrapper.c. The actual implementation of the most of the wide char supporting functionality is in win32/ioutil.* and win32/codepage.*, several low level functionsare extended in place to avoid reimplementation for now. No performance impact was sighted. As previously mentioned, the ANSI APIs used prior the patch perform Unicode conversions internally. Using the Unicode APIs directly while doing custom conversions just retains the status quo. The ways to optimize it are open (fe. by implementing caching for the strings converted to wide variants). The long path implementation is user transparent. If a path exceeds the length of _MAX_PATH, it'll be automatically prefixed with \\?\. The MAXPATHLEN is set to 2048 bytes. Appreciation to Pierre Joye, Matt Ficken, @algo13 and others for tips, ideas and testing. Thanks.
2016-06-20 07:32:19 +00:00
#endif
} else {
Fixed the UTF-8 and long path support in the streams on Windows. Since long the default PHP charset is UTF-8, however the Windows part is out of step with this important point. The current implementation in PHP doesn't technically permit to handle UTF-8 filepath and several other things. Till now, only the ANSI compatible APIs are being used. Here is more about it https://msdn.microsoft.com/en-us/library/windows/desktop/dd317752%28v=vs.85%29.aspx The patch fixes not only issues with multibyte filenames under incompatible codepages, but indirectly also issues with some other multibyte encodings like BIG5, Shift-JIS, etc. by providing a clean way to access filenames in UTF-8. Below is a small list of issues from the bug tracker, that are getting fixed: https://bugs.php.net/63401 https://bugs.php.net/41199 https://bugs.php.net/50203 https://bugs.php.net/71509 https://bugs.php.net/64699 https://bugs.php.net/64506 https://bugs.php.net/30195 https://bugs.php.net/65358 https://bugs.php.net/61315 https://bugs.php.net/70943 https://bugs.php.net/70903 https://bugs.php.net/63593 https://bugs.php.net/54977 https://bugs.php.net/54028 https://bugs.php.net/43148 https://bugs.php.net/30730 https://bugs.php.net/33350 https://bugs.php.net/35300 https://bugs.php.net/46990 https://bugs.php.net/61309 https://bugs.php.net/69333 https://bugs.php.net/45517 https://bugs.php.net/70551 https://bugs.php.net/50197 https://bugs.php.net/72200 https://bugs.php.net/37672 Yet more related tickets can for sure be found - on bugs.php.net, Stackoverflow and Github. Some of the bugs are pretty recent, some descend to early 2000th, but the user comments in there last even till today. Just for example, bug #30195 was opened in 2004, the latest comment in there was made in 2014. It is certain, that these bugs descend not only to pure PHP use cases, but get also redirected from the popular PHP based projects. Given the modern systems (and those supported by PHP) are always based on NTFS, there is no excuse to keep these issues unresolved. The internalization approach on Windows is in many ways different from UNIX and Linux, while it supports and is based on Unicode. It depends on the current system code page, APIs used and exact kind how the binary was compiled The locale doesn't affect the way Unicode or ANSI API work. PHP in particular is being compiled without _UNICODE defined and this is conditioned by the way we handle strings. Here is more about it https://msdn.microsoft.com/en-us/library/tsbaswba.aspx However, with any system code page ANSI functions automatically convert paths to UTF-16. Paths in some encodings incompatible with the current system code page, won't work correctly with ANSI APIs. PHP till now only uses the ANSI Windows APIs. For example, on a system with the current code page 1252, the paths in cp1252 are supported and transparently converted to UTF-16 by the ANSI functions. Once one wants to handle a filepath encoded with cp932 on that particular system, an ANSI or a POSIX compatible function used in PHP will produce an erroneous result. When trying to convert that cp932 path to UTF-8 and passing to the ANSI functions, an ANSI function would likely interpret the UTF-8 string as some string in the current code page and create a filepath that represents every single byte of the UTF-8 string. These behaviors are not only broken but also disregard the documented INI settings. This patch solves the issies with the multibyte paths on Windows by intelligently enforcing the usage of the Unicode aware APIs. For functions expect Unicode (fe CreateFileW, FindFirstFileW, etc.), arguments will be converted to UTF-16 wide chars. For functions returning Unicode aware data (fe GetCurrentDirectoryW, etc.), resulting wide string is converted back to char's depending on the current PHP charset settings, either to the current ANSI codepage (this is the behavior prior to this patch) or to UTF-8 (the default behavior). In a particular case, users might have to explicitly set internal_encoding or default_charset, if filenames in ANSI codepage are necessary. Current tests show no regressions and witness that this will be an exotic case, the current default UTF-8 encoding is compatible with any supported system. The dependency libraries are long switching to Unicode APIs, so some tests were also added for extensions not directly related to streams. At large, the patch brings over 150 related tests into the core. Those target and was run on various environments with European, Asian, etc. codepages. General PHP frameworks was tested and showed no regressions. The impact on the current C code base is low, the most places affected are the Windows only places in the three files tsrm_win32.c, zend_virtual_cwd.c and plain_wrapper.c. The actual implementation of the most of the wide char supporting functionality is in win32/ioutil.* and win32/codepage.*, several low level functionsare extended in place to avoid reimplementation for now. No performance impact was sighted. As previously mentioned, the ANSI APIs used prior the patch perform Unicode conversions internally. Using the Unicode APIs directly while doing custom conversions just retains the status quo. The ways to optimize it are open (fe. by implementing caching for the strings converted to wide variants). The long path implementation is user transparent. If a path exceeds the length of _MAX_PATH, it'll be automatically prefixed with \\?\. The MAXPATHLEN is set to 2048 bytes. Appreciation to Pierre Joye, Matt Ficken, @algo13 and others for tips, ideas and testing. Thanks.
2016-06-20 07:32:19 +00:00
#ifdef ZEND_WIN32
f = php_win32_ioutil_open(new_state.cwd, flags);
#else
f = open(new_state.cwd, flags);
Fixed the UTF-8 and long path support in the streams on Windows. Since long the default PHP charset is UTF-8, however the Windows part is out of step with this important point. The current implementation in PHP doesn't technically permit to handle UTF-8 filepath and several other things. Till now, only the ANSI compatible APIs are being used. Here is more about it https://msdn.microsoft.com/en-us/library/windows/desktop/dd317752%28v=vs.85%29.aspx The patch fixes not only issues with multibyte filenames under incompatible codepages, but indirectly also issues with some other multibyte encodings like BIG5, Shift-JIS, etc. by providing a clean way to access filenames in UTF-8. Below is a small list of issues from the bug tracker, that are getting fixed: https://bugs.php.net/63401 https://bugs.php.net/41199 https://bugs.php.net/50203 https://bugs.php.net/71509 https://bugs.php.net/64699 https://bugs.php.net/64506 https://bugs.php.net/30195 https://bugs.php.net/65358 https://bugs.php.net/61315 https://bugs.php.net/70943 https://bugs.php.net/70903 https://bugs.php.net/63593 https://bugs.php.net/54977 https://bugs.php.net/54028 https://bugs.php.net/43148 https://bugs.php.net/30730 https://bugs.php.net/33350 https://bugs.php.net/35300 https://bugs.php.net/46990 https://bugs.php.net/61309 https://bugs.php.net/69333 https://bugs.php.net/45517 https://bugs.php.net/70551 https://bugs.php.net/50197 https://bugs.php.net/72200 https://bugs.php.net/37672 Yet more related tickets can for sure be found - on bugs.php.net, Stackoverflow and Github. Some of the bugs are pretty recent, some descend to early 2000th, but the user comments in there last even till today. Just for example, bug #30195 was opened in 2004, the latest comment in there was made in 2014. It is certain, that these bugs descend not only to pure PHP use cases, but get also redirected from the popular PHP based projects. Given the modern systems (and those supported by PHP) are always based on NTFS, there is no excuse to keep these issues unresolved. The internalization approach on Windows is in many ways different from UNIX and Linux, while it supports and is based on Unicode. It depends on the current system code page, APIs used and exact kind how the binary was compiled The locale doesn't affect the way Unicode or ANSI API work. PHP in particular is being compiled without _UNICODE defined and this is conditioned by the way we handle strings. Here is more about it https://msdn.microsoft.com/en-us/library/tsbaswba.aspx However, with any system code page ANSI functions automatically convert paths to UTF-16. Paths in some encodings incompatible with the current system code page, won't work correctly with ANSI APIs. PHP till now only uses the ANSI Windows APIs. For example, on a system with the current code page 1252, the paths in cp1252 are supported and transparently converted to UTF-16 by the ANSI functions. Once one wants to handle a filepath encoded with cp932 on that particular system, an ANSI or a POSIX compatible function used in PHP will produce an erroneous result. When trying to convert that cp932 path to UTF-8 and passing to the ANSI functions, an ANSI function would likely interpret the UTF-8 string as some string in the current code page and create a filepath that represents every single byte of the UTF-8 string. These behaviors are not only broken but also disregard the documented INI settings. This patch solves the issies with the multibyte paths on Windows by intelligently enforcing the usage of the Unicode aware APIs. For functions expect Unicode (fe CreateFileW, FindFirstFileW, etc.), arguments will be converted to UTF-16 wide chars. For functions returning Unicode aware data (fe GetCurrentDirectoryW, etc.), resulting wide string is converted back to char's depending on the current PHP charset settings, either to the current ANSI codepage (this is the behavior prior to this patch) or to UTF-8 (the default behavior). In a particular case, users might have to explicitly set internal_encoding or default_charset, if filenames in ANSI codepage are necessary. Current tests show no regressions and witness that this will be an exotic case, the current default UTF-8 encoding is compatible with any supported system. The dependency libraries are long switching to Unicode APIs, so some tests were also added for extensions not directly related to streams. At large, the patch brings over 150 related tests into the core. Those target and was run on various environments with European, Asian, etc. codepages. General PHP frameworks was tested and showed no regressions. The impact on the current C code base is low, the most places affected are the Windows only places in the three files tsrm_win32.c, zend_virtual_cwd.c and plain_wrapper.c. The actual implementation of the most of the wide char supporting functionality is in win32/ioutil.* and win32/codepage.*, several low level functionsare extended in place to avoid reimplementation for now. No performance impact was sighted. As previously mentioned, the ANSI APIs used prior the patch perform Unicode conversions internally. Using the Unicode APIs directly while doing custom conversions just retains the status quo. The ways to optimize it are open (fe. by implementing caching for the strings converted to wide variants). The long path implementation is user transparent. If a path exceeds the length of _MAX_PATH, it'll be automatically prefixed with \\?\. The MAXPATHLEN is set to 2048 bytes. Appreciation to Pierre Joye, Matt Ficken, @algo13 and others for tips, ideas and testing. Thanks.
2016-06-20 07:32:19 +00:00
#endif
2010-09-10 14:02:19 +00:00
}
CWD_STATE_FREE_ERR(&new_state);
return f;
}
2007-08-10 09:09:46 +00:00
/* }}} */
2014-12-13 22:06:14 +00:00
CWD_API int virtual_creat(const char *path, mode_t mode) /* {{{ */
{
cwd_state new_state;
int f;
CWD_STATE_COPY(&new_state, &CWDG(cwd));
2014-12-13 22:06:14 +00:00
if (virtual_file_ex(&new_state, path, NULL, CWD_FILEPATH)) {
CWD_STATE_FREE_ERR(&new_state);
return -1;
}
f = creat(new_state.cwd, mode);
CWD_STATE_FREE_ERR(&new_state);
return f;
}
2007-08-10 09:09:46 +00:00
/* }}} */
2014-12-13 22:06:14 +00:00
CWD_API int virtual_rename(const char *oldname, const char *newname) /* {{{ */
{
cwd_state old_state;
cwd_state new_state;
int retval;
CWD_STATE_COPY(&old_state, &CWDG(cwd));
2014-12-13 22:06:14 +00:00
if (virtual_file_ex(&old_state, oldname, NULL, CWD_EXPAND)) {
CWD_STATE_FREE_ERR(&old_state);
return -1;
}
oldname = old_state.cwd;
CWD_STATE_COPY(&new_state, &CWDG(cwd));
2014-12-13 22:06:14 +00:00
if (virtual_file_ex(&new_state, newname, NULL, CWD_EXPAND)) {
CWD_STATE_FREE_ERR(&old_state);
CWD_STATE_FREE_ERR(&new_state);
return -1;
}
newname = new_state.cwd;
/* rename on windows will fail if newname already exists.
MoveFileEx has to be used */
#ifdef ZEND_WIN32
/* MoveFileEx returns 0 on failure, other way 'round for this function */
Fixed the UTF-8 and long path support in the streams on Windows. Since long the default PHP charset is UTF-8, however the Windows part is out of step with this important point. The current implementation in PHP doesn't technically permit to handle UTF-8 filepath and several other things. Till now, only the ANSI compatible APIs are being used. Here is more about it https://msdn.microsoft.com/en-us/library/windows/desktop/dd317752%28v=vs.85%29.aspx The patch fixes not only issues with multibyte filenames under incompatible codepages, but indirectly also issues with some other multibyte encodings like BIG5, Shift-JIS, etc. by providing a clean way to access filenames in UTF-8. Below is a small list of issues from the bug tracker, that are getting fixed: https://bugs.php.net/63401 https://bugs.php.net/41199 https://bugs.php.net/50203 https://bugs.php.net/71509 https://bugs.php.net/64699 https://bugs.php.net/64506 https://bugs.php.net/30195 https://bugs.php.net/65358 https://bugs.php.net/61315 https://bugs.php.net/70943 https://bugs.php.net/70903 https://bugs.php.net/63593 https://bugs.php.net/54977 https://bugs.php.net/54028 https://bugs.php.net/43148 https://bugs.php.net/30730 https://bugs.php.net/33350 https://bugs.php.net/35300 https://bugs.php.net/46990 https://bugs.php.net/61309 https://bugs.php.net/69333 https://bugs.php.net/45517 https://bugs.php.net/70551 https://bugs.php.net/50197 https://bugs.php.net/72200 https://bugs.php.net/37672 Yet more related tickets can for sure be found - on bugs.php.net, Stackoverflow and Github. Some of the bugs are pretty recent, some descend to early 2000th, but the user comments in there last even till today. Just for example, bug #30195 was opened in 2004, the latest comment in there was made in 2014. It is certain, that these bugs descend not only to pure PHP use cases, but get also redirected from the popular PHP based projects. Given the modern systems (and those supported by PHP) are always based on NTFS, there is no excuse to keep these issues unresolved. The internalization approach on Windows is in many ways different from UNIX and Linux, while it supports and is based on Unicode. It depends on the current system code page, APIs used and exact kind how the binary was compiled The locale doesn't affect the way Unicode or ANSI API work. PHP in particular is being compiled without _UNICODE defined and this is conditioned by the way we handle strings. Here is more about it https://msdn.microsoft.com/en-us/library/tsbaswba.aspx However, with any system code page ANSI functions automatically convert paths to UTF-16. Paths in some encodings incompatible with the current system code page, won't work correctly with ANSI APIs. PHP till now only uses the ANSI Windows APIs. For example, on a system with the current code page 1252, the paths in cp1252 are supported and transparently converted to UTF-16 by the ANSI functions. Once one wants to handle a filepath encoded with cp932 on that particular system, an ANSI or a POSIX compatible function used in PHP will produce an erroneous result. When trying to convert that cp932 path to UTF-8 and passing to the ANSI functions, an ANSI function would likely interpret the UTF-8 string as some string in the current code page and create a filepath that represents every single byte of the UTF-8 string. These behaviors are not only broken but also disregard the documented INI settings. This patch solves the issies with the multibyte paths on Windows by intelligently enforcing the usage of the Unicode aware APIs. For functions expect Unicode (fe CreateFileW, FindFirstFileW, etc.), arguments will be converted to UTF-16 wide chars. For functions returning Unicode aware data (fe GetCurrentDirectoryW, etc.), resulting wide string is converted back to char's depending on the current PHP charset settings, either to the current ANSI codepage (this is the behavior prior to this patch) or to UTF-8 (the default behavior). In a particular case, users might have to explicitly set internal_encoding or default_charset, if filenames in ANSI codepage are necessary. Current tests show no regressions and witness that this will be an exotic case, the current default UTF-8 encoding is compatible with any supported system. The dependency libraries are long switching to Unicode APIs, so some tests were also added for extensions not directly related to streams. At large, the patch brings over 150 related tests into the core. Those target and was run on various environments with European, Asian, etc. codepages. General PHP frameworks was tested and showed no regressions. The impact on the current C code base is low, the most places affected are the Windows only places in the three files tsrm_win32.c, zend_virtual_cwd.c and plain_wrapper.c. The actual implementation of the most of the wide char supporting functionality is in win32/ioutil.* and win32/codepage.*, several low level functionsare extended in place to avoid reimplementation for now. No performance impact was sighted. As previously mentioned, the ANSI APIs used prior the patch perform Unicode conversions internally. Using the Unicode APIs directly while doing custom conversions just retains the status quo. The ways to optimize it are open (fe. by implementing caching for the strings converted to wide variants). The long path implementation is user transparent. If a path exceeds the length of _MAX_PATH, it'll be automatically prefixed with \\?\. The MAXPATHLEN is set to 2048 bytes. Appreciation to Pierre Joye, Matt Ficken, @algo13 and others for tips, ideas and testing. Thanks.
2016-06-20 07:32:19 +00:00
retval = php_win32_ioutil_rename(oldname, newname);
#else
retval = rename(oldname, newname);
#endif
CWD_STATE_FREE_ERR(&old_state);
CWD_STATE_FREE_ERR(&new_state);
return retval;
}
2007-08-10 09:09:46 +00:00
/* }}} */
2014-12-13 22:06:14 +00:00
CWD_API int virtual_stat(const char *path, zend_stat_t *buf) /* {{{ */
{
cwd_state new_state;
int retval;
CWD_STATE_COPY(&new_state, &CWDG(cwd));
2014-12-13 22:06:14 +00:00
if (virtual_file_ex(&new_state, path, NULL, CWD_REALPATH)) {
CWD_STATE_FREE_ERR(&new_state);
return -1;
}
retval = php_sys_stat(new_state.cwd, buf);
CWD_STATE_FREE_ERR(&new_state);
return retval;
}
2007-08-10 09:09:46 +00:00
/* }}} */
2014-12-13 22:06:14 +00:00
CWD_API int virtual_lstat(const char *path, zend_stat_t *buf) /* {{{ */
{
2002-11-04 23:24:15 +00:00
cwd_state new_state;
int retval;
2002-11-04 23:24:15 +00:00
CWD_STATE_COPY(&new_state, &CWDG(cwd));
2014-12-13 22:06:14 +00:00
if (virtual_file_ex(&new_state, path, NULL, CWD_EXPAND)) {
CWD_STATE_FREE_ERR(&new_state);
return -1;
}
2002-11-04 23:24:15 +00:00
2010-09-01 09:49:53 +00:00
retval = php_sys_lstat(new_state.cwd, buf);
CWD_STATE_FREE_ERR(&new_state);
return retval;
}
2007-08-10 09:09:46 +00:00
/* }}} */
2014-12-13 22:06:14 +00:00
CWD_API int virtual_unlink(const char *path) /* {{{ */
{
2002-11-04 23:24:15 +00:00
cwd_state new_state;
int retval;
2002-11-04 23:24:15 +00:00
CWD_STATE_COPY(&new_state, &CWDG(cwd));
2014-12-13 22:06:14 +00:00
if (virtual_file_ex(&new_state, path, NULL, CWD_EXPAND)) {
CWD_STATE_FREE_ERR(&new_state);
return -1;
}
Fixed the UTF-8 and long path support in the streams on Windows. Since long the default PHP charset is UTF-8, however the Windows part is out of step with this important point. The current implementation in PHP doesn't technically permit to handle UTF-8 filepath and several other things. Till now, only the ANSI compatible APIs are being used. Here is more about it https://msdn.microsoft.com/en-us/library/windows/desktop/dd317752%28v=vs.85%29.aspx The patch fixes not only issues with multibyte filenames under incompatible codepages, but indirectly also issues with some other multibyte encodings like BIG5, Shift-JIS, etc. by providing a clean way to access filenames in UTF-8. Below is a small list of issues from the bug tracker, that are getting fixed: https://bugs.php.net/63401 https://bugs.php.net/41199 https://bugs.php.net/50203 https://bugs.php.net/71509 https://bugs.php.net/64699 https://bugs.php.net/64506 https://bugs.php.net/30195 https://bugs.php.net/65358 https://bugs.php.net/61315 https://bugs.php.net/70943 https://bugs.php.net/70903 https://bugs.php.net/63593 https://bugs.php.net/54977 https://bugs.php.net/54028 https://bugs.php.net/43148 https://bugs.php.net/30730 https://bugs.php.net/33350 https://bugs.php.net/35300 https://bugs.php.net/46990 https://bugs.php.net/61309 https://bugs.php.net/69333 https://bugs.php.net/45517 https://bugs.php.net/70551 https://bugs.php.net/50197 https://bugs.php.net/72200 https://bugs.php.net/37672 Yet more related tickets can for sure be found - on bugs.php.net, Stackoverflow and Github. Some of the bugs are pretty recent, some descend to early 2000th, but the user comments in there last even till today. Just for example, bug #30195 was opened in 2004, the latest comment in there was made in 2014. It is certain, that these bugs descend not only to pure PHP use cases, but get also redirected from the popular PHP based projects. Given the modern systems (and those supported by PHP) are always based on NTFS, there is no excuse to keep these issues unresolved. The internalization approach on Windows is in many ways different from UNIX and Linux, while it supports and is based on Unicode. It depends on the current system code page, APIs used and exact kind how the binary was compiled The locale doesn't affect the way Unicode or ANSI API work. PHP in particular is being compiled without _UNICODE defined and this is conditioned by the way we handle strings. Here is more about it https://msdn.microsoft.com/en-us/library/tsbaswba.aspx However, with any system code page ANSI functions automatically convert paths to UTF-16. Paths in some encodings incompatible with the current system code page, won't work correctly with ANSI APIs. PHP till now only uses the ANSI Windows APIs. For example, on a system with the current code page 1252, the paths in cp1252 are supported and transparently converted to UTF-16 by the ANSI functions. Once one wants to handle a filepath encoded with cp932 on that particular system, an ANSI or a POSIX compatible function used in PHP will produce an erroneous result. When trying to convert that cp932 path to UTF-8 and passing to the ANSI functions, an ANSI function would likely interpret the UTF-8 string as some string in the current code page and create a filepath that represents every single byte of the UTF-8 string. These behaviors are not only broken but also disregard the documented INI settings. This patch solves the issies with the multibyte paths on Windows by intelligently enforcing the usage of the Unicode aware APIs. For functions expect Unicode (fe CreateFileW, FindFirstFileW, etc.), arguments will be converted to UTF-16 wide chars. For functions returning Unicode aware data (fe GetCurrentDirectoryW, etc.), resulting wide string is converted back to char's depending on the current PHP charset settings, either to the current ANSI codepage (this is the behavior prior to this patch) or to UTF-8 (the default behavior). In a particular case, users might have to explicitly set internal_encoding or default_charset, if filenames in ANSI codepage are necessary. Current tests show no regressions and witness that this will be an exotic case, the current default UTF-8 encoding is compatible with any supported system. The dependency libraries are long switching to Unicode APIs, so some tests were also added for extensions not directly related to streams. At large, the patch brings over 150 related tests into the core. Those target and was run on various environments with European, Asian, etc. codepages. General PHP frameworks was tested and showed no regressions. The impact on the current C code base is low, the most places affected are the Windows only places in the three files tsrm_win32.c, zend_virtual_cwd.c and plain_wrapper.c. The actual implementation of the most of the wide char supporting functionality is in win32/ioutil.* and win32/codepage.*, several low level functionsare extended in place to avoid reimplementation for now. No performance impact was sighted. As previously mentioned, the ANSI APIs used prior the patch perform Unicode conversions internally. Using the Unicode APIs directly while doing custom conversions just retains the status quo. The ways to optimize it are open (fe. by implementing caching for the strings converted to wide variants). The long path implementation is user transparent. If a path exceeds the length of _MAX_PATH, it'll be automatically prefixed with \\?\. The MAXPATHLEN is set to 2048 bytes. Appreciation to Pierre Joye, Matt Ficken, @algo13 and others for tips, ideas and testing. Thanks.
2016-06-20 07:32:19 +00:00
#ifdef ZEND_WIN32
retval = php_win32_ioutil_unlink(new_state.cwd);
#else
2002-11-04 23:24:15 +00:00
retval = unlink(new_state.cwd);
Fixed the UTF-8 and long path support in the streams on Windows. Since long the default PHP charset is UTF-8, however the Windows part is out of step with this important point. The current implementation in PHP doesn't technically permit to handle UTF-8 filepath and several other things. Till now, only the ANSI compatible APIs are being used. Here is more about it https://msdn.microsoft.com/en-us/library/windows/desktop/dd317752%28v=vs.85%29.aspx The patch fixes not only issues with multibyte filenames under incompatible codepages, but indirectly also issues with some other multibyte encodings like BIG5, Shift-JIS, etc. by providing a clean way to access filenames in UTF-8. Below is a small list of issues from the bug tracker, that are getting fixed: https://bugs.php.net/63401 https://bugs.php.net/41199 https://bugs.php.net/50203 https://bugs.php.net/71509 https://bugs.php.net/64699 https://bugs.php.net/64506 https://bugs.php.net/30195 https://bugs.php.net/65358 https://bugs.php.net/61315 https://bugs.php.net/70943 https://bugs.php.net/70903 https://bugs.php.net/63593 https://bugs.php.net/54977 https://bugs.php.net/54028 https://bugs.php.net/43148 https://bugs.php.net/30730 https://bugs.php.net/33350 https://bugs.php.net/35300 https://bugs.php.net/46990 https://bugs.php.net/61309 https://bugs.php.net/69333 https://bugs.php.net/45517 https://bugs.php.net/70551 https://bugs.php.net/50197 https://bugs.php.net/72200 https://bugs.php.net/37672 Yet more related tickets can for sure be found - on bugs.php.net, Stackoverflow and Github. Some of the bugs are pretty recent, some descend to early 2000th, but the user comments in there last even till today. Just for example, bug #30195 was opened in 2004, the latest comment in there was made in 2014. It is certain, that these bugs descend not only to pure PHP use cases, but get also redirected from the popular PHP based projects. Given the modern systems (and those supported by PHP) are always based on NTFS, there is no excuse to keep these issues unresolved. The internalization approach on Windows is in many ways different from UNIX and Linux, while it supports and is based on Unicode. It depends on the current system code page, APIs used and exact kind how the binary was compiled The locale doesn't affect the way Unicode or ANSI API work. PHP in particular is being compiled without _UNICODE defined and this is conditioned by the way we handle strings. Here is more about it https://msdn.microsoft.com/en-us/library/tsbaswba.aspx However, with any system code page ANSI functions automatically convert paths to UTF-16. Paths in some encodings incompatible with the current system code page, won't work correctly with ANSI APIs. PHP till now only uses the ANSI Windows APIs. For example, on a system with the current code page 1252, the paths in cp1252 are supported and transparently converted to UTF-16 by the ANSI functions. Once one wants to handle a filepath encoded with cp932 on that particular system, an ANSI or a POSIX compatible function used in PHP will produce an erroneous result. When trying to convert that cp932 path to UTF-8 and passing to the ANSI functions, an ANSI function would likely interpret the UTF-8 string as some string in the current code page and create a filepath that represents every single byte of the UTF-8 string. These behaviors are not only broken but also disregard the documented INI settings. This patch solves the issies with the multibyte paths on Windows by intelligently enforcing the usage of the Unicode aware APIs. For functions expect Unicode (fe CreateFileW, FindFirstFileW, etc.), arguments will be converted to UTF-16 wide chars. For functions returning Unicode aware data (fe GetCurrentDirectoryW, etc.), resulting wide string is converted back to char's depending on the current PHP charset settings, either to the current ANSI codepage (this is the behavior prior to this patch) or to UTF-8 (the default behavior). In a particular case, users might have to explicitly set internal_encoding or default_charset, if filenames in ANSI codepage are necessary. Current tests show no regressions and witness that this will be an exotic case, the current default UTF-8 encoding is compatible with any supported system. The dependency libraries are long switching to Unicode APIs, so some tests were also added for extensions not directly related to streams. At large, the patch brings over 150 related tests into the core. Those target and was run on various environments with European, Asian, etc. codepages. General PHP frameworks was tested and showed no regressions. The impact on the current C code base is low, the most places affected are the Windows only places in the three files tsrm_win32.c, zend_virtual_cwd.c and plain_wrapper.c. The actual implementation of the most of the wide char supporting functionality is in win32/ioutil.* and win32/codepage.*, several low level functionsare extended in place to avoid reimplementation for now. No performance impact was sighted. As previously mentioned, the ANSI APIs used prior the patch perform Unicode conversions internally. Using the Unicode APIs directly while doing custom conversions just retains the status quo. The ways to optimize it are open (fe. by implementing caching for the strings converted to wide variants). The long path implementation is user transparent. If a path exceeds the length of _MAX_PATH, it'll be automatically prefixed with \\?\. The MAXPATHLEN is set to 2048 bytes. Appreciation to Pierre Joye, Matt Ficken, @algo13 and others for tips, ideas and testing. Thanks.
2016-06-20 07:32:19 +00:00
#endif
2002-11-04 23:24:15 +00:00
CWD_STATE_FREE_ERR(&new_state);
return retval;
}
2007-08-10 09:09:46 +00:00
/* }}} */
2014-12-13 22:06:14 +00:00
CWD_API int virtual_mkdir(const char *pathname, mode_t mode) /* {{{ */
{
cwd_state new_state;
int retval;
CWD_STATE_COPY(&new_state, &CWDG(cwd));
2014-12-13 22:06:14 +00:00
if (virtual_file_ex(&new_state, pathname, NULL, CWD_FILEPATH)) {
CWD_STATE_FREE_ERR(&new_state);
return -1;
}
#ifdef ZEND_WIN32
Fixed the UTF-8 and long path support in the streams on Windows. Since long the default PHP charset is UTF-8, however the Windows part is out of step with this important point. The current implementation in PHP doesn't technically permit to handle UTF-8 filepath and several other things. Till now, only the ANSI compatible APIs are being used. Here is more about it https://msdn.microsoft.com/en-us/library/windows/desktop/dd317752%28v=vs.85%29.aspx The patch fixes not only issues with multibyte filenames under incompatible codepages, but indirectly also issues with some other multibyte encodings like BIG5, Shift-JIS, etc. by providing a clean way to access filenames in UTF-8. Below is a small list of issues from the bug tracker, that are getting fixed: https://bugs.php.net/63401 https://bugs.php.net/41199 https://bugs.php.net/50203 https://bugs.php.net/71509 https://bugs.php.net/64699 https://bugs.php.net/64506 https://bugs.php.net/30195 https://bugs.php.net/65358 https://bugs.php.net/61315 https://bugs.php.net/70943 https://bugs.php.net/70903 https://bugs.php.net/63593 https://bugs.php.net/54977 https://bugs.php.net/54028 https://bugs.php.net/43148 https://bugs.php.net/30730 https://bugs.php.net/33350 https://bugs.php.net/35300 https://bugs.php.net/46990 https://bugs.php.net/61309 https://bugs.php.net/69333 https://bugs.php.net/45517 https://bugs.php.net/70551 https://bugs.php.net/50197 https://bugs.php.net/72200 https://bugs.php.net/37672 Yet more related tickets can for sure be found - on bugs.php.net, Stackoverflow and Github. Some of the bugs are pretty recent, some descend to early 2000th, but the user comments in there last even till today. Just for example, bug #30195 was opened in 2004, the latest comment in there was made in 2014. It is certain, that these bugs descend not only to pure PHP use cases, but get also redirected from the popular PHP based projects. Given the modern systems (and those supported by PHP) are always based on NTFS, there is no excuse to keep these issues unresolved. The internalization approach on Windows is in many ways different from UNIX and Linux, while it supports and is based on Unicode. It depends on the current system code page, APIs used and exact kind how the binary was compiled The locale doesn't affect the way Unicode or ANSI API work. PHP in particular is being compiled without _UNICODE defined and this is conditioned by the way we handle strings. Here is more about it https://msdn.microsoft.com/en-us/library/tsbaswba.aspx However, with any system code page ANSI functions automatically convert paths to UTF-16. Paths in some encodings incompatible with the current system code page, won't work correctly with ANSI APIs. PHP till now only uses the ANSI Windows APIs. For example, on a system with the current code page 1252, the paths in cp1252 are supported and transparently converted to UTF-16 by the ANSI functions. Once one wants to handle a filepath encoded with cp932 on that particular system, an ANSI or a POSIX compatible function used in PHP will produce an erroneous result. When trying to convert that cp932 path to UTF-8 and passing to the ANSI functions, an ANSI function would likely interpret the UTF-8 string as some string in the current code page and create a filepath that represents every single byte of the UTF-8 string. These behaviors are not only broken but also disregard the documented INI settings. This patch solves the issies with the multibyte paths on Windows by intelligently enforcing the usage of the Unicode aware APIs. For functions expect Unicode (fe CreateFileW, FindFirstFileW, etc.), arguments will be converted to UTF-16 wide chars. For functions returning Unicode aware data (fe GetCurrentDirectoryW, etc.), resulting wide string is converted back to char's depending on the current PHP charset settings, either to the current ANSI codepage (this is the behavior prior to this patch) or to UTF-8 (the default behavior). In a particular case, users might have to explicitly set internal_encoding or default_charset, if filenames in ANSI codepage are necessary. Current tests show no regressions and witness that this will be an exotic case, the current default UTF-8 encoding is compatible with any supported system. The dependency libraries are long switching to Unicode APIs, so some tests were also added for extensions not directly related to streams. At large, the patch brings over 150 related tests into the core. Those target and was run on various environments with European, Asian, etc. codepages. General PHP frameworks was tested and showed no regressions. The impact on the current C code base is low, the most places affected are the Windows only places in the three files tsrm_win32.c, zend_virtual_cwd.c and plain_wrapper.c. The actual implementation of the most of the wide char supporting functionality is in win32/ioutil.* and win32/codepage.*, several low level functionsare extended in place to avoid reimplementation for now. No performance impact was sighted. As previously mentioned, the ANSI APIs used prior the patch perform Unicode conversions internally. Using the Unicode APIs directly while doing custom conversions just retains the status quo. The ways to optimize it are open (fe. by implementing caching for the strings converted to wide variants). The long path implementation is user transparent. If a path exceeds the length of _MAX_PATH, it'll be automatically prefixed with \\?\. The MAXPATHLEN is set to 2048 bytes. Appreciation to Pierre Joye, Matt Ficken, @algo13 and others for tips, ideas and testing. Thanks.
2016-06-20 07:32:19 +00:00
retval = php_win32_ioutil_mkdir(new_state.cwd, mode);
2000-09-03 18:47:35 +00:00
#else
retval = mkdir(new_state.cwd, mode);
2000-09-03 18:47:35 +00:00
#endif
CWD_STATE_FREE_ERR(&new_state);
return retval;
}
2007-08-10 09:09:46 +00:00
/* }}} */
2014-12-13 22:06:14 +00:00
CWD_API int virtual_rmdir(const char *pathname) /* {{{ */
{
cwd_state new_state;
int retval;
CWD_STATE_COPY(&new_state, &CWDG(cwd));
2014-12-13 22:06:14 +00:00
if (virtual_file_ex(&new_state, pathname, NULL, CWD_EXPAND)) {
CWD_STATE_FREE_ERR(&new_state);
return -1;
}
Fixed the UTF-8 and long path support in the streams on Windows. Since long the default PHP charset is UTF-8, however the Windows part is out of step with this important point. The current implementation in PHP doesn't technically permit to handle UTF-8 filepath and several other things. Till now, only the ANSI compatible APIs are being used. Here is more about it https://msdn.microsoft.com/en-us/library/windows/desktop/dd317752%28v=vs.85%29.aspx The patch fixes not only issues with multibyte filenames under incompatible codepages, but indirectly also issues with some other multibyte encodings like BIG5, Shift-JIS, etc. by providing a clean way to access filenames in UTF-8. Below is a small list of issues from the bug tracker, that are getting fixed: https://bugs.php.net/63401 https://bugs.php.net/41199 https://bugs.php.net/50203 https://bugs.php.net/71509 https://bugs.php.net/64699 https://bugs.php.net/64506 https://bugs.php.net/30195 https://bugs.php.net/65358 https://bugs.php.net/61315 https://bugs.php.net/70943 https://bugs.php.net/70903 https://bugs.php.net/63593 https://bugs.php.net/54977 https://bugs.php.net/54028 https://bugs.php.net/43148 https://bugs.php.net/30730 https://bugs.php.net/33350 https://bugs.php.net/35300 https://bugs.php.net/46990 https://bugs.php.net/61309 https://bugs.php.net/69333 https://bugs.php.net/45517 https://bugs.php.net/70551 https://bugs.php.net/50197 https://bugs.php.net/72200 https://bugs.php.net/37672 Yet more related tickets can for sure be found - on bugs.php.net, Stackoverflow and Github. Some of the bugs are pretty recent, some descend to early 2000th, but the user comments in there last even till today. Just for example, bug #30195 was opened in 2004, the latest comment in there was made in 2014. It is certain, that these bugs descend not only to pure PHP use cases, but get also redirected from the popular PHP based projects. Given the modern systems (and those supported by PHP) are always based on NTFS, there is no excuse to keep these issues unresolved. The internalization approach on Windows is in many ways different from UNIX and Linux, while it supports and is based on Unicode. It depends on the current system code page, APIs used and exact kind how the binary was compiled The locale doesn't affect the way Unicode or ANSI API work. PHP in particular is being compiled without _UNICODE defined and this is conditioned by the way we handle strings. Here is more about it https://msdn.microsoft.com/en-us/library/tsbaswba.aspx However, with any system code page ANSI functions automatically convert paths to UTF-16. Paths in some encodings incompatible with the current system code page, won't work correctly with ANSI APIs. PHP till now only uses the ANSI Windows APIs. For example, on a system with the current code page 1252, the paths in cp1252 are supported and transparently converted to UTF-16 by the ANSI functions. Once one wants to handle a filepath encoded with cp932 on that particular system, an ANSI or a POSIX compatible function used in PHP will produce an erroneous result. When trying to convert that cp932 path to UTF-8 and passing to the ANSI functions, an ANSI function would likely interpret the UTF-8 string as some string in the current code page and create a filepath that represents every single byte of the UTF-8 string. These behaviors are not only broken but also disregard the documented INI settings. This patch solves the issies with the multibyte paths on Windows by intelligently enforcing the usage of the Unicode aware APIs. For functions expect Unicode (fe CreateFileW, FindFirstFileW, etc.), arguments will be converted to UTF-16 wide chars. For functions returning Unicode aware data (fe GetCurrentDirectoryW, etc.), resulting wide string is converted back to char's depending on the current PHP charset settings, either to the current ANSI codepage (this is the behavior prior to this patch) or to UTF-8 (the default behavior). In a particular case, users might have to explicitly set internal_encoding or default_charset, if filenames in ANSI codepage are necessary. Current tests show no regressions and witness that this will be an exotic case, the current default UTF-8 encoding is compatible with any supported system. The dependency libraries are long switching to Unicode APIs, so some tests were also added for extensions not directly related to streams. At large, the patch brings over 150 related tests into the core. Those target and was run on various environments with European, Asian, etc. codepages. General PHP frameworks was tested and showed no regressions. The impact on the current C code base is low, the most places affected are the Windows only places in the three files tsrm_win32.c, zend_virtual_cwd.c and plain_wrapper.c. The actual implementation of the most of the wide char supporting functionality is in win32/ioutil.* and win32/codepage.*, several low level functionsare extended in place to avoid reimplementation for now. No performance impact was sighted. As previously mentioned, the ANSI APIs used prior the patch perform Unicode conversions internally. Using the Unicode APIs directly while doing custom conversions just retains the status quo. The ways to optimize it are open (fe. by implementing caching for the strings converted to wide variants). The long path implementation is user transparent. If a path exceeds the length of _MAX_PATH, it'll be automatically prefixed with \\?\. The MAXPATHLEN is set to 2048 bytes. Appreciation to Pierre Joye, Matt Ficken, @algo13 and others for tips, ideas and testing. Thanks.
2016-06-20 07:32:19 +00:00
#ifdef ZEND_WIN32
retval = php_win32_ioutil_rmdir(new_state.cwd);
#else
retval = rmdir(new_state.cwd);
Fixed the UTF-8 and long path support in the streams on Windows. Since long the default PHP charset is UTF-8, however the Windows part is out of step with this important point. The current implementation in PHP doesn't technically permit to handle UTF-8 filepath and several other things. Till now, only the ANSI compatible APIs are being used. Here is more about it https://msdn.microsoft.com/en-us/library/windows/desktop/dd317752%28v=vs.85%29.aspx The patch fixes not only issues with multibyte filenames under incompatible codepages, but indirectly also issues with some other multibyte encodings like BIG5, Shift-JIS, etc. by providing a clean way to access filenames in UTF-8. Below is a small list of issues from the bug tracker, that are getting fixed: https://bugs.php.net/63401 https://bugs.php.net/41199 https://bugs.php.net/50203 https://bugs.php.net/71509 https://bugs.php.net/64699 https://bugs.php.net/64506 https://bugs.php.net/30195 https://bugs.php.net/65358 https://bugs.php.net/61315 https://bugs.php.net/70943 https://bugs.php.net/70903 https://bugs.php.net/63593 https://bugs.php.net/54977 https://bugs.php.net/54028 https://bugs.php.net/43148 https://bugs.php.net/30730 https://bugs.php.net/33350 https://bugs.php.net/35300 https://bugs.php.net/46990 https://bugs.php.net/61309 https://bugs.php.net/69333 https://bugs.php.net/45517 https://bugs.php.net/70551 https://bugs.php.net/50197 https://bugs.php.net/72200 https://bugs.php.net/37672 Yet more related tickets can for sure be found - on bugs.php.net, Stackoverflow and Github. Some of the bugs are pretty recent, some descend to early 2000th, but the user comments in there last even till today. Just for example, bug #30195 was opened in 2004, the latest comment in there was made in 2014. It is certain, that these bugs descend not only to pure PHP use cases, but get also redirected from the popular PHP based projects. Given the modern systems (and those supported by PHP) are always based on NTFS, there is no excuse to keep these issues unresolved. The internalization approach on Windows is in many ways different from UNIX and Linux, while it supports and is based on Unicode. It depends on the current system code page, APIs used and exact kind how the binary was compiled The locale doesn't affect the way Unicode or ANSI API work. PHP in particular is being compiled without _UNICODE defined and this is conditioned by the way we handle strings. Here is more about it https://msdn.microsoft.com/en-us/library/tsbaswba.aspx However, with any system code page ANSI functions automatically convert paths to UTF-16. Paths in some encodings incompatible with the current system code page, won't work correctly with ANSI APIs. PHP till now only uses the ANSI Windows APIs. For example, on a system with the current code page 1252, the paths in cp1252 are supported and transparently converted to UTF-16 by the ANSI functions. Once one wants to handle a filepath encoded with cp932 on that particular system, an ANSI or a POSIX compatible function used in PHP will produce an erroneous result. When trying to convert that cp932 path to UTF-8 and passing to the ANSI functions, an ANSI function would likely interpret the UTF-8 string as some string in the current code page and create a filepath that represents every single byte of the UTF-8 string. These behaviors are not only broken but also disregard the documented INI settings. This patch solves the issies with the multibyte paths on Windows by intelligently enforcing the usage of the Unicode aware APIs. For functions expect Unicode (fe CreateFileW, FindFirstFileW, etc.), arguments will be converted to UTF-16 wide chars. For functions returning Unicode aware data (fe GetCurrentDirectoryW, etc.), resulting wide string is converted back to char's depending on the current PHP charset settings, either to the current ANSI codepage (this is the behavior prior to this patch) or to UTF-8 (the default behavior). In a particular case, users might have to explicitly set internal_encoding or default_charset, if filenames in ANSI codepage are necessary. Current tests show no regressions and witness that this will be an exotic case, the current default UTF-8 encoding is compatible with any supported system. The dependency libraries are long switching to Unicode APIs, so some tests were also added for extensions not directly related to streams. At large, the patch brings over 150 related tests into the core. Those target and was run on various environments with European, Asian, etc. codepages. General PHP frameworks was tested and showed no regressions. The impact on the current C code base is low, the most places affected are the Windows only places in the three files tsrm_win32.c, zend_virtual_cwd.c and plain_wrapper.c. The actual implementation of the most of the wide char supporting functionality is in win32/ioutil.* and win32/codepage.*, several low level functionsare extended in place to avoid reimplementation for now. No performance impact was sighted. As previously mentioned, the ANSI APIs used prior the patch perform Unicode conversions internally. Using the Unicode APIs directly while doing custom conversions just retains the status quo. The ways to optimize it are open (fe. by implementing caching for the strings converted to wide variants). The long path implementation is user transparent. If a path exceeds the length of _MAX_PATH, it'll be automatically prefixed with \\?\. The MAXPATHLEN is set to 2048 bytes. Appreciation to Pierre Joye, Matt Ficken, @algo13 and others for tips, ideas and testing. Thanks.
2016-06-20 07:32:19 +00:00
#endif
CWD_STATE_FREE_ERR(&new_state);
return retval;
}
2007-08-10 09:09:46 +00:00
/* }}} */
#ifdef ZEND_WIN32
2000-09-03 18:47:35 +00:00
DIR *opendir(const char *name);
#endif
2014-12-13 22:06:14 +00:00
CWD_API DIR *virtual_opendir(const char *pathname) /* {{{ */
{
cwd_state new_state;
DIR *retval;
CWD_STATE_COPY(&new_state, &CWDG(cwd));
2014-12-13 22:06:14 +00:00
if (virtual_file_ex(&new_state, pathname, NULL, CWD_REALPATH)) {
CWD_STATE_FREE_ERR(&new_state);
return NULL;
}
retval = opendir(new_state.cwd);
CWD_STATE_FREE_ERR(&new_state);
return retval;
}
2007-08-10 09:09:46 +00:00
/* }}} */
#ifdef ZEND_WIN32
2014-12-13 22:06:14 +00:00
CWD_API FILE *virtual_popen(const char *command, const char *type) /* {{{ */
{
2014-12-13 22:06:14 +00:00
return popen_ex(command, type, CWDG(cwd).cwd, NULL);
}
2007-08-10 09:09:46 +00:00
/* }}} */
2002-05-29 08:41:21 +00:00
#else /* Unix */
2014-12-13 22:06:14 +00:00
CWD_API FILE *virtual_popen(const char *command, const char *type) /* {{{ */
2002-05-29 08:41:21 +00:00
{
size_t command_length;
2004-12-02 01:04:23 +00:00
int dir_length, extra = 0;
2002-05-29 08:41:21 +00:00
char *command_line;
2004-12-02 01:04:23 +00:00
char *ptr, *dir;
2002-05-29 08:41:21 +00:00
FILE *retval;
command_length = strlen(command);
2004-12-02 01:04:23 +00:00
dir_length = CWDG(cwd).cwd_length;
dir = CWDG(cwd).cwd;
while (dir_length > 0) {
if (*dir == '\'') extra+=3;
dir++;
dir_length--;
}
dir_length = CWDG(cwd).cwd_length;
dir = CWDG(cwd).cwd;
ptr = command_line = (char *) emalloc(command_length + sizeof("cd '' ; ") + dir_length + extra+1+1);
2002-05-29 08:41:21 +00:00
memcpy(ptr, "cd ", sizeof("cd ")-1);
ptr += sizeof("cd ")-1;
if (CWDG(cwd).cwd_length == 0) {
*ptr++ = DEFAULT_SLASH;
} else {
2004-12-02 01:04:23 +00:00
*ptr++ = '\'';
while (dir_length > 0) {
switch (*dir) {
case '\'':
*ptr++ = '\'';
*ptr++ = '\\';
*ptr++ = '\'';
/* fall-through */
default:
*ptr++ = *dir;
}
dir++;
dir_length--;
}
*ptr++ = '\'';
2002-05-29 08:41:21 +00:00
}
2010-09-10 14:02:19 +00:00
2002-05-29 08:41:21 +00:00
*ptr++ = ' ';
*ptr++ = ';';
*ptr++ = ' ';
memcpy(ptr, command, command_length+1);
retval = popen(command_line, type);
efree(command_line);
2002-05-29 08:41:21 +00:00
return retval;
}
2007-08-10 09:09:46 +00:00
/* }}} */
#endif
2014-12-13 22:06:14 +00:00
CWD_API char *tsrm_realpath(const char *path, char *real_path) /* {{{ */
{
cwd_state new_state;
char cwd[MAXPATHLEN];
/* realpath("") returns CWD */
if (!*path) {
new_state.cwd = (char*)emalloc(1);
new_state.cwd[0] = '\0';
2010-09-10 14:02:19 +00:00
new_state.cwd_length = 0;
2010-08-27 10:09:52 +00:00
if (VCWD_GETCWD(cwd, MAXPATHLEN)) {
path = cwd;
}
} else if (!IS_ABSOLUTE_PATH(path, strlen(path)) &&
VCWD_GETCWD(cwd, MAXPATHLEN)) {
new_state.cwd = estrdup(cwd);
2014-10-24 18:57:38 +00:00
new_state.cwd_length = (int)strlen(cwd);
} else {
new_state.cwd = (char*)emalloc(1);
new_state.cwd[0] = '\0';
new_state.cwd_length = 0;
}
2014-12-13 22:06:14 +00:00
if (virtual_file_ex(&new_state, path, NULL, CWD_REALPATH)) {
efree(new_state.cwd);
return NULL;
}
if (real_path) {
int copy_len = new_state.cwd_length>MAXPATHLEN-1 ? MAXPATHLEN-1 : new_state.cwd_length;
memcpy(real_path, new_state.cwd, copy_len);
real_path[copy_len] = '\0';
efree(new_state.cwd);
return real_path;
} else {
return new_state.cwd;
}
}
2007-08-10 09:09:46 +00:00
/* }}} */
/*
* Local variables:
* tab-width: 4
* c-basic-offset: 4
* End:
*/