I can condone that course of action. Go ahead and commit it. I'd make a not of it in the documentation so that somebody doesn't get seriously bitten by it.
> -----Original Message----- > From: Vlad Krupin [mailto:[EMAIL PROTECTED]] > Sent: Monday, March 18, 2002 5:08 PM > To: [EMAIL PROTECTED] > Cc: Joseph Tate; PHP Developers Mailing List > Subject: Re: [PHP-DEV] FTP returns wrong file size (and a fix) - second > try > > > If someone needs an ASCII size, they need to scream and file a bug > report and then I'll implement it. This function has not been working > properly for ages and no-one complained. This way at least it will work > consistently and make sense. Optional ASCII mode size will require a > bloat (like an optional parameter) :(. > > Vlad > > > > [EMAIL PROTECTED] wrote: > > >On Mon, 18 Mar 2002, Joseph Tate wrote: > > > >>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. > >> > > > >That sounds like a good idea to me. I can't think of a way why > it would be > >useful, but it doesn't hurt either. I'd go for the ftp_size() > with default > >BINARY, and optional ASCII mode size. (And it's fine with me to merge it) > > > >regards, > >Derick > > > >>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: Scripting the Web - [EMAIL PROTECTED] > > All your branches are belong to me! > > SRM: Script Running Machine - www.vl-srm.net > >----------------------------------------------------------------------- > > > > > > > -- > 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
