Re: Here is linkat(2) again

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Are you sure the problem is the creation of the symlink itself and not the attempt to set GFID on the symlink (where linux sets the xattr on the symlink itself while NetBSD sets the xattr on the target?)

Avati

On Sat, Jun 2, 2012 at 9:48 AM, Emmanuel Dreyfus <manu@xxxxxxxxxx> wrote:
I tracked down this problem this problem on release-3.3/NetBSD

Test case, that seems to work fine:

$ ln -s a b
$ ls -l b
lrwxrwxrwx  0 manu  manu  1 Jun  2 17:46 b -> a

But on bricks logs:

[2012-06-02 17:49:26.920400] W [posix-handle.c:461:posix_handle_hard]
0-pfs-posix: link /export/wd3a/manu/symlink/b ->
/export/wd3a/.glusterfs/db/1e/db1e7f6f-78d4-4701-82dd-e90e6801db31
failed (No such file or directory)
[2012-06-02 17:49:26.920484] E [posix.c:1277:posix_symlink] 0-pfs-posix:
setting gfid on /export/wd3a/manu/symlink/b failed

This is because link(2) is done with a symlink target, and the symlink
leads to nowhere. BSD link(2) first resolves the symlink and get ENOENT.
Linux link(2) operates on the symlink itself, not its target, and works.

Both behavior are standard compliant. The only way to work this around
in a portable way is to use newer standard function linkat(2), which
allow the caller to specify if symlinks must be followed or not.

Here is the change that fixes the above problem. Please approve and
merge! http://review.gluster.com/3507

--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu@xxxxxxxxxx

_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxx
https://lists.nongnu.org/mailman/listinfo/gluster-devel


[Index of Archives]     [Gluster Users]     [Ceph Users]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux