Re: xfsrestore: "is a directory: discarding ino"

[Mandy Kirkconnell <alkirkco@xxxxxxx>]

Nathan Scott wrote:
> On Sun, Mar 21, 2004 at 10:42:33PM -0500, Jason Parker-Burlingham wrote:
> 
>>I'm running a 2.4.23 kernel from CVS with LVM1 patches applied.  I'm
>>trying to move an XFS filesystem from one logical volume to another
>>using xfsrestore 2.2.18 and not having a lot of success:
>>
>>   # xfsdump -J - /mnt | xfsrestore -J - /pivot
>>   [...]
>>   xfsrestore: reading directories
>>   xfsdump: dumping non-directory files
>>   xfsrestore: 2694 directories and 69903 entries processed
>>   xfsrestore: directory post-processing
>>   xfsrestore: WARNING: mkdir  failed: No such file or directory
>>   xfsrestore: WARNING: mkdir  failed: No such file or directory
>>   xfsrestore: WARNING: mkdir  failed: No such file or directory
>>   xfsrestore: WARNING: mkdir  failed: No such file or directory
>>   xfsrestore: WARNING: unable to set non-root extended attribute for : No 
>> such file or directory (2)
>>   xfsrestore: WARNING: unable to set secure extended attribute for : No such 
>> file or directory (2)
>>   xfsrestore: restoring non-directory files
>>   xfsrestore: WARNING: open of ///gconf.xml.defaults/schemas///UI/ failed: 
>> No such file or directory: discarding ino 135
>>   [...]
>>   xfsrestore: WARNING: open of /Kodak Pictures// failed: Is a directory: 
>> discarding ino 10811
>>
>>The point at which the errors occur does not appear to be repeatable.
>>
>>If I let the dump/restore run to completion, xfsrestore reports
>>success and the filesystem appears to be complete, but directory
>>permissions are set to 000.
>>
>>Is there some other option I should be passing to xfsrestore?
> 
> 
> Don't think so, looks like a bug.  Almost looks like the filename
> string is null for some reason, somewhere in restore (those mkdir
> errors, etc, above - look like they're trying to print filenames).
> 
> Does this ring any bells Mandy?  

No, this is new to me.  I agree that it looks like there are a bunch of 
null filename strings.  Jason, you mentioned that the point of error 
doesn't seem to be consistent but it sounds like it's reproducible in 
the sense that you've seen this behaviour more than once.  Is there 
anything unique or special about the data you're restoring?  It looks 
like the FS may have extended attributes (non-root, secure, or both ??). 
  I haven't been able to repro this yet so any additional info would be 
helpful.

Mandy