On Fri, Jul 29, 2011 at 11:03:34AM +0530, Amar Tumballi wrote: > rename(2) can be performed on a symlink too. Hence, I guess what distribute > is doing is valid here. The problem is not rename(2) here, but link(2) that dht produces for a rename(2). By the way I spoted the difference between Linux and NetBSD that causes the bug: link(2) will fail on a symlink to a directory on NetBSD, while it works on Linux $ cd /tmp $ mkdir i386 $ ln -s i386 inst.xxx $ ln inst.xxx machine ln: machine: Operation not permitted $ uname NetBSD $ mkdir i386 $ ln -s i386 inst.xxx $ ln inst.xxx machine $ ls -ld machine lrwxrwxrwx 2 manu manu 4 jui 29 10:03 machine -> i386 $ uname Linux I still have to investigate whether NetBSD behavior is compliant with SUSv2. Would it make sense for glusterfs dht to use rename(2) on IA_IFLNK just like it does for IA_IFDIR? I mean a change like this: --- xlators/cluster/dht/src/dht-rename.c.orig +++ xlators/cluster/dht/src/dht-rename.c @@ -763,9 +763,10 @@ oldloc->path, src_hashed->name, src_cached->name, newloc->path, dst_hashed->name, dst_cached ? dst_cached->name : "<nul>"); - if (IA_ISDIR (oldloc->inode->ia_type)) { + if (IA_ISDIR (oldloc->inode->ia_type) || + IA_ISLNK (oldloc->inode->ia_type)) { dht_rename_dir (frame, this); } else { local->op_ret = 0; dht_rename_create_links (frame); -- Emmanuel Dreyfus manu@xxxxxxxxxx