Newsgroups: comp.sys.apollo
Path: utzoo!utgpu!news-server.csri.toronto.edu!helios.physics.utoronto.ca!alchemy.chem.utoronto.ca!system
From: system@alchemy.chem.utoronto.ca (System Admin (Mike Peterson))
Subject: APR's in general (long)
Message-ID: <1991Jan28.190504.28488@alchemy.chem.utoronto.ca>
Organization: University of Toronto Chemistry Department
References: <9101281715.AA16081@hwcae.cfsat.honeywell.com>
Date: Mon, 28 Jan 1991 19:05:04 GMT

In article <9101281715.AA16081@hwcae.cfsat.honeywell.com> rand@HWCAE.CFSAT.HONEYWELL.COM writes:
>There is a subtle bug in Domain/OS with the Unix cp -r command and the
>required ACL entries. It shows itself on directories that have
>explicit owners and protections (ie. no (U) umask or (P) process
>ownership).

We too have had problems with ACLs and cp, but we mainly use pure BSD ACLs
on everything outside of /sys, so things usually end up OK.
I always check the new directory tree after 'cp -r' and rbak, and
sometimes I have had to do recursive chacl's and chown's to fix ownerships
(rbak does not restore BSD initial file/directory ACL's properly and a
'chacl -R -B' fixes them).

>This was reported in APR 5B54C694. Unfortunetly HP/Apollo said "Use
>/com/cpt." Well, how about people who don't load Aegis?

I agree completely - "use Aegis" should never be offered by Apollo
as a response, and certainly should not be accepted by a user.
While I have Aegis loaded on our DN10000 due to other problems, I don't
know how to do anything with it, and don't want to learn. None of our
m68k nodes even have Aegis loaded.
We bought Apollo because they said they had BSD UNIX, and that it worked
WITHOUT needing proprietary OSs.

>The official line from HP/Apollo is that they won't fix it. Here is the
>text of the HP/Apollo response to the APR:
>
>>       <deleted with barely restrained comments>
>
>I must say that once we persuaded HP/Apollo that this actually
>happens, they were pretty good about it. All of the people we talked
>to at the Hot Line agreed that this is a bug. (In fact the person
>who told us that there was an APR already written, asked us not to
>kill the messenger.) I believe that it is somebody in Engineering that
>said it won't be fixed.

I can't count how many APR's I have that "won't be fixed", or that the
product is "working within specification" even though it doesn't work
properly (who makes up the "specifications" and what good are they if
the product still doesn't function reasonably yet meets specs?).

>(On another note, it was very difficult to persuade HP/Apollo that we
>were not some dumb idiots. With the first person, it took 30 minutes
>on the phone working through an example. Then somebody else got it,
>and the response was "Operator error." Even though we had already
>demonstrated the bug to another person there. Days latter, and after a
>fax of a transcript, the second person agreeded with us too.)

I've seen lots of this too, but not nearly as much recently as when SR10 first
came out.
-- 
Mike Peterson, System Administrator, U/Toronto Department of Chemistry
E-mail: system@alchemy.chem.utoronto.ca
Tel: (416) 978-7094                  Fax: (416) 978-8775
