On Fri, Mar 8, 2013 at 9:32 PM, Eric Sandeen <sandeen@xxxxxxxxxxx> wrote:
> On 3/8/13 4:21 AM, Ole Tange wrote:
>> On Mon, Mar 4, 2013 at 4:20 PM, Eric Sandeen <sandeen@xxxxxxxxxxx> wrote:
>>
>>> 2) so you could run a "real" non-"n" xfs_repair on a metadata image as a more realistic dry run
:
>> I get
>> filenames like:
>>
>> /mnt/disk/??5?z+hEOgl/?7?Psr1?aIH<?ip:??/>S??+??z=ozK/8_0/???d)
>> 5JCG?eiBd?EVsNF'A?v?m?f;Fi6v)d>/?M%?A??J?)B<soGlc??QuY!e-<,6G?
>> X[Df?Wm^[?f 4|
>
> By default, xfs_metadump scrambles filenames, so nothing to worry
> about (it's for privacy reasons). If you use the "-o" option it'll keep
> it in the clear.
Ahh. To me that does not conform to Principle of Least Astonishment -
especially since some of the filenames were not obfuscated.
I would have been less surprised if the files were named:
Use_-o_for_real_file_names_XXXXXXXX
Use_-o_for_real_dir_names_XXXXXXXX
where XXXXXXXX is just a unique number.
/Ole
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
