Re: [Duplicity-talk] new ftp backend

[dAniel hAhler]

Hi,

ncftp seems like a good idea given the previous, "grown" version.

Although it means that all the ftpBackend hacking I've done is "lost",
I'm in favor of this patch.

It has not caused any trouble with my regular backup process yet.

Please consider using ftpBackend.run_command_persist, instead of just
run_command.
It currently retries 3 times, and may be improved in the future to
behave more like the retry process in the previous ftpBackend.

Also, really important: please change it so that is does not use the
account data (login and password) as arguments for a process. It's
possible to see such things from a "normal" shell account (AFAIK) and
therefor I consider this a real bad issue. It should get changed to
write the login+password to a protected file and use this instead.

Given the quite radical change, I would rather say this is not so good
in the late RC phase, but it's a huge cleanup and if the issues above
can get resolved, it may be fine already.

On 7/4/07, Nicolas Aspert <address@hidden> wrote:
> Hi
>
> Kenneth Loafman wrote:
> > Thanks for the work.  I've been thinking of going this route for a while
> > and a recent attempt at fixing Python's ftplib via patch submission just
> > sealed the deal.  The folks at ncftp at least realize that not all FTP
> > servers are RFC compliant and make amends for that.  The goal is a
> > working backup, not enforcing RFC compliance on everyone.
> >
> > Since ncftp is supported on both Windows and Linux, I have no problems
> > with adopting it for our use.  I've used ncftp for years and have yet to
> > find a server it fails to work on.
> >
> > I'll do a bit of testing myself, then get this into RC9, probably by the
> > end of the week.
> >
>
> I am also quite in favor of this solution ! The ncftp backend is much
> simpler to understand (and I must say ncftp has always worked like a charm)
>
> I won't be able to test this within 2 weeks from now, but I'll
> definitely want to look at this one !