|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #65358 php can't handle 8.3 names of files which have long names with unicode in them
Submitted: 2013-07-30 11:09 UTC Modified: 2020-11-18 16:22 UTC
Avg. Score:4.7 ± 0.6
Reproduced:10 of 10 (100.0%)
Same Version:4 (40.0%)
Same OS:6 (60.0%)
From: rsk82 at live dot com Assigned: cmb (profile)
Status: Closed Package: Filesystem function related
PHP Version: 5.4.17 OS: Windows XP
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
Solve the problem:
42 + 48 = ?
Subscribe to this entry?

 [2013-07-30 11:09 UTC] rsk82 at live dot com
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);
    $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


0001-Workaround-to-support-short-path-which-has-Unicode-c (last revision 2013-10-04 09:23 UTC by ku at digitaldolphins dot jp)

Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2013-07-30 11:12 UTC] 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 16:48 UTC]
-Status: Open +Status: Duplicate
 [2013-07-30 16:48 UTC]
This the general issue with non 7-bit encoded filenames, so duplicate of bug 
#64699, see also bug #61315.
 [2013-07-30 17:13 UTC] 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-08-19 06:34 UTC]
-Status: Duplicate +Status: Assigned -Assigned To: +Assigned To: pajoye
 [2013-08-19 06:34 UTC]
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-10-04 09:11 UTC] ku at digitaldolphins dot jp
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.

 [2015-01-29 17:43 UTC] henry dot fai dot hang dot chan at gmail dot com
Would this be fixed in time for PHP 7?
 [2017-10-24 07:37 UTC]
-Status: Assigned +Status: Open -Assigned To: pajoye +Assigned To:
 [2020-11-18 16:22 UTC]
-Status: Open +Status: Closed -Assigned To: +Assigned To: cmb
 [2020-11-18 16:22 UTC]
This has been fixed in the meantime due to UTF-8 path support[1].

[1] <>
PHP Copyright © 2001-2023 The PHP Group
All rights reserved.
Last updated: Tue Mar 21 18:03:39 2023 UTC