Description of problem: ======================= If file has sticky bit and setgid is set, after migration it is removed:- before rebalance:- [root@OVM1 loss]# ls -l total 10240 -rw-r-Sr-T 1 root root 10485760 Aug 7 15:47 rename After rebalance:- [root@OVM1 loss]# ls -l total 10240 -rw-r--r-- 1 root root 10485760 Aug 7 15:47 rename Version-Release number of selected component (if applicable): ============================================================= 3.6.0.27-1.el6rhs.x86_64 How reproducible: ================= haven't tried Steps to Reproduce: =================== 1. create, start and FUSE mount Distributed volume having 3 bricks. 2. created file having size in GB and change permission so it has sticky bit and setgid set. Renamed it so hashed and cached sub-volumes are different [root@OVM1 loss]# ls -l total 10240 -rw-r-Sr-T 1 root root 10485760 Aug 7 15:47 rename 3. started rebalance process for that volume. Once rebalance is completed. 4. checked file from mount point it has different permission. [root@OVM1 loss]# ls -l total 10240 -rw-r--r-- 1 root root 10485760 Aug 7 15:47 rename Actual results: ================ It removed sticky bit and setgid bit Expected results: ================ file permissions should not be changed
Code does not handle this preservation as these bits are used to signal to clients that migration is in progress, etc. In function dht_migrate_file, the current TOTO reads, /* TODO: if the source actually had sticky bit, or sgid bit set, we are not handling it */ This needs to be fixed for this issue to be cleared up.
working as expected on build 3.6.0.29-1.el6rhs.x86_64 hence closing this bug and opening new for issues mentioned in comment # 6