Home directory files invisible!

[Alan Cox]

> Actually it meant the "text" segment (code and constant data) was
> write-protected during execution, and hence could be shared between
> multiple processes executing the same program. In fact that's why it was
> called the "sticky" bit -- the text segment could stick in RAM even if
> the process was swapped out, and in fact never needed to be swapped out
> because it could always be reloaded from the executable file. This is
> now assumed in the case of modern paging systems, but in the old PDP-11
> it wasn't available on all models and could in some corner cases reduce
> the total amount of virtual memory available to the process (you only
> had a total of 8 physical segments of up to 32Kb each, and the stack
> took up at least 1; later models allowed 16 segments total but 8 could
> only be text and 8 could only be data or stack). Hence it had to be
> user-modifiable.

[although you needed a later 2.x BSD to utilise anything beyond 64K code
64K data. 2BSD could do segment handling stuff [think DOS EMS and try not
to get flashbacks from the horror]

> Now I'm showing my age :-)

The V7 manual doesn't quite agree with you. The sticky bit simply
indicates that the code segment for the binary should be kept around in
memory/swap (fast storage) not discarded. It might get set on a tiny
number of root apps to tune performance.

Anyone who remembers "resident" on the Amiga has the right idea.

It did require on the 11 that the program was split I/D so there was an
unmodifiable code segment but that's an implementation detail for that
architecture. Some Unixen today still honour the sticky bit for
executables - but not many.

As it was only relevant for executables it also got borrowed for other
bits. For directories it indicates that only the file owner can
unlink(remove) files - mostly to fix /tmp. A couple of systems use
it for other 'magic' on non-executable files.

Alan