[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[rdiff-backup-users] Character set still problematic?

From: Matt Van Mater
Subject: [rdiff-backup-users] Character set still problematic?
Date: Sun, 16 Oct 2011 12:58:41 -0400

Hi all,

I have the following setup:

Local Ubuntu Server 10.4.3 (mounted CIFS share from Local Win 2008 file server) --> Remote Ubuntu Server 10.4.3 (mounted Truecrypt partion).

Among the files being backed up are my wife's music files, and I am running into continual problems with rdiff-backup not liking the character set (e.g. it dies when trying to transfer a song by Beyonce, where the last e in her name has an accent mark).  I have been renaming the files one by one as i find them with non-specialized characters, but this is a pain and is not a very robust solution for the future.  It really stinks to be a few hundred GB into a transfer and for the operation to fail completely.

I have reach the mailing list archives and see many people post about this issue, but with few resolutions.  I wanted to share my thoughts and see where everyone else is at.

  1. My interim fix that I am going to try is a regex to identify valid characters and use rdiff-backup's regex precedence rules to exclude the _inverse_ of that list, effectively excluding all the funky non-ascii chars without having to list all the exclusion characters explicitly.  Unfortunately my python skills are weak (comments / suggestions are welcome!).
    1.   --include-regexp '[0-9a-zA-Z-_\.\(\)]+' --exclude-regexp '[.]+'
  2. I think a "quick fix" would be to enable rdiff-backup to simply ignore+log any files that have an incompatible character set, permitting it to move on to the other files that meet the naming requirements.
  3. A better long term fix would be to support multiple charsets or locales... I have seen this suggested multiple times but it was never resolved.  Is this a technical issue or a time/resources one?
Thoughts, comments?

reply via email to

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