[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[rdiff-backup-users] Proposal to fix long filenames
From: |
Ben Escoto |
Subject: |
[rdiff-backup-users] Proposal to fix long filenames |
Date: |
Sat, 12 Nov 2005 00:22:08 -0600 |
Time to fix rdiff-backup's oldest bug? In this message I'll describe
the problem and one way to fix it.
The problem:
rdiff-backup has a problem with long filenames. For instance,
rdiff-backup may not be able to backup a file whose name has 250
characters in it, when the maximum allowable filename is 255
characters.
There are three different ways I can see this happening:
1) A source file's length is close to the maximum and additional
suffix pushes it over the limit. For instance, <long filename>
has a length of 250. The mirror file is created successfully, but
increments can be, for instance, <long
filename>.2005-11-11T23:59:49-06:00.snapshot.gz which is 288
filename>characters long.
I think this is the most common case.
2) A source file's length is close to the maximum, and quoting takes
it over the edge. In this case, both the mirror and the increment
files are too long to write.
3) The source filesystem supports longer filenames than the
destination. In this case the mirror file may be too long to
write even without any quoting. I've never heard of this actually
happening.
One way to fix it:
The mirror_metadata file could have two additional optional fields,
called "MirrorFilename" and "IncrementFilename". If MirrorFilename is
set, rdiff-backup reads the mirror file from the
rdiff-backup-data/long_filename_data/<mirror filename> file, instead
of from the normal location in the mirror directory.
Similarly, if IncrementFilename is set, increment data will not be
read from rdiff-backup-data/increments/<whatever>.<suffix> but from
rdiff-backup-data/long_filename_data/<increment filename>.<suffix>
The alternate filenames would have boring but plentiful names like
1, 2, etc.
When backing up, rdiff-backup could examine the length of each file
before it writes it to the repository, and figure out if the mirror
and increments would be too long, and write the data in the
appropriate location, setting those optional fields if necessary.
Drawback:
Originally I thought that the fix for long filenames might somehow be
integrated into a scheme to detect and compress renamed files. But
now I doubt any renaming scheme is forthcoming.
So, any comments? Anyone see any other drawbacks/problems?
--
Ben Escoto
pgpcGZ4oPkYpr.pgp
Description: PGP signature