rdiff-backup-users
[Top][All Lists]
Advanced

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

Re: [rdiff-backup-users] Feature Suggestions for Cross-Platform-Compatib


From: Andrew Ferguson
Subject: Re: [rdiff-backup-users] Feature Suggestions for Cross-Platform-Compatibility
Date: Fri, 10 Oct 2008 11:14:37 -0400

On Oct 10, 2008, at 8:24 AM, Toscano2 wrote:
- the appended timestamps (e.g. 'current_mirror. 2008-10-07T16:43:00-07:00.data') are not compatible with Windows. It's impossible to simply copy over/rsync on an ext3- filesystem locally rdiff-backupped data later to a Windows system without breaking the backups. (Directly using rdiff-backup between local Windows and remote Linux system cannot be used.)

- If you use rdiff-backup on both sides, then this problem won't be there. Rdiff-backup is now well-tested for avoiding reserved Windows characters (and other reserved Windows names). - You could also add : to the chars-to-quote yourself (and, presumably, the other DOS reserved characters) - You could write a patch for rsync which translates reserved Windows characters and names.

So there should be an alternative commandline option (e.g. '--use- windows-compatible-timestamps' or just '--use-compatible- timestamps') which generates the timestamp without ':'/colons, e.g.: '2007-07-28T10-51-18', since the W3-time/datestamps are not meant for being used in filenames.

Patches fully compatible with existing rdiff-backup usage are welcome.

- the timezone could be left out, if by convention, rdiff-backup would
use/convert to UTC before writing timestamps to files, e.g. '--use- utc' to maintain backward compatibility).So problems with daylight saving time and managing servers across different timezones are resolved.

I believe you can override this by adjusting the TZ variable for just the rdiff-backup process. e.g.,

TZ=UTC rdiff-backup ....

Let me know if that doesn't work (and you are using Python 2.3 or later), as it would be a bug in rdiff-backup.

- an option like '--preserve-case' to explicitely override auto- detected settings if any case-insensitive filesystem is used (NOT via '--override-chars-to-quote').

What's wrong with --override-chars-to-quote ? Really, I don't understand why people want to do this on case-insensitive filesystems -- I view dataloss as infinitely more drastic than cosmetic issues with filenames. rdiff-backup reverses the translation during a restore.

The last two ideas would keep filenames smaller, in many cases prevent filepaths from violating length-constraints.

On Unix, rdiff-backup has proper support for handling too-long filenames. I see there was an email recently about this not working on Windows, a bug I'll try to look into after the next release.

- finally, something as '--override-chars-to-quote-from-file' would be useful, so any non-printable characters/ranges can be specified here, too. This would ease creating a single compatibility-file for e.g. easy Windows-Linux-Mac migration, similar to the '--include-from-file' options.

--override-chars-to-quote is a regular expression, so you can put non- printable characters in by escaping them (octal) ... eg:

--override-chars-to-quote "\000-\037"

will make sure that ASCII characters 0 - 31 are escaped. If you write a wrapper script to rdiff-backup, you can put in non-printable characters directly.

I would certainly consider a patch to add an --override-chars-to-quote- from-file option, and it might be a good first patch for someone new to Python or the rdiff-backup code. The get_ctq_from_fsas() function in fs_abilities.py shows how rdiff-backup figures out which chars should be quoted.



Andrew






reply via email to

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