Talk:Sticky bit

This is the talk page for discussing improvements to the Sticky bit article.
This is not a forum for general discussion of the article's subject.

Put new text under old text. Click here to start a new topic.
New to Wikipedia? Welcome! Learn to edit; get help.

Article policies

Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL

Computing Low‑importance

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
Low	This article has been rated as Low-importance on the project's importance scale.

Linux Low‑importance

	Linux portal This article is within the scope of WikiProject Linux, a collaborative effort to improve the coverage of Linux on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.LinuxWikipedia:WikiProject LinuxTemplate:WikiProject LinuxLinux articles
Low	This article has been rated as Low-importance on the project's importance scale.

Unnamed section

A few things to cover before de-stubbing:

dates for "historically"
specific OS interpretations of the bit
examples of setting it (chmod calls)
wikilinks
- there must be a page describing the traditional UNIX permission octets
- 'see also' -- ACLs?
No specific mention of Linux and what it might do on that
more precise categorisation (I have to admit I am not sure what appropriate categories may exist) -- Jon Dowland 15:05, 9 March 2006 (UTC)[reply]

Minor Error?

States the sticky bit can only be set by superuser root, however I seem to be able to apply it as a a normal user.

Version Difference or Minor Error?

States "The Linux kernel ignores the sticky bit on files." This is a little confusing. Linux does ignore the sticky bit on files in the "traditional" sense; however, if root places a sticky bit on a file, and if "all others" have rwx; all others can modify the file, but on my Red Hat ES4; users can't delete the file. Example:

[randy@larson test]$ ll
total 0
-rwxrwxrwt  1 root root 0 Feb  7 11:01 some-file.txt
[randy@larson test]$ rm some-file.txt 
rm: cannot remove `some-file.txt': Permission denied

—Preceding unsigned comment added by Randylarson (talk • contribs) 18:02, 7 February 2008 (UTC)[reply]

I tidied up your example so it was formatted correctly -- Jon Dowland (talk) 12:54, 19 February 2008 (UTC)[reply]

What are the permissions on the containing directory? You may not have the right to alter that (which would prevent you removing files):

jon@ANKH:~$ ls -l /tmp/{foo,bar}
-rwxrwxrwt 1 root root 0 2008-02-19 12:55 /tmp/bar
-rwxrwxrwx 1 root root 0 2008-02-19 12:55 /tmp/foo
jon@ANKH:~$ rm /tmp/foo
rm: cannot remove `/tmp/foo': Operation not permitted
jon@ANKH:~$ rm /tmp/foo
rm: cannot remove `/tmp/bar': Operation not permitted

-- Jon Dowland (talk) 12:57, 19 February 2008 (UTC)[reply]

Just wanted to confirm that in the example, it is indeed the parent directory's permissions that control whether or not the file can be deleted, not the sticky bit. Testing on a couple versions of Ubuntu, behavior for files set 0777 and 1777 were identical with regards to deletion (permitted when you have write permission for the directory, denied in both cases when you do not). Jered Heeschen (talk) 21:04, 1 July 2010 (UTC)[reply]

Here's the kicker... This article is really only talking about the "sticky bit" in the sense of it being only right-most bit in the first of four octals one optionally passes to chmod. Many users commonly refer to the other two bit as "owner-sticky" and "group-sticky" bits although they're not actually the "sticky bit", nor has anyone to my knowledge ever formally declared the optional octal to be a "sticky octet". It's just a strange mental trap people have fallen into over the years which is now propagated via lectures. So, while it's true to say that Linux ignores the sticky bit on files, it's a somewhat dangerous statement if the reader thinks of the setgid and setuid bits as sticky bits. There really should be some disambigution here, but not in the sense that there needs to be another "sticky bit" page--I just can't really think of a good way to word such a thing right now. Dagmar d'Surreal (talk) 18:30, 25 February 2018 (UTC)[reply]

Different sticky bits.

There seems to be at least two types if "sticky bit." For reference, see this page: http://www.gnulamp.com/stickybit.html It would appear that we need to have two different "sticky bit" pages with some disambiguation. —Preceding unsigned comment added by 192.25.240.225 (talk) 16:28, 12 February 2008 (UTC)[reply]

Mac OS X

I'm unsure of whether Mac OS X follows the traditional way for executables, or ignores it. See [1], which says "The sticky bit has no effect on executable files. All optimization on whether text images remain resident in memory is handled by the kernel's virtual memory system." But then there's the other man page linked to in the existing article [2], which says "The ISVTX (the sticky bit) indicates to the system which executable files are shareable (the default) and the system maintains the program text of the files in the swap area." 71.90.130.7 (talk) 05:36, 30 October 2008 (UTC)[reply]

Both of the man pages you cite are present and contain those quotes in my Leopard 10.5.5 installation. I would guess that they changed the behavior and forgot to update one of the two. 24.60.192.190 (talk) 05:59, 3 February 2009 (UTC)[reply]

origin of sticky bit

The feature is documented and published for 4.3BSD: is there a published source for SunOS 3.0? If not, there is no reason to suppose that other editors can verify any statements made regarding this. For what it's worth, 4.3BSD's manual page was updated February 2, 1986, while SunOS 3.0 was released 2 weeks later. TEDickey (talk) 21:14, 26 December 2015 (UTC)[reply]

I received my copy of SunOS-3.0 December 27 1985. Schily (talk) 22:32, 26 December 2015 (UTC)[reply]

That isn't verifiable, since you did not mention a published source, is irrelevant. TEDickey (talk) 23:32, 26 December 2015 (UTC)[reply]

That is extremely verifiable: The first Sun 3/75 have been manufactured December 24 1985 and delivered to H.Berthold AG on December 27 1985 together with the required SunOS-3.0. We can safely assume that the other large Sun OEM (Kodak) did receive their samples at the same time and I would call a delivery to more than one external target "publishing". Well, I of course know that you ignore any reality that you don't like... but this is your problem. Schily (talk) 15:27, 27 December 2015 (UTC)[reply]

As usual, you respond with further unsourced statements. If you had a usable source, you would have used it in your other edits. TEDickey (talk) 01:16, 28 December 2015 (UTC)[reply]

As usual, you are not constructive and ignore verifiable facts just because you don't like them. Schily (talk) 11:44, 29 December 2015 (UTC)[reply]

You missed a step: you forgot to point out the verifiable, reliable source to support your comments. TEDickey (talk) 01:37, 30 December 2015 (UTC)[reply]

Added a hatnote for the unrelated concept from floating-point arithmetic

There is also a completely unrelated "sticky bit" technique used in floating-point arithmetic for ensuring correct rounding in addition and subtraction. I've added a hatnote to point to the appropriate section of the floating point article, but sadly the concept is only mentioned there in passing, not explained in detail. There doesn't seem to be any detailed explanation for it anywhere on the English Wikipedia. --Colin Douglas Howell (talk) 19:17, 8 January 2016 (UTC)[reply]

Looking good to me, thank you. — Dsimic (talk | contribs) 13:02, 10 February 2016 (UTC)[reply]

External links modified

Hello fellow Wikipedians,

I have just added archive links to one external link on Sticky bit. Please take a moment to review my edit. If necessary, add {{cbignore}} after the link to keep me from modifying it. Alternatively, you can add {{nobots|deny=InternetArchiveBot}} to keep me off the page altogether. I made the following changes:

Added archive https://web.archive.org/20071120004625/http://www.informatik.uni-frankfurt.de:80/doc/man/hpux/chmod.2.html to http://www.informatik.uni-frankfurt.de/doc/man/hpux/chmod.2.html

When you have finished reviewing my changes, please set the checked parameter below to true to let others know.

Y An editor has reviewed this edit and fixed any errors that were found.

If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—^{cyberbot II}_{Talk to my owner:Online} 07:06, 11 January 2016 (UTC)[reply]

Done, the link above works fine. — Dsimic (talk | contribs) 13:01, 10 February 2016 (UTC)[reply]

Solaris

The article currently says "Solaris appears to have abandoned this in 2005.[citation needed]" for the historical use of saving programs in memory - is there any reason to believe it was still in use that late? A 1998 SunWorld article from Jim Mauro says that even then, "As far as the sticky bit and executable files go, Solaris no longer implements the traditional "save-text-in-swap" functionality that originated with the sticky bit" (archived at http://sunsite.uakom.sk/sunworldonline/swol-04-1998/swol-04-insidesolaris.html since SunWorld/UnixInsider seems to have blocked the Internet Archive). Alanc (talk) 22:30, 12 March 2017 (UTC)[reply]