[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [rdiff-backup-users] Proposal to fix long filenames
From: |
Sheldon Hearn |
Subject: |
Re: [rdiff-backup-users] Proposal to fix long filenames |
Date: |
Sat, 12 Nov 2005 12:02:45 +0200 |
User-agent: |
KMail/1.8.3 |
On Saturday 12 November 2005 08:22, Ben Escoto wrote:
> So, any comments? Anyone see any other drawbacks/problems?
I think this is another edge case that speaks to the value of entirely
virtualizing the backup store. In other words, don't rely AT ALL on
the capabilities of the filesystem used to store backups, except for
those capabilities common to all documented as being supported for
rdiff-backup servers. In real terms, this leaves you with pretty short
names and just about nothing else.
Instead, use the backup store's filesystem only to store the data
associated with backed up objects (files, directories and links), and
use metadata to express all other attributes of those objects.
At the extreme, every object gets a serial number which is used as its
name in the backup store's filesystem. That serial number is used to
index into the metadata store, to discover the properties of the object
as it should be restored, including ownership, permissions, extended
attributes, NTFS permissions, creation, modification and access times
and checksums.
Directories can be virtualized in the same way.
This addresses more than just long filenames. It also addresses my
"Write-once read-many problem" issue, as well as the issue of
rdiff-backup losing permissions when backing up from NTFS to UFS and
then restoring back to NTFS.
It sidesteps an entire family of problems that arises out of what I
consider to be a design limitation -- rdiff-backup does not seem to
have been originally designed to be as cross-platform a utility as
people would now like it to be.
This is one of the challenges that successful software inevitably
faces. :-)
Ciao,
Sheldon.
pgpkaWd6h41_U.pgp
Description: PGP signature