+++ This bug was initially created as a clone of Bug #1309342 +++ Description of problem: Enabling trash feature for a volume is resulting in wrong permissions being set on previous copy of a truncated file for which a corresponding path does not exists under trash directory. This only happens for the first truncation of file under same directory hierarchy. Subsequent truncations creates previous copies with correct permissions. Version-Release number of selected component (if applicable): mainline How reproducible: always Steps to Reproduce: 1. Create, start and mount a simple distributed volume. 2. Enable trash for the volume and change to mount point. # gluster volume set <VOLNAME> features.trash on 3. Create a temporary directory under root. # mkdir tmp 4. Create a file inside tmp/ with some content. # echo 'Hello, World' > tmp/foo 5. Change permissions on tmp/foo # chmod 0777 tmp/foo 5. truncate tmp/foo # truncate -s 3 tmp/foo 6. Check the permissions of the previous copy of foo created inside .trashcan/tmp/ # ls -l .trashcan/tmp Actual results: .trashcan/tmp/foo_xxxx has different permissions than that of tmp/foo Expected results: .trashcan/tmp/foo_xxxx and tmp/foo should match their permission bits. --- Additional comment from Vijay Bellur on 2016-02-17 09:24:07 EST --- REVIEW: http://review.gluster.org/13461 (features/trash: Retain file permissions during truncate) posted (#1) for review on master by Anoop C S (anoopcs) --- Additional comment from Vijay Bellur on 2016-03-01 02:55:54 EST --- COMMIT: http://review.gluster.org/13461 committed in master by Jeff Darcy (jdarcy) ------ commit b1cb581424305592fac5394a578b307117b22fe7 Author: Anoop C S <anoopcs> Date: Wed Feb 17 15:50:05 2016 +0530 features/trash: Retain file permissions during truncate Consider the situation where directory path for a truncated file does not exists under trash directory. In this scenario after creating the required path we failed to create the orginal file with proper permissions. Eventhough we try to fetch permissions from local->origpath, it was never filled with required value in truncate and ftruncate call paths. This change will copy original location to local->origpath inside both fop handling functions. Change-Id: If5930b6d368d08e58f04db999f3f9edb9250bcb9 BUG: 1309342 Signed-off-by: Anoop C S <anoopcs> Reviewed-on: http://review.gluster.org/13461 Smoke: Gluster Build System <jenkins.com> CentOS-regression: Gluster Build System <jenkins.com> NetBSD-regression: NetBSD Build System <jenkins.org> Reviewed-by: jiffin tony Thottan <jthottan> Reviewed-by: Jeff Darcy <jdarcy>
REVIEW: http://review.gluster.org/13555 (features/trash: Retain file permissions during truncate) posted (#1) for review on release-3.7 by Anoop C S (anoopcs)
COMMIT: http://review.gluster.org/13555 committed in release-3.7 by Vijay Bellur (vbellur) ------ commit 82674a299a3fa9b969c494d2d0a3e72600323af8 Author: Anoop C S <anoopcs> Date: Wed Feb 17 15:50:05 2016 +0530 features/trash: Retain file permissions during truncate Consider the situation where directory path for a truncated file does not exists under trash directory. In this scenario after creating the required path we failed to create the orginal file with proper permissions. Eventhough we try to fetch permissions from local->origpath, it was never filled with required value in truncate and ftruncate call paths. This change will copy original location to local->origpath inside both fop handling functions. >Change-Id: If5930b6d368d08e58f04db999f3f9edb9250bcb9 >BUG: 1309342 >Signed-off-by: Anoop C S <anoopcs> >Reviewed-on: http://review.gluster.org/13461 >Smoke: Gluster Build System <jenkins.com> >CentOS-regression: Gluster Build System <jenkins.com> >NetBSD-regression: NetBSD Build System <jenkins.org> >Reviewed-by: jiffin tony Thottan <jthottan> >Reviewed-by: Jeff Darcy <jdarcy> (cherry picked from commit b1cb581424305592fac5394a578b307117b22fe7) Change-Id: I5d964b4d802551bb04a7011f88edb59a1231238e BUG: 1313233 Signed-off-by: Anoop C S <anoopcs> Reviewed-on: http://review.gluster.org/13555 NetBSD-regression: NetBSD Build System <jenkins.org> Smoke: Gluster Build System <jenkins.com> CentOS-regression: Gluster Build System <jenkins.com> Reviewed-by: jiffin tony Thottan <jthottan> Reviewed-by: Vijay Bellur <vbellur>
This bug is getting closed because a release has been made available that should address the reported issue. In case the problem is still not fixed with glusterfs-3.7.9, please open a new bug report. glusterfs-3.7.9 has been announced on the Gluster mailinglists [1], packages for several distributions should become available in the near future. Keep an eye on the Gluster Users mailinglist [2] and the update infrastructure for your distribution. [1] https://www.gluster.org/pipermail/gluster-users/2016-March/025922.html [2] http://thread.gmane.org/gmane.comp.file-systems.gluster.user