RTC 4.0 regression? how to set group/other executable permissions?
One answer
UNIX File Permissions Aren't Maintained After scm load... (161875)
Comments
Hi Tim. Thanks for the response. I don't know what to tell you about 3.x: even now if I use my 3.x client to load my workspace all my executable files have all executable bits set. If I use my 4.0.0.1 client to load my workspace, it has only the user execute bit set.
This is just a bug. If the concern were really about "exposing permissions", then the group and other "read" permissions would be disabled. It makes zero sense to allow read but not execute, from an exposure point of view. Someone just has to copy the file somewhere else and make it executable.
The only non-broken way to make this work is have default permissions of 0666 if the executable attribute is not set, or 0777 if the executable attribute is set, and let the user's umask handle the details. That's the way UNIX was designed to work and it's worked fine for 40+ years; it's silly for an SCM tool to try to change that. If users don't want to allow this that should be their choice, by setting umask.
I've tested on Ubuntu 12.04 and Linux Mint 13 using RTC 3.0.1.4. Ubuntu seems to preserve the execute bits as you see it when I load. Mint does not preserve the execute bits. I'm not sure about the differences and my umask is set to 0022 on both. RTC 4.0 seems to exhibit the behaviour you've described on both Ubuntu and Mint.
I think this does warrant a work item so please open one. It is odd that it has changed between the two versions. It's possible that I just couldn't find the work item that explains this behaviour or it's unexpected behaviour due to some other changes.
As for the umask, there is a work item to respect the setting: We should respect the umask for the user's execute bit (205284). Please add your support to it.
Comments
Paul Smith
Oct 25 '12, 9:35 p.m.Just in case it's not clear, I'm using RTC on GNU/Linux. Cheers!