Would there ever be a need to get the ASCII ftp_size? If not, the go ahead, but if there ever might be, you may want to add a parameter to ftp_size so that it behaves like ftp_get et all. The parameter could default to BINARY.
Joseph > -----Original Message----- > From: Vlad Krupin [mailto:[EMAIL PROTECTED]] > Sent: Monday, March 18, 2002 4:15 PM > To: PHP Developers Mailing List > Cc: [EMAIL PROTECTED] > Subject: [PHP-DEV] FTP returns wrong file size (and a fix) - second try > > > Hi, this is the second try to get feedback and to make a fix to > ftp_size() function. > After bringing that issue up a few days back, I got response from Derick > only with some concerns, which I'll address here. > Please, respond or I'll just apply the patch because it makes sense to > me and see what happens. > > > First of all, ftp_size() function is broken. It will return different > results for the same file depending on what function was called before > it. To fix it, we have to set the mode of the ftp server session to > BINARY rather than ASCII. It is a one-liner patch. > > Derick was concerned that this will change the state of the session > without the user explicitly requesting it and we do not restore it. > However, this is irrelevant since all the functions that depend on that > state will set it for themselves: > - ftp_nlist() and ftp_rawlist() already do just that - they just set the > type to ASCII and do not restore it. > - ftp_get(), ftp_fget(), ftp_put() and ftp_fput() require you to set the > type explicitly > - other functions do not depend on transfer type (except for ftp_size() ). > > It was an obvious oversight not to make ftp_size() set the mode before > requesting the size of a file (I would have never imagined that the size > of the file differs depending on whether we do 'dir' in text mode or > binary mode... duh!) > > So, to wrap it up. Making that change will not affect *any* other > functionality of the ftp extension (you are welcome to read through the > source - I just did that) and will fix ftp_size() to consistently return > correct results. > > Question: Does anybody object to putting that change in, *and* also > merging it into the release branch? This is an obvious bug, and the fix > doesn't affect anything else. > > Vlad > > > > > -- > PHP Development Mailing List <http://www.php.net/> > To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
