Error when folder path contains special characters (ą, ć)

[GoogleCodeExporter]

As in the summary, test it, reported by Rafael Lauriano.

Original issue reported on code.google.com by czarek.t...@gmail.com on 11 Jun 2013 at 9:56

[GoogleCodeExporter]

This still needs to be confirmed.

Original comment by czarek.t...@gmail.com on 21 Jul 2013 at 6:35

• Added labels: NextRelease

[GoogleCodeExporter]

Confirmed in MSIE. After adding "ąć" to directory name, application displays 
"Page not found" webpage informing that navigation failed. Also the 
php-desktop-msie.exe process is hanging in processes list still after 
application was closed.

Original comment by czarek.t...@gmail.com on 21 Jan 2014 at 12:28

• Added labels: Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

The problem also occurs in phpdesktop-Chrome. The application window displays 
an error message like this:

  Error 500: Internal Server Error
  Cannot spawn CGI process [C:\phpdesktop\phpdesktop-chrome-31.0-php-5.5.8_ąć\www/index.php]: No such device or address

It seems that the problem sits in the Mongoose webserver, needs further 
investigation.

Original comment by czarek.t...@gmail.com on 21 Jan 2014 at 12:31

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

This is the error from the phpdesktop console:

  - 18:12:44.136 WARNING: spawn_process: CreateProcess(C:\phpdesktop\phpdesktop-chrome-─à─ç\php\php-cgi.exe "C:\phpdesktop
\phpdesktop-chrome-─à─ç\www\index.php"): 2

Debug logs from mongoose:

  *** 1390583766.0000094C.spawn_process.1361: Running [C:\phpdesktop\phpdesktop-chrome-ąć\php\php-cgi.exe "C:\phpdesktop\phpdesktop-chrome-ąć\www\index.php"]
  *** 1390583766.0000094C.send_http_error.970: [Error 500: Internal Server Error
Cannot spawn CGI process [C:\phpdesktop\phpdesktop-chrome-ąć\www/index.php]: 
No such device or address]

So the code to fix should be somewhere on line 1361 in the spawn_process() 
function.

Original comment by czarek.t...@gmail.com on 24 Jan 2014 at 5:17

[GoogleCodeExporter]

Fixed the problem in mongoose, creating process with unicode characters works 
fine. But now php-cgi.exe doesn't want to work when passed unicode characters 
to it.Getting this messsage from php-cgi process:

    No input file specified.

Original comment by czarek.t...@gmail.com on 24 Jan 2014 at 6:40

[GoogleCodeExporter]

The php-cgi.exe executable seems to be compiled in ASCII mode, so it can't 
accept unicode paths. It won't even work passing a normal ascii path with no 
special characters, but when the php-cgi.exe executable is in a path that 
contains special characters.

Original comment by czarek.t...@gmail.com on 24 Jan 2014 at 6:56

[GoogleCodeExporter]

Correction to comment #12: the php-cgi.exe can reside in a directory with 
unicode characters. The problem is running a php script that resides in a 
directory with unicode characters. Even when path to such script is relative, 
it will fail.

Original comment by czarek.t...@gmail.com on 24 Jan 2014 at 7:12

[GoogleCodeExporter]

The php.exe executable can run scripts fine when the php.exe resides in a 
unicode path and when the provided path to php.exe is relative. So it should 
also be possible for this to work in php-cgi.exe. Probably php-cgi uses a 
different function to open the file.

PHP CLI (php.exe) is using VCWD_FOPEN() to open a file.
PHP CGI is using php_fopen_primary_script(), thus the different behavior.

Original comment by czarek.t...@gmail.com on 24 Jan 2014 at 8:00

[GoogleCodeExporter]

In php_fopen_primary_script() it calls zend_resolve_path() and that is causing 
the issue. It tries to resolve an unicode path and results in error. The fix 
would be to get rid of that call, build php-cgi.exe from sources and include 
the custom built cgi executables with phpdesktop binaries.

Instructions on building php from sources:
https://wiki.php.net/internals/windows/stepbystepbuild

Also a minor modification to mongoose would be required, so that it passes a 
relative path to the php script.

Original comment by czarek.t...@gmail.com on 24 Jan 2014 at 8:04

[GoogleCodeExporter]

It is sad that PHP doesn't support unicode paths and this cannot be easily 
fixed. The only solution left that I'm thinking of would be to force php to use 
some virtual file system layer on top of which we would fix the unicode 
support. It's not a fix for the whole unicode issue in php, but only for our 
use case, when the www/ directory is on a path that contains unicode 
characters. This solution would require to provide custom php binaries for 
phpdesktop. Not sure how this would play with loading of custom php extensions 
like the php encoders.

Original comment by czarek.t...@gmail.com on 24 Jan 2014 at 11:34

[GoogleCodeExporter]

Much of the code that would need to be modified to support unicode in PHP 
5.4/5.5 is in TSRM/tsrm_virtual_cwd.c. I've been investigating the unicode 
issue for many hours and there are so many complexities in doing it. I don't 
think I wil take on this task. In PHP 5.6 they have even refactored much of the 
TSRM directory. A crazy amount of time would need to be devoted to support this 
feature. I've read that php 5.6 was supposed to fix unicde path issues, but 
I've tested 5.6.0-alpha1 and the issue still exists. PHP 6 was supposed to 
support unicode but was abandoned due to complexities. I don't see PHP 
supporting unicode paths anytime soon.

Original comment by czarek.t...@gmail.com on 25 Jan 2014 at 1:03

• Changed state: WontFix

[GoogleCodeExporter]

Issue 68 has been merged into this issue.

Original comment by czarek.t...@gmail.com on 25 Jan 2014 at 1:21

[GoogleCodeExporter]

Issue 68 has been merged into this issue.

Original comment by czarek.t...@gmail.com on 25 Jan 2014 at 1:56

[GoogleCodeExporter]

Fixed unicode paths issues in the mongoose webserver in revision 44266e938f59.

Original comment by czarek.t...@gmail.com on 25 Jan 2014 at 2:10