Hi Craig,
I just tried a backup with:
$Conf{ClientCharset} = '';
But now instead of the previous error:
[sender] cannot convert filename: user1/docs/r\#351ponse.doc (Invalid or
incomplete multibyte or wide character)
I now get the (familiar?) error:
rsync_bpc: fstat "user1/docs/r\#351ponse.doc" failed: No such file or
directory (2)
I suspect this is due to the same/similar bug I have been chasing down with
you regarding the handling of deleted (or spuriously deleted) files.
Indeed, attribPrint shows:
$VAR1 = {
'r�ponse.doc' => {
'compress' => 3,
'digest' => '',
'gid' => 0,
'inode' => 0,
'mode' => 0,
'mtime' => 0,
'name' => 'r�ponse.doc',
'nlinks' => 0,
'size' => 0,
'type' => 10,
'uid' => 0
} }
};
Craig Barratt wrote at about 21:43:38 -0700 on Monday, June 24, 2019:
> Jeff,
>
> I suspect you'll get the same error if you use native rsync and tell it to
> convert utf8 to utf8 (eg, add '--iconv=utf8,utf8' to your native rsync
> command).
>
> Since you don't need any conversion, you should set $Conf{ClientCharset} to
> an empty string. That should cause rsync to no longer attempt any charset
> conversion.
>
> Craig
>
> On Sun, Jun 23, 2019 at 6:13 PM <[email protected]> wrote:
>
> > Craig Barratt via BackupPC-users wrote at about 13:59:46 -0700 on Sunday,
> > June 23, 2019:
> > > The error you are getting is when rsync_bpc is trying to use iconv to
> > > convert the client file name encoding to utf8 (which is the native
> > format
> > > that BackupPC on the server).
> > >
> > > What is $Conf{ClientCharset} set to for this host? If it is empty then
> > > rsync_bpc should skip any charset conversion, so I assume it's not
> > > empty.
> > I have it set to UTF-8
> > In my notes I have that this should be set to the output of the
> > command 'locale charmap' which is UTF-8 on Ubuntu 18.04 -- but I
> > can't remember where/why I determined that.
> >
> > > Next, it would appear that 'r'$'\351''ponse.doc' is not a valid encoded
> > > name in that Charset.
> >
> > Well, when I type 'ls' on the server, it shows the file as:
> > -rwx------ 1 user1 user1 28672 May 11 2005 'r'$'\351''ponse.doc'
> >
> > Indeed when I run:
> > echo 'r'$'\351''ponse.doc' | iconv -f UTF-8 -t UTF-8
> > I get:
> > riconv: illegal input sequence at position 1
> > Not sure why this happens if I have UTF-8 as my 'locale charmap'
> >
> > Even so, shouldn't backuppc treat such an error more gracefully.
> > For example,
> > - If iconv gives an error, try without charset conversion (like
> > BackupPC 3.x)
> >
> > At least this would be better than the current setup where lack of
> > charset conversion causes the file to fail to be backed up at all -
> > which in many ways is the worst thing possible...
> >
> > >
> > > In BackupPC 3.x, the xfer methods didn't support any charset conversion
> > > (you could, for example, have smbclient do it instead).
> > >
> > > Craig
> > >
> > > On Sat, Jun 15, 2019 at 8:56 PM <[email protected]> wrote:
> > >
> > > > Michael Stowe wrote at about 03:35:13 +0000 on Sunday, June 16, 2019:
> > > > > On 2019-06-15 19:20, [email protected] wrote:
> > > > > > I am running backuppc 4.3.0 on Linux Ubuntu 18.04
> > > > > >
> > > > > > I have a file copied over from an old Windows installation to my
> > Linux
> > > > > > server with name:
> > > > > >
> > > > > > -rwx------ 1 user1 user1 28672 May 11 2005
> > 'r'$'\351''ponse.doc'
> > > > > >
> > > > > > This file gives an error under backuppc as follows:
> > > > > > [sender] cannot convert filename:
> > > > > > user1/docs/r\#351ponse.doc (Invalid or incomplete multibyte
> > or
> > > > > > wide character)
> > > > > >
> > > > > > Note that rsync itself has no trouble copying this file when I
> > run
> > > > > > rsync manually.
> > > > > >
> > > > > > Also, interestingly, this same file backed up fine on my old
> > Fedora
> > > > 12
> > > > > > server
> > > > > > running backuppc 3.x.
> > > > > >
> > > > > > Any ideas why backuppc is having trouble with this file?
> > > > >
> > > > > Almost definitely because the encoding is invalid relative to the
> > > > > locale. The simplest thing to do is to rename the file so that
> > it's a
> > > > > valid filename.
> > > >
> > > > I could do that of course, but i would like to "fix" it if possible.
> > > > If the native filesystem and 'rsync' are both able to deal with the
> > > > file, it seems to me that backuppc should also be able to deal with
> > > > it.
> > > >
> > > > Backup should be maximally tolerant so as to duplicate the files as
> > > > permissively as possible...
> > > >
> > > >
> > > > _______________________________________________
> > > > BackupPC-users mailing list
> > > > [email protected]
> > > > List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
> > > > Wiki: http://backuppc.wiki.sourceforge.net
> > > > Project: http://backuppc.sourceforge.net/
> > > >
> > > _______________________________________________
> > > BackupPC-users mailing list
> > > [email protected]
> > > List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
> > > Wiki: http://backuppc.wiki.sourceforge.net
> > > Project: http://backuppc.sourceforge.net/
> >
_______________________________________________
BackupPC-users mailing list
[email protected]
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/
