2012/2/18 Tommy Wu <wu.tommy@xxxxxxxxx>:
> 2012/2/18 Bill Kendall <wkendall@xxxxxxx>:
>> On 02/14/2012 11:21 AM, Tommy Wu wrote:
>>> from the xfsdump man page:
>>> xfsrestore also generates a directory named orphanage in the dest
>>> directory. xfsrestore removes this directory after completing a simple
>>> restore. However, if orphanage is not empty, it is not removed. This
>>> can happen if files present on the dump media are not referenced by
>>> any of the restored directories. The orphanage has an entry for each
>>> such file. The entry name is the file's original inode number, a ".",
>>> and the file's generation count modulo 4096 (only the lower 12 bits of
>>> the generation count are used).
>>> and the -t option from xfsdump man page:
>>> Displays the contents of the dump, but does not create or modify any
>>> files or directories. It may be desirable to set the verbosity level
>>> to silent when using this option.
>>> But when we use -t option with xfsrestore, it still create orphanage
>>> directory in current directory (because no dest directory assign).
>>> and if it's not empty, it is not removed.
>>> This is a bug or it's a feature?
>> I can see code where this would happen, except that it would appear
>> to require both -r and -t to be used, and xfsrestore doesn't allow
>> If you send the command line you used I can take another look.
> here is the command I used for -t:
> cat var.xfsdump.gz | gzip -dqv | xfsrestore -v silent -p 300 -J -t - |
> grep "^xfsrestore:"
> I also test it with only -t option, it also create orphanage folder
> for such dump file (not all dump file has this issue)
> cat var.xfsdump.gz | gzip -dqv | xfsrestore -t - | grep "^xfsrestore:"
> Tommy Wu
I use xfsdump 3.0.6 plus following 2 patch:
[PATCH] xfsdump: allow system() to obtain exit status
[PATCH] xfsdump: handle files with no extent headers