[Bug 11027] New: Sticky bit not set when using --chmod=D+t alone, without --perms

samba-bugs at samba.org samba-bugs at samba.org
Tue Dec 30 21:22:32 MST 2014


https://bugzilla.samba.org/show_bug.cgi?id=11027

            Bug ID: 11027
           Summary: Sticky bit not set when using --chmod=D+t alone,
                    without --perms
           Product: rsync
           Version: 3.0.9
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P5
         Component: core
          Assignee: wayned at samba.org
          Reporter: mgaldzic at gmail.com
        QA Contact: rsync-qa at samba.org

Another way to phrase, sticky bit on directories gets ignored when not using
--perms, -p.
Suggestion: At the very least a strong mention in the docs/ man page under the
--chmod entry.

First, I point out one situation where I had it work, then I go on to describe
the failing case. Finally, I show a combination which makes it work. (rsync
Kung fu)

*Sticky bit ON, on source dir
drwxr-sr-t. 2 redleader rebels 32 Dec 30 18:32 new_data

Use --perms, include trailing slash on source dir
rsync -r -p  new_data/ destination
Result: works, sticky bit ON, on destination dir
drwxr-sr-t. 3 redleader rebels 47 Dec 30 19:15 destination


*Sticky bit OFF, on source dir
drwxr-sr-x. 2 redleader rebels 32 Dec 30 18:32 new_data

Attempt to chmod Sticky bit set on directories
rsync -r --chmod=D+t  new_data/ destination
Result: fail, Sticky bit OFF on dest dir
drwxr-sr-x. 2 redleader rebels 32 Dec 30 19:36 destination

*Want to force the setting of the Sticky Bit on all dirs

Starting with a mix of permissions
$ ls -l new_data .
.:
drwxr-sr-x. 4 redleader rebels 39 Dec 30 19:38 new_data
new_data:
drwxrwsr-x. 2 redleader rebels 6 Dec 30 19:38 sticky_off
drwxrwsr-t. 2 redleader rebels 6 Dec 30 19:38 sticky_on

$ rsync -rp --chmod=D+t  new_data/ destination
Note: use -p [or --perms] and include the trailing slash on source_dir/

Result: All dirs have the sticky bit set
$ ls -l destination .
.:
total 0
drwxr-sr-t. 4 redleader rebels 39 Dec 30 19:42 destination
drwxr-sr-t. 4 redleader rebels 39 Dec 30 19:38 new_data
destination:
total 0
drwxrwsr-t. 2 redleader rebels 6 Dec 30 19:42 sticky_off
drwxrwsr-t. 2 redleader rebels 6 Dec 30 19:42 sticky_on


*Related point for anyone that is confused by the behavior of --chmod:

Condition A: Sticky bit ON, on source dir
drwxr-sr-t. 2 redleader rebels 32 Dec 30 18:32 new_data

Use --perms, do not include slash on source dir
rsync -r --perms  new_data destination

Result: ?, sticky bit OFF, on destination dir, but sticky ON new_data (now a
subdir)
drwxr-sr-x. 2 redleader rebels 32 Dec 30 19:25 destination
destination/:
drwxr-sr-t. 4 redleader rebels 39 Dec 30 19:52 new_data
[Note: I found this behavior unintuitive, as chmod is being done on destination
dir; I expected destination to have the permissions set as I specify in the
rsync command, same behavior with other --chmod directives rsync -rp
--chmod=Dg-w new_data destination. This follows expectations based on using the
chmod command itself in a shell]

-- 
You are receiving this mail because:
You are the QA Contact for the bug.


More information about the rsync mailing list