Hi Dmitry, Many thanks for the comments.
> -----Original Message----- > From: Dmitry Stogov [mailto:dmi...@zend.com] > Sent: Monday, February 1, 2016 10:23 AM > To: Anatol Belski <anatol....@belski.net>; internals@lists.php.net > Cc: 'Pierre Joye' <pierre....@gmail.com>; 'Xinchen Hui' > <larue...@gmail.com>; 'Nikita Popov' <nikita....@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
