Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91044
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain belski.net from 85.214.73.107 cause and error)
To: "'Dmitry Stogov'" <dmitry@zend.com>,
	<internals@lists.php.net>
Cc: "'Pierre Joye'" <pierre.php@gmail.com>,
	"'Xinchen Hui'" <laruence@gmail.com>,
	"'Nikita Popov'" <nikita.ppv@gmail.com>
References: <03ca01d159da$fe2d76b0$fa886410$@belski.net> <56AF2410.3090009@zend.com>
In-Reply-To: <56AF2410.3090009@zend.com>
Date: Mon, 1 Feb 2016 11:03:14 +0100
Message-ID: <006301d15cd7$c60fe6f0$522fb4d0$@belski.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AQHc/OH61fGL/otFQ0yoa3ZjD19IYAFPI2IinvU4JCA=
Content-Language: en-us
Subject: RE: [PHP-DEV] Re: Streams and I/O refactoring approach
From: anatol.php@belski.net ("Anatol Belski")


Hi Dmitry,

Many thanks for the comments.

> -----Original Message-----
> From: Dmitry Stogov [mailto:dmitry@zend.com]
> Sent: Monday, February 1, 2016 10:23 AM
> To: Anatol Belski <anatol.php@belski.net>; internals@lists.php.net
> Cc: 'Pierre Joye' <pierre.php@gmail.com>; 'Xinchen Hui'
> <laruence@gmail.com>; 'Nikita Popov' <nikita.ppv@gmail.com>
> Subject: [PHP-DEV] Re: Streams and I/O refactoring approach
> 
> Hi,
> 
> At current state, I see this not as a whole stream layer refactoring, but
as a low-
> level replacement of POSIX layer on Windows.
> I see only few "visible" changes:
>
Basically it's the result of analyzing the code of particularly APR, libuv
and several other projects. While libuv works with UTF-8 paths only, APR
retains a wider compatibility. Please check the code here for an example

https://github.com/apache/apr/blob/trunk/file_io/win32/open.c#L321
 
> 1. The layer first checks, if file names are valid UTF-8 strings, and use
UTF-8
> names or fall back to system locale.
Yep, it is done for the fallback, and also the non-unicode part is
conditional, so can be turned off on compilation time with
PHP_WIN32_IOUTIL_ANSI_COMPAT_MODE set to 0. For an example how it is done in
APR

https://github.com/apache/apr/blob/trunk/file_io/win32/open.c#L406

Currently it would make sense to keep this fallback, so the current
scripts/codes using non-unicode would keep to work.

> 2. The patch allows to use long file names (longer than MAX_PATH) using
> "//?/******<utf8-absolute-long-path>"
Yep, to do is to prepend \\?\ transparently for the user. But even without
\\?\ multibyte paths are supported.

> 3. Files now are opened in FILE_SHARE_READ | FILE_SHARE_WRITE |
> FILE_SHARE_DELETE mode (I'm not sure about intended better POSIX
> compliance and possible side effects).
> 
This is done in most projects, fe

https://github.com/apache/apr/blob/trunk/file_io/win32/open.c#L346

But we can remove it if there's something wrong.

> For me, the approach looks a bit inconsistent, especially the attempt to
use the
> same string as UTF-8 and then using some code page.
> 

The only difference of my approach to the other projects is that I suggest
to keep the POSIX compatible APIs, instead of having a whole scruct
describing a filesystem object, fe

https://ci.apache.org/projects/httpd/trunk/doxygen/structapr__file__t.html
 
It could be done later, but for now keeping POSIX APIs would be IMHO the
simplest solution. And as I've stated, it is just a preparation to have
everything at the same base, otherwise further improvements are quite
tedious.

Regards

Anatol