duplicity-talk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Duplicity-talk] [ ftplicity-Bugs-2684345 ] Traceback with duplicity


From: Kenneth Loafman
Subject: Re: [Duplicity-talk] [ ftplicity-Bugs-2684345 ] Traceback with duplicity 0.5.06-2~bpo40+1]
Date: Thu, 12 Mar 2009 12:26:04 -0500
User-agent: Thunderbird 2.0.0.19 (X11/20090105)

I don't need to re-implement it... ncftpput is not used anymore, so no
need to check for it.  As far as I know, ncftp itself never had this
problem, just the utility.

...Ken

address@hidden wrote:
> I see .. exactly the versions I missed ;) .. so your going to implement
> it again?
> What about a nice error message explaining the matter?
> 
> ..ede
> -- 
>> The check is only in 0.5.06, .07, .08, it was taken out in 0.5.09 when I
>> changed to using ncftp directly, rather than ncftpput/get/ls.  The check
>> was only intended to protect against ncftpput 3.2.0, but they all come
>> as a group, so it affects all of the group.
>>
>> We're up to .11, with .12 coming out next week or so.
>>
>> ...Ken
>>
>> address@hidden wrote:
>>  
>>> it says
>>>
>>> NcFTPLs 3.2.0
>>>
>>> maybe a letter case difference?
>>>
>>> ..ede
>>>
>>>    
>>>> 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
>>>>>
>>>>>             
>>>>  
>>>> ------------------------------------------------------------------------
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
> 


Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]