Re: where user temp files should go, env var names

["Jay R. Ashworth" <jra () BAYLINK COM>]

On Thu, Dec 21, 2000 at 11:30:19AM +0100, Peter J . Holzer wrote:
> On 2000-12-19 00:55:34 -0500, Mike A. Harris wrote:
> > On Tue, 19 Dec 2000, Aaron Drew wrote:
> > > I wouldn't envisage a kernel patch to give each tty or user its own
> > > virtual /tmp being be THAT hard to do.
> >
> > The kernel doesn't differentiate between directories in the
> > filesystem. For all the kernel cares /tmp is where user directories
> > are stored. The kernel doesn't ever know or treat differently any
> > names of dirs in the filesystem.
>
> It shouldn't treat directories differently based on the *name*.
>
> Some unixes have/had a "hidden directories" feature. If a flag is set
> on a directory, any attempt to access the directory would instead
> access one of its subdirectories, depending on some other factor.
> DomainOS and some versions of Minix used this to keep different binaries
> in the "same" place. So, for example, on DomainOS, you would have
> /usr/bin/sysv/ps and /usr/bin/bsd/ps, and depending on whether you
> were running it in SysV or BSD mode, you would get one or the other
> executable when executing /usr/bin/ps. HP-UX inherited the feature from
> Domain-OS, but I can't recall whether it was used for anything useful.
> HP-UX 11 doesn't seem to have it anymore, anyway.
>
> Similarly, instead of a "OS mode", the subdirectory could be based
> on the user-id, so if /tmp has the "hidden-subdirs-are-userids"
> bit set, an access to /tmp/mutt.12345.msg would in fact access
> /tmp/1010/mutt.12345.msg, if my uid is 1010.

Indeed.  but it's worth remembering part of the point is *using* /tmp
in some circumstance is that *it is public*.  It is a good place to
park files which need to be shared by multiple programs being run on
the same machine by different users.

Now, granted, this is no longer the best way to *do* IPC, but it did
get done in the past, and it could be considered part of the "semantics
of Unix", if you like.

> > This definitely has nothing at all to do with the kernel whatsoever.
> > It is a userland programming issue.
> >
> > The kernel does not impose policy decisions upon systems, that is what
> > a sysadmin is for. Fix the programmer.
>
> "mechanism, not policy", right. However, the kernel can provide a
> mechanism. Whether it is the right one (personally, I found those hidden
> directories rather confusing) is debatable. Especially since there is
> another mechanism in userland (the TMPDIR environment variable) which
> has almost the same effect, if it is used.

Yup, usually set by the user, but at least *visible* to that user so
that he or she can unset it if they find the need to run a program that
expects a shared /tmp.

Cheers
-- jra
--
Jay R. Ashworth                                                jra () baylink com
Member of the Technical Staff     Baylink
The Suncoast Freenet         The Things I Think
Tampa Bay, Florida     http://baylink.pitas.com                +1 727 804 5015