I've found a sneaky bug: setting the +d attribute to a file and doing
immediately a xfsdump, the xfsdump ignore the +d attribute of the file. Doing
"sync" or waiting for the cache to be flushed, xfsdump does the right thing.

How to replicate the bug:
 I've found this bug with a machine with 512MB of ram (almost all the filesystem
structure in cache), kernel version 2.6.7, xfs root filesystem, xfsdump
2.2.21-1, shell zsh, debian testing.

To replicate, do this:

Do a level 0 xfsdump of the filesystem, then:

host2:/root# mkdir /try
host2:/root# cd /try
host2:/try# touch prova
host2:/try# ls --inode prova
67326632 prova
host2:/try# xfsdump -l 0 -s try -F -L prova -M prova -f dump -e -v
excluded_files=debug  / |& grep 67326632 [copy here the right inode number of
the file "prova"]
(no output, so the file is not excluded: CORRECT)
host2:/try# chattr +d prova ; xfsdump -l 0 -s try -F -L prova -M prova -f dump
-e -v excluded_files=debug  / |& grep 67326632
(no output, so the file is not excluded: WRONG because i did chattr +d)
host2:/try# sync  
host2:/try# xfsdump -l 0 -s try -F -L prova -M prova -f dump -e -v
excluded_files=debug  / |& grep 67326632 
xfsdump: pruned ino 67326632, owner 0, estimated size 0: skip flag set
(after the "sync", the file is finally excluded!)

Note that with 512MB of ram, the xfsdump is VERY fast to execute, so the kernel
has no time to flush the cache:
host2:/try# time xfsdump -l 0 -s try -F -L prova -M prova -f dump -e -v
excluded_files=debug  / |& grep 67326632
xfsdump: pruned ino 67326632, owner 0, estimated size 0: skip flag set
xfsdump -l 0 -s try -F -L prova -M prova -f dump -e -v excluded_files=debug / 
0.33s user 0.73s system 97% cpu 1.084 total
grep 67326632  0.01s user 0.10s system 10% cpu 1.083 total