While I'm not enamored with the idea of running a beta in production, this problem appears to be resolved in 5.4.0beta1-dev.

I've setup Apache 2.2.19 and PHP 5.3.8 (though not with mod_ssl) and have run the test script you provided, but it doesn't produce the problem you reported (it works fine).

In your report, $_FILES['filename']['name'] reports the length of the string as 10, even though only 9 characters are displayed.

Is it possible that somewhere in your program you're converting between charsets or mangling the filename.

Also, could you provide a packet capture of the network traffic between your web browser and your web application. You can do this with Wireshark (Windows/Linux) or NetMon (Windows).

Yes, I will attempt to get this information to you. I can say that we were using 5.2.13 without incident prior to updating to 5.3.8. After updating to 5.3.8, we were notified by users that they could no longer download files that they were successfully uploading. That was when I determined the missing first character. Because we didn't want to go backward, I put on the 5.4 version, and the problem went away. Note that no changes were made in the PHP source during the process of changing versions. I will try to back all that with the requested data.

Keeping state at "Feedback" until data requested by mafick is provided.

Here are the capture contents using Wireshark and PHP 5.3.8:

No.     Time        Source                Destination           Protocol Length Info
   1203 7.252093    10.0.0.251            184.18.147.3          HTTP     986    POST /private/aaron/filename.php HTTP/1.1  (text/plain)

Frame 1203: 986 bytes on wire (7888 bits), 986 bytes captured (7888 bits)
Ethernet II, Src: AsustekC_8e:2f:bb (00:26:18:8e:2f:bb), Dst: 3com_49:bb:06 (00:01:02:49:bb:06)
Internet Protocol Version 4, Src: 10.0.0.251 (10.0.0.251), Dst: 184.18.147.3 (184.18.147.3)
Transmission Control Protocol, Src Port: 65260 (65260), Dst Port: http (80), Seq: 1, Ack: 1, Len: 932
Hypertext Transfer Protocol
MIME Multipart Media Encapsulation, Type: multipart/form-data, Boundary: "---------------------------9503744825200"
    [Type: multipart/form-data]
    First boundary: -----------------------------9503744825200\r\n
    Encapsulated multipart part:  (text/plain)
        Content-Disposition: form-data; name="filename"; filename="readme.txt"\r\n
        Content-Type: text/plain\r\n\r\n
        Line-based text data: text/plain
            Hello! This is a test.
    Last boundary: \r\n-----------------------------9503744825200--\r\n

No.     Time        Source                Destination           Protocol Length Info
   1205 7.252782    10.0.0.1              10.0.0.251            HTTP     986    POST /private/aaron/filename.php HTTP/1.1  (text/plain)

Frame 1205: 986 bytes on wire (7888 bits), 986 bytes captured (7888 bits)
Ethernet II, Src: 3com_49:bb:06 (00:01:02:49:bb:06), Dst: AsustekC_8e:2f:bb (00:26:18:8e:2f:bb)
Internet Protocol Version 4, Src: 10.0.0.1 (10.0.0.1), Dst: 10.0.0.251 (10.0.0.251)
Transmission Control Protocol, Src Port: 65260 (65260), Dst Port: http (80), Seq: 1, Ack: 1, Len: 932
Hypertext Transfer Protocol
MIME Multipart Media Encapsulation, Type: multipart/form-data, Boundary: "---------------------------9503744825200"
    [Type: multipart/form-data]
    First boundary: -----------------------------9503744825200\r\n
    Encapsulated multipart part:  (text/plain)
        Content-Disposition: form-data; name="filename"; filename="readme.txt"\r\n
        Content-Type: text/plain\r\n\r\n
        Line-based text data: text/plain
            Hello! This is a test.
    Last boundary: \r\n-----------------------------9503744825200--\r\n

I started going back version by version from 5.3.8 to see where the problem started, and it seems to have begun with 5.3.7, as 5.3.6 works correctly. Once again, I'm just replacing PHP builds -- I'm not modifying any else. With 5.3.6, I get back what I would expect:

array(1) { ["filename"]=> array(5) { ["name"]=> string(10) "readme.txt" ["type"]=> string(10) "text/plain" ["tmp_name"]=> string(31) "C:\temp\file_upload\php594F.tmp" ["error"]=> int(0) ["size"]=> int(22) } } 

With 5.3.7 and 5.3.8, I get back the missing first letter:

array(1) { ["filename"]=> array(5) { ["name"]=> string(10) "eadme.txt" ["type"]=> string(10) "text/plain" ["tmp_name"]=> string(31) "C:\temp\file_upload\php594F.tmp" ["error"]=> int(0) ["size"]=> int(22) } } 

With 5.4.beta1-dev, I'm back to getting everything that I expect:

array(1) { ["filename"]=> array(5) { ["name"]=> string(10) "readme.txt" ["type"]=> string(10) "text/plain" ["tmp_name"]=> string(31) "C:\temp\file_upload\php594F.tmp" ["error"]=> int(0) ["size"]=> int(22) } }

This bug is present on Windows with magic_quotes_gpc on. "s" is then always set and the change in r312103 means the leading char is skipped.

This bug has been fixed in SVN.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.

 For Windows:

http://windows.php.net/snapshots/
 
Thank you for the report, and for helping us make PHP better.

I can confirm that this is fixed in 5.3 r315756. Thank you for the fix, and the quick turn around.