This series has expanded yet again, but I hope I'm now done with
it. I'd really like to get it reviewed this time around. I've
sent out a test for xfstests to verify it this time around...
The main change this time is that I've rearranged the way duplicate
names are handled once they have been obfuscated. There is a chance
that the result of an obfuscation would be a name that already had
been stored in the names table. It used to be in that case another
obfuscation attempt was made, but due to limitations in the
algorithm there was a small possibility that no alternative would
be available. In that case, a duplicate name would be produced
in the metadump file; the duplicates would show up in the
reincarnated filesystem produced by xfs_mdrestore, and would be
identified as problems by xfs_repair.
So there are a few new patches that address this, with some of
them just preparatory work in support of the one that contains
the real changes.
Since the last time it got posted, these changes have been made:
- I've gone over various descriptions in the patches and in the
comments in the code, and have refined them in hopes it will
make the whole thing a lot clearer. Some of this stuff is
hard to describe.
- Fixed a problem with treatment of the "lost+found" directory
that cropped up in the last posting.
- Dropped a change that fixed a compile warning.
- Parts of the code have been rearranged, separating the obfuscation
step from the process of identifying an alternate name if a
duplicate is found.
- Alternate names are now generated using a methodical process that
will produce a large number of possibilities, many more than were
allowed before. This should avoid ever running into the case
where duplicates ever wind up in a metadump file.
Below is some of the text I sent last time I posted this series.
My original purpose was to fix a bug in the function used by
xfs_metadump to obfuscate file and extended attribute names.
Arkadiusz Miśkiewicz found out that when he attempted to perform a
metadump on a filesystem which had some files whose names used 8-bit
characters, it never completed. The cause was a flaw in the
algorithm used to obfuscate names which caused an infinite loop when
certain names got obfuscated.
I have fixed that bug (in patch 4 of this series), but while I was
at it I rearranged the code a bit and did some other cleanups. The
first 7 patches in the series are really pretty directly related to
But while in there I noticed some other somewhat subtle issues and
have addressed those in this series as well:
- There is a table that tracks names to ensure duplicates aren't
produced as a result of obfuscation. There was a case where a
failure to update the table was silently ignored.
- There was still a chance that pathological cases could end up
repeating due to finding duplicates. I changed it so it would
give up after a fixed number of attempts.
- Obfuscated names had been chosen from an alphabet of all allowable
characters. This was more than needed, so I made it create names
that were (mostly) printables.
- It was previously possible for an obfuscated name to end up being
a duplicate of a real name, because non-obfuscated names were not
placed in the name table.
And finally I did a little tidying of the code that manages the name