Remove new permissions handling

[ghost]

This PR is about reverting the change of permissions handling introduced in 1.2. The permissions handling implemented in 1.2 leads to

• backing up of files that have not changed (if only their permissions have changed)
• not recognizing of pre-1.2 backups

#988 #1055 #1093 #1086

[aryoda]

bump... is someone able to review and test this PR?

[aryoda]

The fix seems to enable the --no-perms option "only". Man page says:

-p, --perms
This option causes the receiving rsync to set the destination
permissions to be the same as the source permissions. (See also
the --chmod option for a way to modify what rsync considers to
be the source permissions.)

          When this option is off, permissions are set as follows:

          o      Existing files (including updated files) retain their ex‐
                 isting permissions,  though  the  --executability  option
                 might change just the execute permission for the file.

          o      New  files  get their "normal" permission bits set to the
                 source file’s permissions masked with the  receiving  di‐
                 rectory’s   default  permissions  (either  the  receiving
                 process’s umask, or the  permissions  specified  via  the
                 destination  directory’s  default ACL), and their special
                 permission bits disabled except in the case where  a  new
                 directory  inherits  a  setgid bit from its parent direc‐
                 tory.

[aryoda]

reverting the change of permissions handling introduced in 1.2.

Does anyone know the commit number? Or was it part of multiple commits?

"Undoing" the commit could be another way of solving this...

[emtiu]

Speaking for myself, this problem (meaning #988) is one of the most "hairy" Issues facing the project at the moment. It goes to the heart of the functionality, and will affect almost everyone's backups, no matter which steps we take next.

This is definitely a high-priority problem, but most people affected will have the workaround in place by now, so I think we can afford to take it slow. I'd rather spend some more time figuring out what's what in this project before committing (pardon the pun) to a solution.

[aryoda]

I totally understand this, so no need to hurry.

IMHO the thing is that the BiT user also should understand some rsync basics (esp. hairy things like permissions and links...) but we cannot expect this and that may lead to new issues.