Sticky bit?

[Not Marc Spencer]

In article <gilbertd.669645050 at p4.cs.man.ac.uk> gilbertd at p4.cs.man.ac.uk (Dave Gilbert) writes:

   As far as I'm aware what it does is do something like try and keep
   programs in memory -so that say you have 20 people using vi on a
   machine, it ould only hold 1 copy and also it would keep it in
   memory so its available immediatly

   Dave (I think I'm correct?)

While the `sticky bit' is set on a sharable executable file, the text
of that file will not be removed from the system swap area.  Thus the
file does not have to be fetched from the file system upon each
execution.  Shareable text segments are normally placed in a
least-frequently-used cache after use, and thus the `sticky bit' has
little effect on commonly-used text images.

If the sticky bit is set on a file which has none of its execute bits
set, then the kernel's buffer cache will not be used for accesses to
the file.  This can be used on large files (such as swap files for
diskless NFS clients) so that accesses to these files will not blow
everything else out of the server's buffer cache.

A directory whose `sticky bit' is set becomes an append-only
directory, or, more accurately, a directory in which the deletion of
files is restricted.  A file in a sticky directory may only be removed
or renamed by a user if the user has write permission for the
directory and the user is the owner of the file, the owner of the
directory, or the super-user.  This feature is usefully applied to
directories such as /tmp which must be publicly writable but should
deny users the license to arbitrarily delete or rename each others'
files.  A directory whose `sticky bit' is set becomes an append-only
directory, or, more accurately, a directory in which the deletion of
files is restricted.  A file in a sticky directory may only be removed
or renamed by a user if the user has write permission for the
directory and the user is the owner of the file, the owner of the
directory, or the super-user.  This feature is usefully applied to
directories such as /tmp which must be publicly writable but should
deny users the license to arbitrarily delete or rename each others'
files.

--
		  Help stamp out vi in our lifetime!
	Scott Goehring			goehring at gnu.ai.mit.edu
	On exile in Indianapolis, IN