Elias Pipping <[EMAIL PROTECTED]> wrote: > On Sat, Jan 26, 2008 at 08:58:34AM +0100, Jim Meyering wrote: >> >> Please do this as root: >> >> cd coreutils-6.10/src >> ./id -a >> ./rm -rf f g >> echo a > f >> ./chown +0:+0 f >> ls -ld . f >> ./cp f g >> ls -l g >> >> and look at the output. >> The final ls should show g with group "root". > > For some reason it doesn't. > > # cd coreutils-6.10/src > # ./id -a > uid=0(root) gid=0(wheel) groups=0(wheel),1(daemon),8(procview), > 2(kmem),29(certusers),3(sys),9(procmod),4(tty), > 102(com.apple.sharepoint.group.2),5(operator),80(admin),20(staff), > 101(com.apple.sharepoint.group.1) > # ./rm -rf f g > # echo a > f > # ./chown +0:+0 f > # ls -ld . f > drwxr-xr-x 3 pipping staff 11186 Jan 26 12:29 . > -rw-r--r-- 1 root wheel 2 Jan 26 12:29 f > # ./cp f g > # ls -l g > -rw-r--r-- 1 root staff 2 Jan 26 12:29 g
That suggests that the bogus group is set by cp's open call. I suspect some sort of ACL mechanism that specifies "staff" as the default group -- or maybe some rule says "inherit group from parent directory". Do you see the same behavior if you run those commands in /tmp? (in place of "./", you'll need "/abs/path-to/coreutils-6.10/src/") _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils