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

[Kenneth Loafman]

That was fixed in v0.5.07, so maybe you're running an earlier version?
If not, then what does the first line of 'ncftpls -v' say?

You do the safe thing, verify everything.  Most folks do not.

...Ken

address@hidden wrote:
> Sorry to be persistent on it ... finally it is your decision.
> 
> Just to be clear. Because at some point in time ncftp 3.2.0 segfaulted,
> this gives a hint that it was badly programmed and every data from it
> might get corrupted without somebody noticing it?
> Again mine is also 3.2.0 so why is it not banned? Ok I know that
> everything is fione because I verify every backup. But still. Shouldn't
> it be banned?
> 
> ..ede
> 
>> Short answer, yes, sort of.  It won't harm the system, but it may harm
>> the program, or the data it generates.
>>
>> A segfault is an errant memory read/write to memory outside the program
>> itself, i.e. it tries to read/write to a system area, or into another
>> program.  If this errant read/write is to a legitimate location inside
>> the program itself, you can get stack or data corruption, which is very
>> hard to find, and annoying.
>>
>> This location can change when, for example, the compiler is different or
>> even when the compile options are different.  Different distro's use
>> different versions of the compiler, sometimes change the options that
>> the author used, gen for 32-bit and 64-bit, any number of changes can
>> move the target address, and move the problem.
>>
>> If I know that I have a program that may segfault in one environment,
>> then I know that I have a program that may corrupt data in another
>> environment.  Its best not to trust to luck in an application that
>> serves a backup program.
>>
>> That said, I take back what I wrote earlier (entirely too much blood in
>> my caffeine stream).  The check should stay in for that particular
>> version, and it is better to ask the user to upgrade.
>>
>> ...Ken
>>
>> address@hidden wrote:
>>  
>>> Do I understand correctly that a segfault might compromise the systems
>>> stability or affect other programs running on the same machine? In that
>>> case I totally agree with you ...
>>>
>>> ..ede
>>> -- 
>>>    
>>>> 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
>>>>>
>>>>>             
>>>>  
>>>> ------------------------------------------------------------------------
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>>     
>>
>>
>>  
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> 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