This is something we've dealt with as one of those "just how the system works" kinds of things, but I'm wondering if maybe someone else has found a better workaround than we have. We have a rather large intranet site which is managed by a central team and contains several different department sites, which are maintained in separate branches within the main intranet branch. Each departmental site's workarea is shared with a specific group to restrict who can mess around in there. There are several UNIX groups set up and the central team is a member of most of those groups. However, in UNIX, you have a primary group, which is what a file's group ownership defaults to when you create a file in a particular directory. Herein lies the problem.
Let's say for the sake of this argument that Jim is in the central intranet team and his primary group is "A", although he is also a member of groups "B", "C" and "D". There is a departmental site in another branch, whose workarea is shared with group "B". Jim is managing that particular site and is dropping some files into its workarea. However the files that Jim puts into the workarea are now group owned by group "A". So anyone in the department who only exists in group "B" cannot modify those files that Jim dropped in there. What a pain.
This happens on a grand scale with over 100 department sites in our intranet. To get around it, I created a custom menu item that can be run in any workarea and will figure out what group the workarea is shared with and then recursively changes the group ownership of all the files in that workarea to that group. The downside is that it marks every file in the workarea as modified - not desired. But it works and can be executed by anyone and so I don't have to fix file ownerships all day long.
I'm wondering if anyone knows a better way to handle this frustrating situation. Am I using primitive methods when there is an easy solution?
Dave SmithSr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com
