[Top] [All Lists]

Fwd: xfs_reno

To: david@xxxxxxxxxxxxx
Subject: Fwd: xfs_reno
From: Hans-Peter Jansen <hpj@xxxxxxxxx>
Date: Wed, 06 Mar 2013 15:55:19 +0100
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
User-agent: KMail/4.9.5 (Linux/3.4.28-2.20-desktop; KDE/4.9.5; x86_64; ; )
Hi Dave,

I tried to gather Barrys SOB, but failed so far. His trace ends in 2009 google 

How is this case usually handled?

Here's the current state of things.


----------  Weitergeleitete Nachricht  ----------

Betreff: xfs_reno
Datum: Mittwoch, 6. MÃrz 2013, 12:52:19
Von: Hans-Peter Jansen <hpj@xxxxxxxxx>
An: bnaujok@xxxxxxx

Hi Barry,

attached is a slightly mangled version of your xfs_reno tool, that I badly 
needed recently. While at it, I plan to submit it, as it saved my *ss. Thanks.

Apart from relocation to xfsprogs, I just changed this

+       log_message(LOG_DEBUG, "%s: %llu %lu %s", msg, node->ino,
+                       node->numpaths, node->paths[0]);

from %llu to %lu for the node->numpaths argument. It might still be wrong, as 
numpath is defined as nlink_t which is a __u32 type, but the %s printed 
garbage like this:

Scanning directory tree...
xfs_reno: add_node_path: ino 8611163235, path 
xfs_reno: add_node_path: ino 8611163233, path 
xfs_reno: add_node_path: ino 8611163234, path 
xfs_reno: nodehash: 8611163233 692488159933497345 ïï]ïïfïeï
xfs_reno: nodehash: 8611163234 692366801337581569 ïï]ïïfïeï
xfs_reno: nodehash: 8611163235 692223830466232321 ïï]ïïfïeï

I guess, gcc is smart enough to see, that the struct members overlap here, and 
prints the paths[0] argument as a %llu value. What do you think?

Anyway, I will revise this during the course of creating a xlstests test for 

Do you allow me to add your Signed-off-by to this patch?

If you want to build this, apply both patches to xfsprogs.



Attachment: xfsprogs-xfs_reno.diff
Description: Text Data

Attachment: xfsprogs-libattr-ac.diff
Description: Text Data

<Prev in Thread] Current Thread [Next in Thread>