Bug #65358 [Com]: php can't handle 8.3 names of files which have long names with unicode in them

From: Date: Fri, 04 Oct 2013 09:11:38 +0000
Subject: Bug #65358 [Com]: php can't handle 8.3 names of files which have long names with unicode in them
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-182017@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=65358&edit=1

 ID:                 65358
 Comment by:         ku at digitaldolphins dot jp
 Reported by:        rsk82 at live dot com
 Summary:            php can't handle 8.3 names of files which have long
                     names with unicode in them
 Status:             Assigned
 Type:               Bug
 Package:            Filesystem function related
 Operating System:   Windows XP
 PHP Version:        5.4.17
 Assigned To:        pajoye
 Block user comment: N
 Private report:     N

 New Comment:

As a workaround, you can trick php if you allow using ShortName instead of LongName.

You'll need to tweak tsrm_realpath_r.

I'll post a patch to avoid this issue.

Thanks


Previous Comments:
------------------------------------------------------------------------
[2013-08-19 06:34:08] pajoye@php.net

This is not a duplicate bug of the unicode paths support.

The problem here, in this exact (maybe other encoding could be affected but same 
cause then) issue, is that the CRT call FindFirstFileW instead of FindFirstFileA, 
despite that _UNICODE is defined.

Patch on its way.

------------------------------------------------------------------------
[2013-07-30 17:13:15] rsk82 at live dot com

Yes, but there are different things to add support for full fledged unicode names on windows and
support only for shortened 8.3 dos paths that have no unicode chars in them. I thought that such
names would by completely transparent to php like they are for 16 apps. This is not exact duplicate.

------------------------------------------------------------------------
[2013-07-30 16:48:43] ab@php.net

This the general issue with non 7-bit encoded filenames, so duplicate of bug 
#64699, see also bug #61315.

------------------------------------------------------------------------
[2013-07-30 11:12:52] rsk82 at live dot com

Functions affected are not only fopen, but all, no matter if writing or reading the file.

And I think it is and issue in all of the php versions in windows not only 5.4.

------------------------------------------------------------------------
[2013-07-30 11:09:49] rsk82 at live dot com

Description:
------------
I don't know if this is expected. I know that php can't handle international file names in
Windows but shortened paths have no Unicode characters in them so I do not see any reason that php
should have any problem with that.

These paths are perfectly visible to 16bit win311 apps and such files are editable by those
programs, of course them cannot see the correct name of the file but this doesn't count any
problem with accessing their content. And if that I think php should have similar behavior here.

Maybe the php's filesystem functions are trying to "do better" and translate such
path to it's normal mode and subsequently are confused about what they have done.

Test script:
---------------
    <?
    $FS = new \COM('Scripting.FileSystemObject', null, CP_UTF8);
    $FS->CreateTextFile("c:\\Ελλάδα.txt");
    $ShortPath = $FS->GetFile("c:\\Ελλάδα.txt")->ShortPath;
    echo $ShortPath;
    $handle = fopen($ShortPath, 'w');
    ?>

Expected result:
----------------
The script should run without any errors.

Actual result:
--------------
Warning: fopen(C:\BFEE~1.TXT): failed to open stream: Invalid argument in C:\test.php on line 6


------------------------------------------------------------------------



-- 
Edit this bug report at https://bugs.php.net/bug.php?id=65358&edit=1


Thread (9 messages)

« previous php.bugs (#182017) next »