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. -Alex 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 that issue. 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 table. _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
