Bug 1293903

Summary:	[Tier]: can not delete symlinks from client using rm
Product:	[Red Hat Storage] Red Hat Gluster Storage	Reporter:	Rahul Hinduja <rhinduja>
Component:	tier	Assignee:	Mohammed Rafi KC <rkavunga>
Status:	CLOSED ERRATA	QA Contact:	Rahul Hinduja <rhinduja>
Severity:	urgent	Docs Contact:
Priority:	unspecified
Version:	rhgs-3.1	CC:	asrivast, byarlaga, dlambrig, rhs-bugs, rkavunga, sankarshan, storage-qa-internal
Target Milestone:	---	Keywords:	Regression, ZStream
Target Release:	RHGS 3.1.2
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:	glusterfs-3.7.5-14	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:
Clones:	1293963 (view as bug list)		Environment:
Last Closed:	2016-03-01 06:05:23 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1293237, 1293963, 1295360

Description Rahul Hinduja 2015-12-23 12:58:07 UTC

Description of problem:
=======================

Tried to remove symlink from client, the command returns to prompt without error and echo $? show 0. But the file is still present at client.

Client:
=======
[root@dj a]# touch b
[root@dj a]# ln -s b c
[root@dj a]# ls
b  c
[root@dj a]#
[root@dj a]# ll
total 0
-rw-r--r--. 1 root root 0 Dec 23 05:32 b
lrwxrwxrwx. 1 root root 1 Dec 23  2015 c -> b
[root@dj a]# 
[root@dj a]# rm -r c
rm: remove symbolic link ‘c’? y
[root@dj a]# echo $?
0
[root@dj a]# ls
b  c
[root@dj a]#
[root@dj a]# ll
total 0
-rw-r--r--. 1 root root 0 Dec 23 05:32 b
lrwxrwxrwx. 1 root root 1 Dec 23  2015 c -> b
[root@dj a]# 

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

glusterfs-3.7.5-13.el7rhgs.x86_64


How reproducible:
=================
1/1


Steps to Reproduce:
===================
1. Create file on tier volume
2. Create symlink to file
3. Delete symlink

Actual results:
===============
Symlink remain in system


Expected results:
=================
symlink should be deleted

Comment 4 Mohammed Rafi KC 2015-12-23 18:22:58 UTC

this happens if we delete the actual which symlink pointed to.

upstream patch http://review.gluster.org/13074

Comment 5 Rahul Hinduja 2015-12-28 05:03:36 UTC

(In reply to Mohammed Rafi KC from comment #4)
> this happens if we delete the actual which symlink pointed to.
> 
> upstream patch http://review.gluster.org/13074

Just to be clear, this happens to an actual symlink file deletion as well i.e, delete an symlink file only which returns no errors and remains in system.

Comment 6 Mohammed Rafi KC 2015-12-28 06:09:50 UTC

(In reply to Rahul Hinduja from comment #5)
> (In reply to Mohammed Rafi KC from comment #4)
> > this happens if we delete the actual which symlink pointed to.
> > 
> > upstream patch http://review.gluster.org/13074
> 
> Just to be clear, this happens to an actual symlink file deletion as well
> i.e, delete an symlink file only which returns no errors and remains in
> system.

Sorry, I was wrong here. I tested in a single machine where the symlink and the actual file was in same machine.

Comment 9 Rahul Hinduja 2016-01-06 12:00:51 UTC

Verified with build: glusterfs-3.7.5-14.el7rhgs.x86_64

Removal of symbolic and hardlink from tiervolume is successful without any errors. Moving this bug to verified state

[root@dj ~]# mkdir /mnt/fuse
[root@dj ~]# mount -t glusterfs 10.70.37.165:/tiervolume /mnt/fuse/
[root@dj ~]# cd /mnt/fuse/
[root@dj fuse]# 
[root@dj fuse]# touch a
[root@dj fuse]# ls
a
[root@dj fuse]# ll
total 0
-rw-r--r--. 1 root root 0 Jan  6 04:36 a
[root@dj fuse]# ln -s a b
[root@dj fuse]# ll
total 0
-rw-r--r--. 1 root root 0 Jan  6 04:36 a
lrwxrwxrwx. 1 root root 1 Jan  6  2016 b -> a
[root@dj fuse]# rm -rf b
[root@dj fuse]# ll
total 0
-rw-r--r--. 1 root root 0 Jan  6 04:36 a
[root@dj fuse]# ln -s a c
[root@dj fuse]# ll
total 0
-rw-r--r--. 1 root root 0 Jan  6 04:36 a
lrwxrwxrwx. 1 root root 1 Jan  6  2016 c -> a
[root@dj fuse]# rm c
rm: remove symbolic link ‘c’? y
[root@dj fuse]# ll
total 0
-rw-r--r--. 1 root root 0 Jan  6 04:36 a
[root@dj fuse]# 
[root@dj fuse]# 
[root@dj fuse]# for i in {1..3}; do cp -rf /etc etc.$i ; done 
[root@dj fuse]# 
[root@dj fuse]# ll
total 336
-rw-r--r--.  1 root root     0 Jan  6 04:36 a
drwxr-xr-x. 80 root root 65536 Jan  6  2016 etc.1
drwxr-xr-x. 80 root root 65536 Jan  6  2016 etc.2
drwxr-xr-x. 80 root root 65536 Jan  6  2016 etc.3
[root@dj fuse]# ln -s a d
[root@dj fuse]# ln a e
[root@dj fuse]# ll
total 336
-rw-r--r--.  2 root root     0 Jan  6 04:36 a
lrwxrwxrwx.  1 root root     1 Jan  6  2016 d -> a
-rw-r--r--.  2 root root     0 Jan  6 04:36 e
drwxr-xr-x. 80 root root 65536 Jan  6  2016 etc.1
drwxr-xr-x. 80 root root 65536 Jan  6  2016 etc.2
drwxr-xr-x. 80 root root 65536 Jan  6  2016 etc.3
[root@dj fuse]# 
[root@dj fuse]# rm -rf *
[root@dj fuse]# ll
total 0
[root@dj fuse]# ls
[root@dj fuse]# 
[root@dj fuse]# touch {1..9}
[root@dj fuse]# for i in {1..9}; do ln -s $i sym.$i ; done
[root@dj fuse]# for i in {1..9}; do ln  $i hard.$i ; done
[root@dj fuse]# ls
1  2  3  4  5  6  7  8  9  hard.1  hard.2  hard.3  hard.4  hard.5  hard.6  hard.7  hard.8  hard.9  sym.1  sym.2  sym.3  sym.4  sym.5  sym.6  sym.7  sym.8  sym.9
[root@dj fuse]# ll
total 0
-rw-r--r--. 2 root root 0 Jan  6 04:44 1
-rw-r--r--. 2 root root 0 Jan  6 04:44 2
-rw-r--r--. 2 root root 0 Jan  6 04:44 3
-rw-r--r--. 2 root root 0 Jan  6 04:44 4
-rw-r--r--. 2 root root 0 Jan  6 04:44 5
-rw-r--r--. 2 root root 0 Jan  6 04:44 6
-rw-r--r--. 2 root root 0 Jan  6 04:44 7
-rw-r--r--. 2 root root 0 Jan  6 04:44 8
-rw-r--r--. 2 root root 0 Jan  6 04:44 9
-rw-r--r--. 2 root root 0 Jan  6 04:44 hard.1
-rw-r--r--. 2 root root 0 Jan  6 04:44 hard.2
-rw-r--r--. 2 root root 0 Jan  6 04:44 hard.3
-rw-r--r--. 2 root root 0 Jan  6 04:44 hard.4
-rw-r--r--. 2 root root 0 Jan  6 04:44 hard.5
-rw-r--r--. 2 root root 0 Jan  6 04:44 hard.6
-rw-r--r--. 2 root root 0 Jan  6 04:44 hard.7
-rw-r--r--. 2 root root 0 Jan  6 04:44 hard.8
-rw-r--r--. 2 root root 0 Jan  6 04:44 hard.9
lrwxrwxrwx. 1 root root 1 Jan  6  2016 sym.1 -> 1
lrwxrwxrwx. 1 root root 1 Jan  6  2016 sym.2 -> 2
lrwxrwxrwx. 1 root root 1 Jan  6  2016 sym.3 -> 3
lrwxrwxrwx. 1 root root 1 Jan  6  2016 sym.4 -> 4
lrwxrwxrwx. 1 root root 1 Jan  6  2016 sym.5 -> 5
lrwxrwxrwx. 1 root root 1 Jan  6  2016 sym.6 -> 6
lrwxrwxrwx. 1 root root 1 Jan  6  2016 sym.7 -> 7
lrwxrwxrwx. 1 root root 1 Jan  6  2016 sym.8 -> 8
lrwxrwxrwx. 1 root root 1 Jan  6  2016 sym.9 -> 9
[root@dj fuse]# rm -rf *
[root@dj fuse]# ll
total 0
[root@dj fuse]# ls
[root@dj fuse]# mount | grep tiervolume 
10.70.37.165:/tiervolume on /mnt/fuse type fuse.glusterfs (rw,relatime,user_id=0,group_id=0,default_permissions,allow_other,max_read=131072)
[root@dj fuse]#

Comment 11 errata-xmlrpc 2016-03-01 06:05:23 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2016-0193.html