Re: [Gluster-devel] dht and rename: how is it supposed to work?

[Emmanuel Dreyfus]

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
address@hidden