PHP Bug# 27633 Patch
| From: | Binam, Jesse | Date: | Fri, 10 Dec 2004 23:06:33 +0000 |
| Subject: | PHP Bug# 27633 Patch | ||
| Groups: | php.internals | ||
| Request: | Send a blank email to internals+get-14042@lists.php.net to get a copy of this message | ||
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. ;)
--- ftp.c.bak Wed Dec 8 09:27:45 2004 +++ ftp.c Fri Dec 10 15:35:03 2004 @@ -846,16 +846,25 @@ * Everything Else \n */ #ifdef PHP_WIN32 - while ((s = strpbrk(ptr, "\r\n"))) { - if (*s == '\n') { - php_stream_putc(outstream, '\r'); + while ((s = strpbrk(ptr, "\r\n")) && (s < e)) { + + /* for some reason some servers prefix a \r before a \n, + * resulting in a \r\r\n in the buffer when + * the remote file already has windoze style line endings. + * Now I understand "220 ASCII tastes bad, dude" + */ + + php_stream_write(outstream, ptr, (s - ptr)); + php_stream_putc(outstream, '\r'); + php_stream_putc(outstream, '\n'); + if (*s == '\r' && *(s + 1) == '\r' && *(s + 2) == '\n') { + s += 3; } else if (*s == '\r' && *(s + 1) == '\n') { + s += 2; + } else if (*s == '\r') { + s++; + } else if (*s == '\n') { s++; - } - s++; - php_stream_write(outstream, ptr, (s - ptr)); - if (*(s - 1) == '\r') { - php_stream_putc(outstream, '\n'); } ptr = s; }
--- ftp.c.bak Wed Dec 8 09:27:45 2004 +++ ftp.c Fri Dec 10 15:35:03 2004 @@ -846,16 +846,25 @@ * Everything Else \n */ #ifdef PHP_WIN32 - while ((s = strpbrk(ptr, "\r\n"))) { - if (*s == '\n') { - php_stream_putc(outstream, '\r'); + while ((s = strpbrk(ptr, "\r\n")) && (s < e)) { + + /* for some reason some servers prefix a \r before a \n, + * resulting in a \r\r\n in the buffer when + * the remote file already has windoze style line endings. + * Now I understand "220 ASCII tastes bad, dude" + */ + + php_stream_write(outstream, ptr, (s - ptr)); + php_stream_putc(outstream, '\r'); + php_stream_putc(outstream, '\n'); + if (*s == '\r' && *(s + 1) == '\r' && *(s + 2) == '\n') { + s += 3; } else if (*s == '\r' && *(s + 1) == '\n') { + s += 2; + } else if (*s == '\r') { + s++; + } else if (*s == '\n') { s++; - } - s++; - php_stream_write(outstream, ptr, (s - ptr)); - if (*(s - 1) == '\r') { - php_stream_putc(outstream, '\n'); } ptr = s; }