|
From: | edgar . soldin |
Subject: | Re: [Duplicity-talk] [ ftplicity-Bugs-2684345 ] Traceback with duplicity 0.5.06-2~bpo40+1] |
Date: | Thu, 12 Mar 2009 18:23:26 +0100 |
User-agent: | Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.19) Gecko/20081209 Thunderbird/2.0.0.19 Mnenhy/0.7.5.0 |
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? ..edeThat 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? ..edeShort 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 ..edeBack 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
[Prev in Thread] | Current Thread | [Next in Thread] |