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: edgar . soldin
Subject: Re: [Duplicity-talk] [ ftplicity-Bugs-2684345 ] Traceback with duplicity 0.5.06-2~bpo40+1]
Date: Thu, 12 Mar 2009 15:06:14 +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

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





reply via email to

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