Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ut-sally.UUCP
Path: utzoo!decvax!decwrl!pyramid!ut-sally!std-unix
From: std-unix@ut-sally.UUCP (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: umasks and P1003 in general
Message-ID: <4108@ut-sally.UUCP>
Date: Mon, 3-Feb-86 16:31:52 EST
Article-I.D.: ut-sally.4108
Posted: Mon Feb  3 16:31:52 1986
Date-Received: Tue, 4-Feb-86 00:01:31 EST
Organization: IEEE/P1003 Portable Operating System Environment Committee
Lines: 75
Approved: jsq@sally.UUCP

[ Comments within square brackets like this are by the poster,
unless they end with -mod, when they are by the moderator.  -mod ]

Date: Sun, 2 Feb 86 14:29:57 pst
>From: aps@DECWRL.DEC.COM (Armando P. Stettner)

Hi.
On the subject of umasks:
I feel that setting the modes of a created file according to a
per-directory umask is a bad idea.

On the surface, it seems like it might be a good idea.  But what this
change does is to remove some of the responsibility and choice of the
program and certain choices of the invoker to place it where such
decisions may have been (perhaps) arbitrarily made by the people who
created and/or own the target directory.  The word `arbitrary' may be
too strong a word but the point I am trying to make is that one
important characteristic of UNIX I have come to respect, appreciate,
and love is that UNIX doesn't do things one doesn't ask it to do nor
does it change or coerce things one produces (files on UNIX vs files on
VMS, as an example of the latter).  Please leave the decisions with the
programmers and the users.

[ The same argument would apply just as well to existing directory
protection modes or the 4.2BSD method of assigning groups to files.
However, the moderator has been sticking his oar in too often lately
and will try to be quiet.  -mod ]

My second objection stems from the thought that it might break a large
set of existing programs (uucp, tip, lp{r,d,rm}, data base subsystems
that run across several UNIX implementations and can not assume certain
record locking facilities, etc).  [Don't nickel and dime me with
implementation details; try and understand what I am trying to say.  I
could check the sources also.  Thanks.]

[ Please elaborate.  -mod ]

On the UNIX IEEE P1003 effort, in general:
This brings me to my next (and maybe the more important) point:  I have
been watching this news group and the standards efforts in general (the
ANSI C effort to a lessor degree).  I am concerned by what I see.  I am
afraid what is happening is sort of what people feared would happen if
a Constitutional Convention were to take place and this is: people now
have a chance to change things.  Intentions are all well and good (I
assume this).  However, things are getting changed.  What I would like
to see in a standard that is attempting to pull together a fragmented
world, such as the UNIX world, is a strong subset of the
characteristics and functions in the more common (popular?) existing
implementations; not one which is implemented by no current version.  I
don't know; maybe this is what is wanted by people on the IEEE
committee:  no current vendor has a head start ...

There are few good things that are done by ``committee'' that I know
of.  This does not mean that I feel that P1003 should be disbanded;
however, I feel the members should be aware of the possible pitfalls of
`by committee' design and work to avoid them.

[ I'm overdue for posting a report on the latest P1003 meeting and will
address this subject.  However, be aware that the newsgroup is not P1003,
and that the committee members constantly raise your concern.  -mod ]


Maybe the resulting work of P1003 should be called UNIX2 or unUNIX
(Onionix?**).

[Needless to say (I know: then why say it?), these opinions are mine
and not necessarily DEC's]

	Armando Stettner
	decwrl!aps, decvax!aps, decwse::aps, aps@berkeley


** Onionix is a trademark of aps enterprises...

Volume-Number: Volume 5, Number 33