Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

Click here to return to the 'umask, NSUmask, etc.' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
umask, NSUmask, etc.
Authored by: sjk on Feb 02, '06 12:12:14PM
Just wanted to add that using "umask 2" and "NSUmask 2" doesn't guarantee files will always be created group writable.

Also, if a directory is group writable any member of its group can create/delete/rename files in that directory, but not necessarily modify them because of lacking explicit write permission. In that case you may need to change permissions of any preexisting files to be group writable.

An app might modify a write-protected file in a group-writable directory by renaming the original file, writing a new version, then deleting the original. That new version will normally be owned by the user running the app. Sometimes the new version will properly inherit permissions via umask but there are exceptions. Version control software like RCS can operate this way, relying on directories being writable rather than the individual files they contain.

The rules for traditional Unix-style directory and regular file permissions/ownerships are fairly easy to understand. What's tricky is getting them to properly behave and cooperate consistently, especially over entire filesystems. For example, the big limitation with umask is it's a global setting rather than being per-directory. ACLs can help but add more complexity and management issues.

Personally, I prefer managing a smaller number of group writable directories than a larger number of group writable files. If someone can't modify the file in a group writable directory I might tell them to make a copy of it, modify that, then replace the original with the copy instead of having to make the original file writable. And sometimes it's an advantage that the file ownership then changes to the user who last modified it. But most apps only care about file permissions when attempting modifications and ignore possibly more liberal directory permissions.

As I've written before, the original Unix permission scheme wasn't designed for scaling to handle the huge numbers of files/directories we manage nowadays yet we're still stuck using it.

[ Reply to This | # ]