|
|
10.4: Share an iPhoto library among multiple users
Yes, I second this.
10.4: Share an iPhoto library among multiple users
Wouldn't just changing your umask take care of this issue?
10.4: Share an iPhoto library among multiple users
Yes, but that would affect all of your newly created files, not just the iPhoto Library. To those not knowing the "umask" sets what permissions new files are created with. Taking into account that by default OS X creates a new different group for each user account, you would need to set your umask to allow write access to all your files to all users, which not everybody wants (unless your tinkering goes further, which involves playing with Netinfo manager, chmod'ing and chown'ing preexisting files in your home folder, blah, blah… not for the faint of heart).
10.4: Share an iPhoto library among multiple users
Oops! I meant iTunes Library in "not just the iPhoto Library".
10.4: Share an iPhoto library among multiple users
Yes, I use umasks to accomplish the same thing and it works great.
umask, NSUmask, etc.
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. |
SearchFrom our Sponsor...Latest Mountain Lion HintsWhat's New:HintsNo new hintsComments last 2 daysNo new commentsLinks last 2 weeksNo recent new linksWhat's New in the Forums?
Hints by TopicNews from Macworld
From Our Sponsors |
|
Copyright © 2014 IDG Consumer & SMB (Privacy Policy) Contact Us All trademarks and copyrights on this page are owned by their respective owners. |
Visit other IDG sites: |
|
|
|
Created this page in 0.14 seconds |
|