On 26 January 2012 14:59, Les Mikesell
<lesmikesell AT gmail DOT com> wrote:
On Thu, Jan 26, 2012 at 10:57 AM, Michael Stepner
<
michaelstepner AT gmail DOT com> wrote:
>
>> I haven't used the ftp module so I can't help much, but is that LIST
>> command actually sending any filenames?
>
>
> I don't know how to check for certain, but the with gFTP I certainly get a
> file listing, and the log shows:
>
>>> (000090)26/01/2012 0:49:34 AM - backup (xxx.xxx.xxx.xxx)> LIST -aL
>>> (000090)26/01/2012 0:49:34 AM - backup (xxx.xxx.xxx.xxx)> 150 Connection
>>> accepted
>>> (000090)26/01/2012 0:49:34 AM - backup (xxx.xxx.xxx.xxx)> 226 Transfer OK
LIST, and 'ls -a' should show hidden files. Alternatively, you could
use wireshark to observe the network activity on either the linux or
windows side.
I used the command line ftp program on my desktop, which the man page indicates is supplied by gFTP (see my next statements for more details). It behaves exactly as the GTK GUI version does: when I log in, it automatically sends SYST and the server responds "215 UNIX emulated by FileZilla". And when I send ls or ls -a, the server responds with LIST -aL.
When I tried to run the command line ftp program on my server, I realized I didn't have one.
I considered that that may be the problem, but I doubted it, since BackupPC must be using its own mechanism for making FTP connections, without relying on an external program. The server is seeing a connection, after all, and I note that in its Debian/Ubuntu packages, there is no ftp-related dependency or suggested/recommended package. But I decided to try installing gFTP's console client on the server anyway. I did, it behaves the same way as it does on my desktop when connecting to the FTP server, and installing it did not solve my issues with BackupPC.
> BackupPC might not be getting a file listing, and it shows:
>
>>> (000089)26/01/2012 0:45:13 AM - backup (xxx.xxx.xxx.xxx)> LIST
>>> (000089)26/01/2012 0:45:13 AM - backup (xxx.xxx.xxx.xxx)> 150 Connection
>>> accepted
>>> (000089)26/01/2012 0:45:13 AM - backup (xxx.xxx.xxx.xxx)> 226 Transfer OK
>
> Although, as I said in a previous post, I speculate that that could be due
> to the lack of BackupPC sending a "SYST" command, which gFTP did:
>>> (000090)26/01/2012 0:49:33 AM - backup (xxx.xxx.xxx.xxx)> SYST
>>> (000090)26/01/2012 0:49:33 AM - backup (xxx.xxx.xxx.xxx)> 215 UNIX
>>> emulated by FileZilla
SYST is just a request for the OS version name - it should not change
subsequent behavior.
man ftp and man ftpd on the linux system should give the details of
commands and expected responses.
You're right, I looked it up, and SYST shouldn't be changing subsequent behaviour. This difference in the logs is immaterial.
>> Since you are installing a 3rd party service on the client for the
>> transfer anyway, why not use cwrRsync which is known to work and
>> probably more efficient?
>
>
> A fair point. I already have an FTP server running on the clients for
> services apart from backups, so the decision is whether or not to install a
> second 3rd party service. I'm probably willing to do that, although I'd
> prefer to use the existing FTP server.
You'll probably get more correct incremental backups with rsync
(deletions and changes with old timestamps tracked) and if you have
low bandwidth connections, fulls will be much more efficient.
So, I'm stumped by this bug. It might be client side: gFTP works fine in fetching a directory listing and files from the server, but BackupPC does not. It could also be server side: perhaps FileZilla has some non-standard behaviour (as you said), and perhaps gFTP is able to adapt to it whereas BackupPC is not.
As you suggest, I'm going to give up and switch to rsync. I don't really want to spend more time investigating this, and even if I did, I wouldn't know what to do next. I hope this conversation is useful if someone else encounters a similar issue in the future. I know that when I googled the error message I had in my BackupPC logs, I found nothing.
A final note about my switch to rsync, for any future readers:
> Moreover, that might not be an option for all users. I do think this bug is
> worth sorting out.
I think you'll have to sort out whether it is filezilla doing
something non-standard or a backuppc bug, though.
Thank you for your help, Les.
Michael
