php-windows Digest 31 Jul 2013 06:27:10 -0000 Issue 4124
Topics (messages 31076 through 31086):
Re: CLI Crash Bug
31076 by: Jan Ehrhardt
31081 by: Keith Davis
31082 by: Keith Davis
31083 by: Jan Ehrhardt
Re: php can't resolve 8.3 paths to unicode filenames, is that expected ?
31077 by: Anatol Belski
31078 by: R. S.
31080 by: Anatol Belski
31084 by: R. S.
31085 by: Anatol Belski
31086 by: R. S.
to unsubscribe this email id from the list
31079 by: Aviral Nigam
Administrivia:
To subscribe to the digest, e-mail:
php-windows-digest-subscr...@lists.php.net
To unsubscribe from the digest, e-mail:
php-windows-digest-unsubscr...@lists.php.net
To post to the list, e-mail:
php-wind...@lists.php.net
----------------------------------------------------------------------
--- Begin Message ---
Jan Ehrhardt in php.windows (Tue, 30 Jul 2013 18:15:50 +0200):
>Keith Davis in php.windows (Fri, 26 Jul 2013 16:24:26 -0500):
>>Ok, I copied both php5.dll and php_wincache.dll from the ones you
>>compiled, Jan, with Eric's patch and it works!
>
>New compilation without Eric's patch, but with Dmitry's patch of today:
>https://dl.dropboxusercontent.com/u/8954372/php-5.5.2-dev-nts-Win32-VC11-x86.zip
BTW: you'll only need php_wincache.dll and php_opcache.dll from this
build in addition to the official PHP 5.5.1 build. PHP 5.5.2 (due in
about two weeks) will contain Dmitry's patch officially.
Jan
--- End Message ---
--- Begin Message ---
But I thought from the previous fix, what was updated was php5.dll. So, to be
clear, I want to use a base (revert my php5.dll file to base) 5.5.1 build with
the new php_wincache.dll and php_opcache.dll files?
Keith Davis (214) 906-5183
-----Original Message-----
From: Jan Ehrhardt [mailto:php...@ehrhardt.nl]
Sent: Tuesday, July 30, 2013 11:25 AM
To: php-wind...@lists.php.net
Subject: Re: [PHP-WIN] Re: CLI Crash Bug
Jan Ehrhardt in php.windows (Tue, 30 Jul 2013 18:15:50 +0200):
>Keith Davis in php.windows (Fri, 26 Jul 2013 16:24:26 -0500):
>>Ok, I copied both php5.dll and php_wincache.dll from the ones you
>>compiled, Jan, with Eric's patch and it works!
>
>New compilation without Eric's patch, but with Dmitry's patch of today:
>https://dl.dropboxusercontent.com/u/8954372/php-5.5.2-dev-nts-Win32-VC1
>1-x86.zip
BTW: you'll only need php_wincache.dll and php_opcache.dll from this build in
addition to the official PHP 5.5.1 build. PHP 5.5.2 (due in about two weeks)
will contain Dmitry's patch officially.
Jan
--
PHP Windows Mailing List (http://www.php.net/) To unsubscribe, visit:
http://www.php.net/unsub.php
This message (including any attachments) may contain confidential or otherwise
privileged information and is intended only for the individual(s) to which it
is addressed. If you are not the named addressee you should not disseminate,
distribute or copy this e-mail. Please notify the sender immediately by e-mail
if you have received this e-mail by mistake and delete this e-mail from your
system. E-mail transmission cannot be guaranteed to be secured or error-free as
information could be intercepted, corrupted, lost, destroyed, arrive late or
incomplete, or contain viruses. The sender therefore does not accept liability
for any errors or omissions in the contents of this message or that arise as a
result of e-mail transmission. If verification is required please request a
hard-copy version from the sender.
www.pridedallas.com
--- End Message ---
--- Begin Message ---
For clarity, I'm testing the whole 5.5.2-dev build. Seems to work fine.
Keith Davis (214) 906-5183
From: Keith Davis [mailto:keithda...@pridedallas.com]
Sent: Tuesday, July 30, 2013 3:57 PM
To: php-wind...@lists.php.net
Subject: RE: [PHP-WIN] Re: CLI Crash Bug
But I thought from the previous fix, what was updated was php5.dll. So, to be
clear, I want to use a base (revert my php5.dll file to base) 5.5.1 build with
the new php_wincache.dll and php_opcache.dll files?
Keith Davis (214) 906-5183
-----Original Message-----
From: Jan Ehrhardt [mailto:php...@ehrhardt.nl]
Sent: Tuesday, July 30, 2013 11:25 AM
To: php-wind...@lists.php.net
Subject: Re: [PHP-WIN] Re: CLI Crash Bug
Jan Ehrhardt in php.windows (Tue, 30 Jul 2013 18:15:50 +0200):
>Keith Davis in php.windows (Fri, 26 Jul 2013 16:24:26 -0500):
>>Ok, I copied both php5.dll and php_wincache.dll from the ones you
>>compiled, Jan, with Eric's patch and it works!
>
>New compilation without Eric's patch, but with Dmitry's patch of today:
>https://dl.dropboxusercontent.com/u/8954372/php-5.5.2-dev-nts-Win32-VC1
>1-x86.zip
BTW: you'll only need php_wincache.dll and php_opcache.dll from this build in
addition to the official PHP 5.5.1 build. PHP 5.5.2 (due in about two weeks)
will contain Dmitry's patch officially.
Jan
This message (including any attachments) may contain confidential or otherwise
privileged information and is intended only for the individual(s) to which it
is addressed. If you are not the named addressee you should not disseminate,
distribute or copy this e-mail. Please notify the sender immediately by e-mail
if you have received this e-mail by mistake and delete this e-mail from your
system. E-mail transmission cannot be guaranteed to be secured or error-free as
information could be intercepted, corrupted, lost, destroyed, arrive late or
incomplete, or contain viruses. The sender therefore does not accept liability
for any errors or omissions in the contents of this message or that arise as a
result of e-mail transmission. If verification is required please request a
hard-copy version from the sender.
www.pridedallas.com
--- End Message ---
--- Begin Message ---
Keith Davis in php.windows (Tue, 30 Jul 2013 15:57:05 -0500):
>But I thought from the previous fix, what was updated was php5.dll. So,
>to be clear, I want to use a base (revert my php5.dll file to base)
>5.5.1 build with the new php_wincache.dll and php_opcache.dll files?
Yes. Dmitry took another road to solve the problem, which did not modify
php5.dll. He only patched php_opcache.dll.
Jan
--- End Message ---
--- Begin Message ---
On Tue, July 30, 2013 00:25, R. S. wrote:
> The thing is these paths do not have any non ascii chars in them. Old 16b
> win311 apps are perfectly fine with such files, they just can't correctly
> show their name nor create a fresh file with non ascii name. And such
> behavior I was expecting from php.
>
>
> <?
> $FS = new \COM('Scripting.FileSystemObject', null, CP_UTF8);
> $FS->CreateTextFile("c:\\Ελλάδα.txt");
> $ShortPath = $FS->GetFile("c:\\Ελλάδα.txt")->ShortPath;
> echo $ShortPath; file_get_contents($ShortPath); ?>
>
>
> error:
> Warning: file_get_contents(C:\BFEE~1.TXT): failed to open stream: Invalid
> argument in C:\test.php on line 12
>
> I think somewhere down the rabbit hole the function tries to recreate
> original path and then gets confused.
>
> Is there any way around it ? Like creating a handle from a COM object, or
> a separate protocol like in file_get_contents("php://stdin"), or whatever
> to pass it to the fopen() so php won't see the offending name ?
>
This is a known issue with 8 bit filenames, please read here
https://bugs.php.net/bug.php?id=64699 . If you work with COM, why don't
you use it to get the file contents?
Regards
Anatol
--- End Message ---
--- Begin Message ---
Hello Anatol,
Tuesday, July 30, 2013, 6:32:42 PM, you wrote:
> This is a known issue with 8 bit filenames, please read here
Yes, but 8.3 names are not 8-bit.
> If you work with COM, why don't
> you use it to get the file contents?
I really need a file handle to use with for example
curl which needs it to store content of downloading file.
Is there a way of producing a file handle with COM
that is understandable by php ?
--- End Message ---
--- Begin Message ---
On Tue, 2013-07-30 at 18:53 +0200, R. S. wrote:
> > This is a known issue with 8 bit filenames, please read here
>
> Yes, but 8.3 names are not 8-bit.
In addition to the fact that 8.3 names are an issue themselves as they
might be not present on a particular system, it's about a multibyte name
in your case. So it needs to be encoded and decoded.
>
> > If you work with COM, why don't
> > you use it to get the file contents?
>
> I really need a file handle to use with for example
> curl which needs it to store content of downloading file.
>
> Is there a way of producing a file handle with COM
> that is understandable by php ?
Not sure about that and whether it's needed. I'd rather do inside out,
use a non unicode filename with CURL and then move that file into some
unicode name using a cmd script. Or even move it using COM.
Regards
Anatol
--- End Message ---
--- Begin Message ---
Hello Anatol,
Tuesday, July 30, 2013, 10:13:28 PM, you wrote:
> In addition to the fact that 8.3 names are an issue themselves as they
> might be not present on a particular system,
I don't see any issue if 8.3 are not present. If they don't they don't.
I think then com would even be able to create such a name for me
to use it with php.
There are many features required of optional to run the language, like
particular c++ libraries present on the system. It's up to coder to if around
the issue if he thinks that not every system would have a feature.
> it's about a multibyte name
> in your case. So it needs to be encoded and decoded.
In my case there is not a multibyte name. PHP should not do any encoding or
decoding here. How is that programs that never heard of Unicode from 1990s
are able to open Unicode named files perfectly fine ?
The real issue is if a program gets slightly aware of a feature so it
is able to detect it but not cope with it. PHP should not touch the name as it
was
given in the function.
> Not sure about that and whether it's needed. I'd rather do inside out,
> use a non unicode filename with CURL and then move that file into some
> unicode name using a cmd script. Or even move it using COM.
Yeah, I know of that way.
I filled a bug here: https://bugs.php.net/bug.php?id=65358
But they dismissed it as duplicate.
It has nothing to do with these bugs:
https://bugs.php.net/bug.php?id=64699
https://bugs.php.net/bug.php?id=61315
Where people tried to put Unicode strings *directly* into php functions.
Again I understand that it not works and wont work until a nowhere seen
php6 with Unicode support comes up.
Here I want to protect php from seeing the Unicode, but it still knows better
and tries to
resolve these shortened path.
I wonder if someone who dismissed my bug even looked at it for more of one
second.
--- End Message ---
--- Begin Message ---
Dear R.S.,
On Tue, July 30, 2013 23:28, R. S. wrote:
> I filled a bug here: https://bugs.php.net/bug.php?id=65358
> But they dismissed it as duplicate.
> It has nothing to do with these bugs:
> https://bugs.php.net/bug.php?id=64699
> https://bugs.php.net/bug.php?id=61315
>
>
> Where people tried to put Unicode strings *directly* into php functions.
> Again I understand that it not works and wont work until a nowhere seen
> php6 with Unicode support comes up.
>
> Here I want to protect php from seeing the Unicode, but it still knows
> better and tries to resolve these shortened path.
>
> I wonder if someone who dismissed my bug even looked at it for more of
> one second.
just compare the mail addresses and you'll see that it was me who has
changed the status of your ticket. This has to be understood literally as
a duplicate, not dismiss. We dont need multiple open tickets about the
same thing, so for this reason. To check that it is indeed a multibyte
filename issue, I'll describe how I checkit:
- in an arbitrary dir create two files zzzzzzzzz_Ελλάδα.txt and
zzzzzzzzz_ellada.txt
- list the files with the commando dir /x, the relevant part i see here is
07/31/2013 12:22 AM 0 ZZZZZZ~2.TXT zzzzzzzzz_ellada.txt
07/31/2013 12:22 AM 0 ZZZZZZ~1.TXT zzzzzzzzz_ε???δα.txt
- do these simple runs
> php -r "var_dump(fopen('ZZZZZZ~2.TXT', 'r'));"
resource(5) of type (stream)
> php -r "var_dump(fopen('ZZZZZZ~1.TXT', 'r'));"
Warning: fopen(ZZZZZZ~1.TXT): failed to open stream: Invalid argument in
Command line code on line 1
bool(false)
The file without multibyte chars in the name can be opened. Also, do you
notice that question marks in the other filename? Those have to be
handled. Despite of how good the other old and new programs are, PHP
doesn't support this at the moment. That isn't a thing of belief but the
fact.
As a dessert I'd suggest you to read this ticket from not very recent past
about how it's going in python http://bugs.python.org/issue13247 :)
Cheers
Anatol
--- End Message ---
--- Begin Message ---
Hello Anatol,
Wednesday, July 31, 2013, 12:47:58 AM, you wrote:
> Warning: fopen(ZZZZZZ~1.TXT): failed to open stream: Invalid argument in
> Command line code on line 1
> bool(false)
Yes, but how does the function even know that there are multibyte
in it's arguments ? Since it was given the ascii compliant name ?
And why 16 bit apps don't experience any errors since they are much
older than php ? Maybe because they are ignorant about multibyte paths ?
Shouldn't php be ignorant too if it can't handle it ?
> The file without multibyte chars in the name can be opened. Also, do you
> notice that question marks in the other filename?
Yes, but there are no question marks in shortenened path.
> Those have to be handled.
But how the php function does know about that ?
Now I tried to open that greek file in old msdos 622 and it worked
without any issue. Although I know it will mess it name if I try to
change it. And I expect the same from php. But I don't want here
to rename anything in php.
> Despite of how good the other old and new programs are, PHP
> doesn't support this at the moment.
So it should and it is a bug. And it is the two different things if
I want you to make PHP Unicode complying, which I do not.
I want you to make php completely ignorant of unicode paths
as are the old 20 yo apps until it will be able to 100% successfully handle it.
> As a dessert I'd suggest you to read this ticket from not very recent past
> about how it's going in python http://bugs.python.org/issue13247 :)
under Windows, os.path.abspath returns non-ASCII bytes paths as question marks
but what you need abspath for ? and why php filesystem functions need
to know absolute path ?
another thing I noticed is that php doesn't as I thought try to translate the
path, if I give it
the one without unicode I get back it in the same shortened form
so what is happening here ? it doesn't give the user absolute path but it must
be using it somewhere internally
<?
$FS = new \COM('Scripting.FileSystemObject', null, CP_UTF8);
$FS->CreateTextFile("c:\\zzzzzzzzz_ellada.txt");
$ShortPath = $FS->GetFile("c:\\zzzzzzzzz_ellada.txt")->ShortPath;
echo "short path: ".$ShortPath."\n";
$handle = fopen($ShortPath, 'r');
echo "handle path: ".stream_get_meta_data($handle)['uri']."\n";
// echoes: C:\ZZZZZZ~2.TXT
?>
--- End Message ---
--- Begin Message ---
please unsubscribe this email id from your mailing list
--- End Message ---
