On Fri, Jul 29, 2011 at 08:09:01AM +0000, Emmanuel Dreyfus wrote:
> $ cd /tmp
> $ mkdir i386
> $ ln -s i386 inst.xxx
> $ ln inst.xxx machine
> ln: machine: Operation not permitted
> $ uname
> NetBSD
>
> I still have to investigate whether NetBSD behavior is compliant with SUSv2.
I checked NetBSD kernel sources. link(2) follows symlink and work on the
final target. This is fine with SUSv2, which does not tell anything about
symlinks for link(2) behavior. I would say that glusterfs makes a wrong
assumption that it can link on a symlink to a directory.
In order to properly fix this, glusterfs dht rename should resolve
symlinks before doing the rename itself. I can try to make a patch for that
if it is regonised as something to fix in glusterfs. The alternative is to
add a linux_link(2) system call to NetBSD, but I am not sure this
will be acccepted.
> 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:
That propsosed change still breaks: the rename is done but an error
message about failed unlink is presented to the user.
> --- 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
>
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel@xxxxxxxxxx
> https://lists.nongnu.org/mailman/listinfo/gluster-devel
--
Emmanuel Dreyfus
manu@xxxxxxxxxx
