[Bugs] [Bug 1313233] New: Wrong permissions set on previous copy of truncated files inside trash directory

[bugzilla at redhat.com]

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

            Bug ID: 1313233
           Summary: Wrong permissions set on previous copy of truncated
                    files inside trash directory
           Product: GlusterFS
           Version: 3.7.8
         Component: trash-xlator
          Severity: medium
          Priority: medium
          Assignee: bugs at gluster.org
          Reporter: anoopcs at redhat.com
                CC: bugs at gluster.org, jthottan at redhat.com
        Depends On: 1309342



+++ 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 at redhat.com)

--- 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 at redhat.com) 
------
commit b1cb581424305592fac5394a578b307117b22fe7
Author: Anoop C S <anoopcs at redhat.com>
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 at redhat.com>
    Reviewed-on: http://review.gluster.org/13461
    Smoke: Gluster Build System <jenkins at build.gluster.com>
    CentOS-regression: Gluster Build System <jenkins at build.gluster.com>
    NetBSD-regression: NetBSD Build System <jenkins at build.gluster.org>
    Reviewed-by: jiffin tony Thottan <jthottan at redhat.com>
    Reviewed-by: Jeff Darcy <jdarcy at redhat.com>


Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1309342
[Bug 1309342] Wrong permissions set on previous copy of truncated files
inside trash directory
-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.