Bug 1373524

Summary: SMB:listing and chmod on original file which is renamed now succeeds from one of the cifs mount
Product: [Community] GlusterFS Reporter: surabhi <sbhaloth>
Component: md-cacheAssignee: Poornima G <pgurusid>
Status: CLOSED EOL QA Contact:
Severity: high Docs Contact:
Priority: unspecified    
Version: 3.8CC: bugs
Target Milestone: ---Keywords: Triaged
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-11-07 10:41:28 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:

Description surabhi 2016-09-06 13:56:55 UTC
Description of problem:
******************************

When multiple files are created from one of the cifs mount and are renamed in loop, executing ll on that renamed file from another cifs mount succeeds even when the file is already renamed.chmod also succeeded on that file.

For ex. : 
From mnt1:
create file1 from cifs mnt1 
rename it to f1 


From mnt2:
ll file1
chmod 766 file1

Above operations succeeds from mnt2 

On mnt1 :

ll file1:
no such file or directory
         

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

glusterfs-libs-3.8.2-0.24.gitf524648.el7.x86_64
glusterfs-debuginfo-3.8.2-0.24.gitf524648.el7.x86_64
glusterfs-cli-3.8.2-0.24.gitf524648.el7.x86_64
glusterfs-3.8.2-0.24.gitf524648.el7.x86_64
glusterfs-server-3.8.2-0.24.gitf524648.el7.x86_64
samba-vfs-glusterfs-4.4.5-1.el7rhgs.x86_64
glusterfs-fuse-3.8.2-0.24.gitf524648.el7.x86_64
glusterfs-api-3.8.2-0.24.gitf524648.el7.x86_64
glusterfs-client-xlators-3.8.2-0.24.gitf524648.el7.x86_64

How reproducible:
Always


Steps to Reproduce:
1.Multiple cifs mount
2.Create 10 files from mnt1
3.Rename 10 files in loop from mnt1
4.ll of file1 from mnt2
5. chmod 776 file1

Actual results:

the listing and chmod succeeds from one of the mount points for the file which is already renamed from another mount point.

Expected results:
the other cifs client should get updated with the renamed file name and should not list or allow any operation on the old filename.


Additional info:

Comment 1 Niels de Vos 2016-09-12 05:39:53 UTC
All 3.8.x bugs are now reported against version 3.8 (without .x). For more information, see http://www.gluster.org/pipermail/gluster-devel/2016-September/050859.html

Comment 2 Niels de Vos 2017-11-07 10:41:28 UTC
This bug is getting closed because the 3.8 version is marked End-Of-Life. There will be no further updates to this version. Please open a new bug against a version that still receives bugfixes if you are still facing this issue in a more current release.