My best guess is that being user1 from the user-group, I would NOT want my permissions to be 775, since any other user of this user-group would have unrestricted RWX access to my private /home/user1 space. Rather 640 by default.
And sharing cache among different users of the same group with the same permissions 775 still, in my opinion, is not a good idea, since, as my best understanding is, having different packages/releases, sstate-cache will be superposition of these different packages/releases (humongous sstate-cache)... In the sense, that any user can do whatever to shared sstate-cache, and to harm other users (unintentionally). Divide and conquer is better approach. Agree if the same user shares two different releases with the same sstate-cache, as single user. Has only control over, does not harm anyone else if something go awry. Much more cleaner... Seems. IMHO. Zoran _______ On Mon, Sep 25, 2017 at 8:55 PM, Burton, Ross <ross.bur...@intel.com> wrote: > I'm guessing one of the users has a different umask to the other, so is > writing directories with mode 755 instead of 775. > > Ross > > On 25 September 2017 at 19:41, Marco <cavallini.k...@gmail.com> wrote: > >> Hello, >> I am trying to share a sstate-cache between two (or more) users in a >> shared directory. >> Although I set the directory owner, group and permissions I face to a >> weird condition that I don't understand. >> Particularly why some directories don't have the group write >> permisisons that drive me to a buld failure for mambers of the group. >> >> I wonder if I am doing something wrong or I have an unexpected issue. >> >> >> koan@kmobile:sstate-cache$ ll >> totale 1028 >> drwxrwxr-x 2 koan devgroup 4096 set 14 15:32 00 >> drwxrwxr-x 2 koan devgroup 4096 set 14 14:37 01 >> ... >> drwxr-xr-x 2 koan devgroup 4096 set 14 15:31 1d >> drwxrwxr-x 2 koan devgroup 4096 set 14 15:31 1e >> ... >> drwxr-xr-x 2 koan devgroup 4096 set 14 15:32 27 >> drwxrwxr-x 2 koan devgroup 4096 set 14 15:32 28 >> ... >> etc... >> >> >> Any help would be greatly appreciated. >> >> Thank you >> -- >> Marco 'mckoan' >> -- >> _______________________________________________ >> yocto mailing list >> yocto@yoctoproject.org >> https://lists.yoctoproject.org/listinfo/yocto >> > > > -- > _______________________________________________ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto > >
-- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
