Hi, > -----Original Message----- > From: Anatol Belski [mailto:anatol....@belski.net] > Sent: Monday, February 1, 2016 11:03 AM > To: 'Dmitry Stogov' <dmi...@zend.com>; internals@lists.php.net > Cc: 'Pierre Joye' <pierre....@gmail.com>; 'Xinchen Hui' > <larue...@gmail.com>; 'Nikita Popov' <nikita....@gmail.com> > Subject: RE: [PHP-DEV] Re: Streams and I/O refactoring approach > > > 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. > After some discussions and rethinking this approach, I came to conclusion that creating a layer with POSIX compatible signatures for low level IO is most likely not a good idea. I won't continue on this idea and rather going for an RFC to target better APIs and refactoring for the low level IO layer. Though probably it were worth to reuse the parts of this patch to add the missing features in the current code base.
Thanks. Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
