[Bugs] [Bug 1654753] New: A distributed-disperse volume crashes when a symbolic link is renamed

[bugzilla at redhat.com]

https://bugzilla.redhat.com/show_bug.cgi?id=1654753

            Bug ID: 1654753
           Summary: A distributed-disperse volume crashes when a symbolic
                    link is renamed
           Product: GlusterFS
           Version: mainline
         Component: distribute
          Assignee: bugs at gluster.org
          Reporter: jahernan at redhat.com
                CC: bugs at gluster.org



Description of problem:

On a distributed-disperse volume, if you try to rename a symbolic link, the
fuse process dies.

Version-Release number of selected component (if applicable): mainline


How reproducible:

Often, depends on the names used as original and renamed names

Steps to Reproduce:
1. gluster volume create test disperse 6 redundancy 2 host:/bricks/test_{1..12}
2. gluster volume start test
3. mount -t glusterfs host:/test /mnt
4. ln -s /dummy /mnt/symlink
5. mv /mnt/symlink /mnt/symlink.2

Actual results:

Fuse mount crashes

Expected results:

The rename should not cause a crash

Additional info:

The problem appears at the creation of the linkto file when the new name
doesn't go to the same brick the symlink was residing before the rename. In
this case DHT creates the symlink and tries to set some attributes calling
setattr fop.

When setattr is called, the passed inode references the "real" file (i.e. a
symlink). However, when ec receives the answers from bricks, statpre and
statpost say that the inode is a regular file (because linkto files are regular
files on the bricks).

This makes ec assume that it's a file, so it must have a defined size, but
symlinks do not have size, which causes an assertion to fail.

We shouldn't use the same inode structure to represent two different things.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.