d30c3dcf11
op_ret incremented to compensate for NULL terminating character
leads to self referential loop where OSXFUSE which would reply
on a same READLINK() over and over again
~~~
[2014-07-12 08:41:29.815473]
T [fuse-bridge.c:1372:fuse_readlink_cbk] 0-glusterfs-fuse:
1: /a/b/1 => ../../1
[2014-07-12 08:41:29.815820]
T [fuse-bridge.c:1372:fuse_readlink_cbk] 0-glusterfs-fuse:
0: /a/b/1 => ../../1
[2014-07-12 08:41:29.816165]
T [fuse-bridge.c:1372:fuse_readlink_cbk] 0-glusterfs-fuse:
1: /a/b/1 => ../../1
~~~
It happens due to the problem being (op_ret + 1) > strlen(linkname),
for some odd reason this isn't an issue on Linux where there are odd
safegaurds on these things - Example of following code
~~~
((char *)linkname)[op_ret] = '\0';
send_fuse_data (this, finh, (void *)linkname, op_ret + 2048); <---- Here!
~~~
This behaves normally with no issue, the reasoning i have is that
internally 'readlink()' is verified with strlen() again or perhaps the size
is re-adjusted to the strlen() of `linkname`
This isn't the case on OSX, one needs to make sure that
~~~
strlen(linkname) == op_ret
~~~
Otherwise you would get READLINK() loops as shown above.
This patch fixes the problem.
Many thanks to Anand Avati for helping me out on this.
Change-Id: Ia35818de78a5e4d89bad03ab06e2c5ed6e6753a4
BUG: 1095525
Signed-off-by: Harshavardhana <harsha@harshavardhana.net>
Reviewed-on: http://review.gluster.org/8300
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Anand Avati <avati@redhat.com>
For more info, please visit http://www.gluster.org/.