Re: [Duplicity-talk] 0.4.3-rc11 failure on FTP

[Kenneth Loafman]

Nicolas Aspert wrote:
> Hello
> 
> On 8/4/07, Kenneth Loafman <address@hidden> wrote:
>> It turns out there's an easy fix to that, use the -l option.
>>
>>   ncftpls -F -t 30 -u srvbck -l ftp://192.168.1.10/array1/homebck0/
>>
>> gives a long listing.  I just need to parse the list returned, but
>> that's not too bad as long as everyone's compatible.  The best answer
>> may be to use the -l option first, if we get anything back then do the
>> default -1 option to get the list, thereby ignoring ls differences.
>>
>> I'll put a note into Mike to see if there's a better way.  This has
>> become a real nuisance for all.
>>
> 
> That's okay I just got around this one by creating a dummy file.
> However, the ncftp backend suffers from a MAJOR problem I recently 
> experienced.
> While a full backup took about 11h, it now need 25 hours to
> complete... I am now considering to revert to the old ftp backend
> unless this one is improved (maybe using the spooling possibilities of
> ncftp ?)

That's the normal workaround.  I think I need to add a mechanism to the
backend class that will create the initial directory automatically.
This problem hits at least the ssh, ftp, and file backends.

As to the slowdown... I've tested on my own systems, mostly Linux to
Linux, but one Linux to Windows and have seen a small slowdown of maybe
5-10%.  That would not be a problem considering the wide range of ftp
servers that ncftp will talk to.  I'd like to know what your source and
target systems are and if you have any insight into what may be the
problem and why one would work better than the other.

...Ken


...Ken

signature.asc
Description: OpenPGP digital signature