Re: [Duplicity-talk] [ ftplicity-Bugs-2684345 ] Traceback with duplicity 0.5.06-2~bpo40+1]

[Kenneth Loafman]

Not sure that A was the right choice, but we're past that now.  It's
easily removed if you just remove the check in ftpbackend.py, so maybe a
patch could be issued to remove the check, or maybe just issue a warning
instead.

I tend to err towards caution in handling errors.  A segfault may not be
generated if the memory modified is not executed, but could produce bad
data output instead, so unless I know the version has been fixed, and
not just compiled differently, I would not really trust it.

...Ken

address@hidden wrote:
> Thanks for this overview ... very interesting in every detail indeed ....
> 
> Regarding your comments ...
> 
> A) If ncftp 3.2.0 raises an error, but not always, why blocking by
> version and not by issuing the segfault or whatever error? E.g. in the
> case of the ftplicity user from the bug list... He used
> ftplicity/duplicity happily until now the new version refuses to work
> with a obviously working ncftp version.
> 
> B) You explained that a version string is compared, so the question on
> put with list-files is obsolete :)
> 
> Eventually, I agree totally ... Dogmatic Rules are for people that
> refuse development. Usually they don't last long .... Said that, why
> force somebody to upgrade, if there is only a chance of an error
> occuring but no certainty. This is like trying to keep children from
> danger. Impossible ;)
> 
> ... ede
> 
> PS: I really love the phrase of your french teacher :))
> 
> 
> Kenneth Loafman wrote:
>> address@hidden wrote:
>>  
>>>> I have a suspicion there may be differences in the distro's, some with
>>>> bug fixes, some not.
>>>>         
>>> How does duplicity detect the faulty version? Or does it detect the
>>> fault itself?
>>>     
>>
>> The fault itself would be a segfault, so no, we don't do that.  It runs
>> the ncftp command and looks for the version string.  Simplicity.
>>
>>  
>>> But then, why does the list command issue a ftp put command?
>>>     
>>
>> You'll have to explain that one.  It should not.
>>
>>  
>>> ..qeustions over questions ..ede
>>>     
>>
>> Back in the dawn of history, duplicity used ftplib.py for direct access
>> to ftp.  This was impossible to maintain because the maintainers of
>> ftplib.py preferred standardization over functionality.  They treated
>> the RFC's as gospel and anyone who's been around ftp long enough grows
>> to know that ftp servers are only 'mostly' standard.  I chose NcFTP
>> because I had never had it fail to work on any server I targeted.  I
>> chose functionality over standardization.  A note - do a 'strings' on
>> NcFTP and you will find where they detect the problem FTP servers and
>> this is something any ftp client needs to do.
>>
>> The 2nd incarnation of the ftp backend used the ncftpget/put/ls
>> utilities rather than the ncftp command directly.  After much success
>> with pexpect driving ssh, and many problems with various versions of the
>> ncftp utilities, I decided to drive ncftp directly with pexpect and not
>> use the utilities for anything at all.  I made the mistake of thinking
>> that if ncftp was so solid, then the utilities would be solid as well.
>>
>> Thus the 3rd incarnation of the ftp backend.  This one still has some
>> issues, I'm sure, but those are being ironed out.  Unless someone can
>> prove to me that they have a better functioning ftp server or library, I
>> think we have finally found the functionality and robustness we need
>> going forwards.
>>
>> I'm getting really tired of fixing bugs against a flaky protocol that
>> should have died years ago.  It wastes too much time.  It's one of those
>> things like French that I don't like to mess with.  As my French teacher
>> said on the day after it was too late to drop, "Throw away the rules,
>> now we're going to learn French.".  FTP is like that.
>>
>> ...Ken
>>
>>
>>  
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Duplicity-talk mailing list
>> address@hidden
>> http://lists.nongnu.org/mailman/listinfo/duplicity-talk
>>   
> 
> 
> 
> _______________________________________________
> Duplicity-talk mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/duplicity-talk
>

signature.asc
Description: OpenPGP digital signature