Talk:Unix filesystem

This article is within the scope of WikiProject Computer science, a collaborative effort to improve the coverage of Computer science related articles 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.Computer scienceWikipedia:WikiProject Computer scienceTemplate:WikiProject Computer scienceComputer science

???

This article has not yet received a rating on Wikipedia's content assessment scale.

???

This article has not yet received a rating on the project's importance scale.

Things you can help WikiProject Computer science with:

Here are some tasks awaiting attention:

Article requests :
- Requested articles/Applied arts and sciences/Computer science, computing, and Internet
Cleanup :
- Computer science articles needing attention
- Computer science articles needing expert attention
Copyedit :
- Computing
Expand :
- Computer science
Infobox :
- Computer science articles without infoboxes
Maintain :
- Timeline of computing 2020–present
Photo :
- Find pictures for the biographies of computer scientists (see List of computer scientists)
- Computing articles needing images
Stubs :
- Computer science stubs
Unreferenced :
- WikiProject Computer science/Unreferenced BLPs
Project-related :
- Tag all relevant articles in Category:Computer science and sub-categories with {{WikiProject Computer science}}

/sbin's name

Pretty sure that sbin intially stood for static linked binaries. — Preceding unsigned comment added by 173.55.202.3 (talk) 08:16, 3 May 2012 (UTC)[reply]

Given that /usr/sbin also exists, and doesn't contain statically-linked binaries, I'm not sure about that. Guy Harris (talk) 08:35, 19 November 2013 (UTC)[reply]

I always understood it to mean "system administration binaries", but I can't remember ever having an explicit explanation of the name. QVVERTYVS (hm?) 23:16, 19 November 2013 (UTC)[reply]

I have the impression that ("system administration", or something such as that) was what the "s" meant. Guy Harris (talk) 00:09, 20 November 2013 (UTC)[reply]

Ted Dickey

ted dickey? from the "textmode UI" page? what the fuck are you doing here :D :D Delt01 00:42, 11 June 2012 (UTC)

/usr/libexec is in FHS

Early versions of the FHS did not include /usr/libexec; this has since been rectified: http://www.linuxbase.org/betaspecs/fhs/fhs/ch04s07.html

That URL has "betaspecs" in it; the /usr section of the 2.3 version of the FHS doesn't mention /usr/libexec. Is there a later official version of the FHS that includes it, or is this something that will appear in a future release, such as 3.0? Guy Harris (talk) 01:33, 17 November 2013 (UTC)[reply]

So where did /sbin, /usr/sbin, and /var come from?

Actually, unless my memories are too faded, I know where they came from - some people at Sun, around the time SunOS 4.0 was being developed, were making some changes to the directory layout, oriented towards NFS-only diskless workstations (when Sun were killing of the ND remote-disk-access protocol), and one of the changes was the introduction of /var (to separate read-only stuff in /usr, with diskless workstations mounting the same export on /usr, from read-write stuff in /var, with each diskless workstation mounting its own private directory tree on /var), and another was splitting (/usr)/bin from (/usr)/sbin (not related to diskless workstations, but it was a cleanup done while they were at it, so that users who didn't need the administrative tools didn't have to have them in their $PATH).

I seem to remember a document written describing this, and possibly even being circulated outside Sun (possibly amongst licensees of NFS and/or the BSD folk). However, I can't seem to find any trace of that document online. Anybody have less-faded memories than mine? Guy Harris (talk) 01:26, 17 November 2013 (UTC)[reply]

I don't have the document you want, but wouldn't /sbin have been created for the same reason? In 4.3BSD/early System V, /etc contained (writable) configuration files as well as system programs, e.g. /etc/init (now /sbin/init). QVVERTYVS (hm?) 09:58, 18 November 2013 (UTC)[reply]

(/etc/init dates back even earlier, at least to V6.)

Yeah, I think that was another reason for creating /sbin.

I think the split between /sbin and /usr/sbin, and between /bin and /usr/bin, was between "stuff we don't want to require shared libraries" and "stuff that can use shared libraries"; "stuff we don't want to require shared libraries" included "stuff that had to run before we had the file system containing the shared libraries mounted", as well as "stuff we'd like to be able to run without shared libraries so that somebody can install a test build of a shared library after saving the old version, and then back out the change in case the new shared library doesn't work", so SunOS 4.0 had either /bin/mv or /bin/cp for putting the old shared library back.

But this is all fading memories from the mid '80's, which is why I wish the stuff the Sun folks had written about this was available somewhere. Guy Harris (talk) 20:16, 18 November 2013 (UTC)[reply]

The split between /bin and /usr/bin was because they (Kernigan, Ritchies, Thompson, et al) ran out of disk space on the pack (UNIX was written on a PDP!) that had /bin, so they made /usr/bin. See http://lists.busybox.net/pipermail/busybox/2010-December/074114.html which was referenced from http://www.osnews.com/story/25556/Understanding_the_bin_sbin_usr_bin_usr_sbin_Split/ 174.46.232.2 (talk) 18:19, 3 April 2014 (UTC)[reply]

That was the original split. The directory layout was changed in SunOS 4.0, with /sbin and /usr/sbin and /var being introduced, and with, as I remember, a bunch of stuff moved from /bin to /usr/bin. Diskless workstations had /bin on a per-machine root file system and /usr/bin on a shared read-only /usr file system, so they moved as many programs as possible to the shared /usr/bin and moved all writable files from the read-only /usr to a per-machine writable /var. Guy Harris (talk) 19:01, 3 April 2014 (UTC)[reply]

Other Unices, other filesystems

Would it be useful to describe -- or even mention -- variant file systems from other UNIX variants? Specifically, I was thinking of the scheme in SCO Unix which was... er, different. (Probably because it was derived from Xenix, which was its own unique thread of the UNIX split. All I know is encountering SCO 10 years ago, scratching my head over the file system, & bewilderedly muttering, "Okay....") -- llywrch (talk) 20:37, 28 April 2014 (UTC)[reply]

The article discusses variants in filesystems in several places, although so far I've tried to keep it a general overview and I would like to keep it that way rather than discussing every minute detail of every single Unix variant and Linux distro that ever existed. What filesystem differences do you have in mind? The location of standard files? Different file types? The implementation? QVVERTYVS (hm?) 21:35, 28 April 2014 (UTC)[reply]

In the case of SCO Unix -- & I'm going on memory here -- it originally had filesystems with names starting with two digits with a string indicating the purpose of the files in the directory. Then, when Santa Cruz decided to adopt Sys V standards, all of these directories were symlinked to the familiar directories (e.g. /bin, /sbin/, /var, etc.). Every other version of UNIX I've worked with -- Solaris, SunOS, FreeBSD, Linux -- has kept pretty close to the standard, although with the occasional quirk, such as /opt. It was strange enough for the general sense to stick in my mind, despite the fact I've since tried to forget as much about SCO Unix as I could. Had this peculiarity been documented under either Xenix or SCO Unix, I wouldn't think of mentioning it, & I'm not going to push for it even now. However, I think an example or two are worth mentioning in the article as a reason why a filesystem standard was considered a good thing, & likely arose somewhat later in UNIX history. -- llywrch (talk) 16:15, 29 April 2014 (UTC)[reply]

/var/tmp

Schily, why is the description of /var/tmp "superfluous text"? It's in several of the hier(7) manpages cited. QVVERTYVS (hm?) 14:40, 15 February 2015 (UTC)[reply]

If this was for /var/tmp/ than I would expect a clear explanation that describes the difference. Note that /tmp is usually (since 1988) tmpfa mounted while /var/tmp is not. Schily (talk) 15:05, 15 February 2015 (UTC)[reply]

/tmp is described as: "A place for temporary files. Many systems clear this directory upon startup; it might have tmpfs mounted atop it, in which case its contents do not survive a reboot, or it might be explicitly cleared by a startup script at boot time." The contrast with /var/tmp should be clear from the description. If it's not, then why remove it rather than improve it? QVVERTYVS (hm?) 15:08, 15 February 2015 (UTC)[reply]