Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:14042 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 54731 invoked by uid 1010); 10 Dec 2004 23:04:55 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 45181 invoked from network); 10 Dec 2004 23:03:46 -0000 Received: from unknown (HELO charon.simplot.com) (12.18.144.212) by pb1.pair.com with SMTP; 10 Dec 2004 23:03:46 -0000 Received: from occ01mx003.na.simplot.com (10.10.6.25) by charon.simplot.com (MX V5.3 AnGp) with SMTP for ; Fri, 10 Dec 2004 16:03:44 -0700 Received: from 10.10.6.3 by occ01mx003.na.simplot.com (InterScan E-Mail VirusWall NT); Fri, 10 Dec 2004 16:03:44 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C4DF0C.7F060037" Date: Fri, 10 Dec 2004 16:06:33 -0700 Message-ID: <5367F26C013DE8429873569307F6F4A37313AB@OCC01MX023.na.simplot.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: PHP Bug# 27633 Patch Thread-Index: AcTfCOS3LiHpbRzPQXmcfZy2/GkpFAAAIPlQ To: Subject: PHP Bug# 27633 Patch From: Jesse.Binam@simplot.com ("Binam, Jesse") ------_=_NextPart_001_01C4DF0C.7F060037 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This patch should fix bug# 27633. The messed up line endings in the output was caused by *some* servers prefixing every '\n' with a '\r' so if the remote file already had windows style line endings the data in the buffer was "\r\r\n" and the existing code didn't handle this correcly. I have tested this against vsftpd, ws-ftpd, warftp, os400 ftp, and successfully transferred files with both *nix and win32 style line endings correctly. As a side note... The problem that a dot hoekstra at boxitbv dot nl expressed where large files would be truncated, I believe was caused by the last characters in the buffer being a line ending. On the next iteration of the loop it would write all the nulls at the end of the buffer to the stream?? I saw this twice in my testing. The rest of the data was there, it was just after a bunch of nulls. So it wasn't truncated per se, the filesize was actually significantly larger, but I can see how it could *appear* truncated. After this patch I transferred several megs of data and didn't see this, but YMMV on this one! If it's still a problem let me know and I will look at it. Jess P.S. As this is the first time I have contributed anything publicly with my name attached, constructive critsism of my code is welcome, but please be gentle. ;) ------_=_NextPart_001_01C4DF0C.7F060037 Content-Type: text/plain; name="27633.diff" Content-Transfer-Encoding: base64 Content-Description: 27633.diff Content-Disposition: attachment; filename="27633.diff" LS0tIGZ0cC5jLmJhawlXZWQgRGVjICA4IDA5OjI3OjQ1IDIwMDQNCisrKyBmdHAuYwlGcmkgRGVj IDEwIDE1OjM1OjAzIDIwMDQNCkBAIC04NDYsMTYgKzg0NiwyNSBAQA0KIAkJCSAqIEV2ZXJ5dGhp bmcgRWxzZSBcbg0KIAkJCSAqLw0KICNpZmRlZiBQSFBfV0lOMzINCi0JCQl3aGlsZSAoKHMgPSBz dHJwYnJrKHB0ciwgIlxyXG4iKSkpIHsNCi0JCQkJaWYgKCpzID09ICdcbicpIHsNCi0JCQkJCXBo cF9zdHJlYW1fcHV0YyhvdXRzdHJlYW0sICdccicpOw0KKwkJCXdoaWxlICgocyA9IHN0cnBicmso cHRyLCAiXHJcbiIpKSAmJiAocyA8IGUpKSB7DQorDQorCQkJCS8qIGZvciBzb21lIHJlYXNvbiBz b21lIHNlcnZlcnMgcHJlZml4IGEgXHIgYmVmb3JlIGEgXG4sIA0KKwkJCQkgKiByZXN1bHRpbmcg aW4gYSBcclxyXG4gaW4gdGhlIGJ1ZmZlciB3aGVuDQorCQkJCSAqIHRoZSByZW1vdGUgZmlsZSBh bHJlYWR5IGhhcyB3aW5kb3plIHN0eWxlIGxpbmUgZW5kaW5ncy4NCisJCQkJICogTm93IEkgdW5k ZXJzdGFuZCAiMjIwIEFTQ0lJIHRhc3RlcyBiYWQsIGR1ZGUiDQorCQkJCSAqLw0KKw0KKwkJCQlw aHBfc3RyZWFtX3dyaXRlKG91dHN0cmVhbSwgcHRyLCAocyAtIHB0cikpOw0KKwkJCQlwaHBfc3Ry ZWFtX3B1dGMob3V0c3RyZWFtLCAnXHInKTsNCisJCQkJcGhwX3N0cmVhbV9wdXRjKG91dHN0cmVh bSwgJ1xuJyk7DQorCQkJCWlmICgqcyA9PSAnXHInICYmICoocyArIDEpID09ICdccicgJiYgKihz ICsgMikgPT0gJ1xuJykgew0KKwkJCQkJcyArPSAzOw0KIAkJCQl9IGVsc2UgaWYgKCpzID09ICdc cicgJiYgKihzICsgMSkgPT0gJ1xuJykgew0KKwkJCQkJcyArPSAyOw0KKwkJCQl9IGVsc2UgaWYg KCpzID09ICdccicpIHsgDQorCQkJCQlzKys7DQorCQkJCX0gZWxzZSBpZiAoKnMgPT0gJ1xuJykg ew0KIAkJCQkJcysrOw0KLQkJCQl9DQotCQkJCXMrKzsNCi0JCQkJcGhwX3N0cmVhbV93cml0ZShv dXRzdHJlYW0sIHB0ciwgKHMgLSBwdHIpKTsNCi0JCQkJaWYgKCoocyAtIDEpID09ICdccicpIHsN Ci0JCQkJCXBocF9zdHJlYW1fcHV0YyhvdXRzdHJlYW0sICdcbicpOw0KIAkJCQl9DQogCQkJCXB0 ciA9IHM7DQogCQkJfQ0K ------_=_NextPart_001_01C4DF0C.7F060037--