On Mon, Jan 01, 2007 at 11:47:06PM +0100, Mikulas Patocka wrote: > >Anyway, cp -a is not the only application that wants to do hardlink > >detection. > > I tested programs for ino_t collision (I intentionally injected it) and > found that CP from coreutils 6.7 fails to copy directories but displays > error messages (coreutils 5 work fine). MC and ARJ skip directories with > colliding ino_t and pretend that operation completed successfuly. FTS > library fails to walk directories returning FTS_DC error. Diffutils, find, > grep fail to search directories with coliding inode numbers. Tar seems > tolerant except incremental backup (which I didn't try). All programs > except diff were tolerant to coliding ino_t on files. Thanks for testing so many programs, but... did the files/symlinks with colliding inode number have i_nlink > 1? Or did you also have directories with colliding inode numbers. It looks like you've introduced hardlinked directories in your test which are definitely not supported, in fact it will probably cause not only issues for userspace programs, but also locking and garbage collection issues in the kernel's dcache. I'm surprised you're seeing so many problems. The only find problem that I am aware of is the one where it assumes that there will be only i_nlink-2 subdirectories in a given directory, this optimization can be disabled with -noleaf. The only problems I've encountered with ino_t collisions are archivers and other programs that recursively try to copy a tree while preserving hardlinks. And in all cases these seem to have no problem with such collisions as long as i_nlink == 1. Jan - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
