Hi Dave,
I tried to gather Barrys SOB, but failed so far. His trace ends in 2009 google
wise.
How is this case usually handled?
Here's the current state of things.
Cheers,
Pete
---------- 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
/work/dlbase/hosts/11.2/pico/var/run/screens
xfs_reno: add_node_path: ino 8611163233, path
/work/dlbase/hosts/11.2/pico/var/run/pcscd/pcscd.events
xfs_reno: add_node_path: ino 8611163234, path
/work/dlbase/hosts/11.2/pico/var/run/uscreens
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
xfs_reno...
Do you allow me to add your Signed-off-by to this patch?
If you want to build this, apply both patches to xfsprogs.
TIA,
Pete
-------------------------------------------------------------
xfsprogs-xfs_reno.diff
Description: Text Data
xfsprogs-libattr-ac.diff
Description: Text Data
|