RFC xfsprogs: fix generate_obfuscate_name()
Get series with b4
b4 am 1286390920.1951.357.camel@doinkVersions newest first
- v1 RFC Latest6 patches 0 repliesNew
Patches in v1 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/6 | xfsprogs: change how leading '/' is handleddb/ | +40 | 0 replies | |
| 2/6 | xfsprogs: do slightly less obfuscation in the file namedb/ | +2 | 0 replies | |
| 3/6 | xfsprogs: compute obfuscated name differentlydb/ | +53 | 0 replies | |
| 4/6 | xfsprogs: eliminate a pointless loopdb/ | +63 | 0 replies | |
| 5/6 | xfsprogs: replace repeated blocks with a loopdb/ | +9 | 0 replies | |
| 6/6 | xfsprogs: use pointers to reference path charactersdb/ | +17 | 0 replies |
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [PATCH, RFC 0/6] xfsprogs: fix generate_obfuscate_name()
I'm sending this out for the moment with an "RFC" tag because I don't consider this work done (I want to do some refinements, basically). But I wanted to get the code out there for an initial review to see if there are any major problems with what I'm proposing here.
This is fixing the problem in xfs_db metadump feature in which the attempt to create an obfuscated filename can result in an endless loop.
I've run it through all possible 6-character names starting with 0x01 through 0x07 (and counting...) and the new algorithm (which is basically contained in patch 3 of the series) produces an alternate path with the same hash as the original for all cases. I also ran all the test cases I identified previously and all compute an alternate path without hanging.
-Alex
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs