Closed GoogleCodeExporter closed 9 years ago
This still needs to be confirmed.
Original comment by czarek.t...@gmail.com
on 21 Jul 2013 at 6:35
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
[deleted comment]
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
[deleted comment]
[deleted comment]
[deleted comment]
[deleted comment]
[deleted comment]
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
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
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
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
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
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
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
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
Issue 68 has been merged into this issue.
Original comment by czarek.t...@gmail.com
on 25 Jan 2014 at 1:21
Issue 68 has been merged into this issue.
Original comment by czarek.t...@gmail.com
on 25 Jan 2014 at 1:56
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
Project will move to Github. Find this issue at the new address (soon):
https://github.com/cztomczak/phpdesktop/issues/33
Original comment by czarek.t...@gmail.com
on 24 Aug 2015 at 3:19
Original issue reported on code.google.com by
czarek.t...@gmail.com
on 11 Jun 2013 at 9:56