I previously have mentioned that when a directory has the sticky bit set, a file can be deleted only by the owner of the file or the owner of the directory. This behavior is specified by Posix and is now rather universal. However that was not the original purpose of the sticky bit. I see that the Posix definition of the ls command actually calls the sticky bit "the restricted deletion flag". The constant in the C header files for this bit is S_ISVTX. The
svtx stands for
save text and this reveals the original purpose of the bit.
The original idea was that if the sticky bit was set, the text segment of a process would stay in the swap area. This would allow it to be read into memory with a single disk read. Originally, Unix used a filesystem with a block size of 512 and the blocks tended to scatter. So it would take time to collect the text segment and load it into memory. At first there was no paging, only swapping. And to run a program would need to be completely loaded into memory. Now we page-fault a program into memory. Pages are loaded as they are needed. So is the original use of the sticky bit dead? Well, no. It depends on the OS.
With HP-UX, this usage is still alive and is documented on the
HP-UX chmod(2) man page. What use is this? From
The HP-UX Kernel Tuning and Performance Guide via
HP-UX Faq:
"When applications are located remotely, set the "sticky bit" on the applications binaries, using the chmod +t command. This tells the system to page the text to the local disk. Otherwise, it is "retrieved" across the network. Of course, this would only apply when there is actual paging occurring. More recently, there is a kernel parameter, page_text_to_local, which when set to 1, will tell the kernel to page all NFS executable text pages to local swap space."
With Solaris, there is no sign of the original use of the sticky bit, however according to the
Solaris chmod(2) man page:
"If a regular file is not executable and has S_ISVTX set, the file is assumed to be a swap file. In this case, the system's page cache will not be used to hold the file's data. If the S_ISVTX bit is set on any other file, the results are unspecified."
So you will need to check the chmod(2) man page for your particular OS to see what effect, if any, the sticky bit has on a file. Also, be aware that where an effect does exist, the OS may restrict setting a sticky bit to root. For example, with HP-UX, a malicious user could set a lot of sticky bits and run the system out of swap space.
HP-UX actually also has some symbolic links that have the sticky bit set. I will address this below.