Talk:Filesystem Hierarchy Standard

Plan 9

I'm removing the sentence about Plan 9, because not only is FHS not a Plan 9 thing, but it also didn't _influence_ Plan 9's names for system folders. Plan 9 existed before FHS. Also, the paragraph, which goes

Modern Linux distributions include a /sys directory as a virtual filesystem (sysfs, comparable to /proc, which is a procfs), which stores and allows modification of the devices connected to the system, whereas many traditional UNIX and Unix-like operating systems use /sys as a symbolic link to the kernel source tree. Likewise, Plan 9 from Bell Labs includes a /net directory.

makes it sound like Plan 9 has /net _in addition_ to all that /sys registry stuff, which it doesn't.

This particular mention of Plan 9 in this article makes no sense whatsoever. It might however make sense in Unix directory structure.

Stuart M (talk) 19:26, 28 June 2010 (UTC)

/usr/local "specific to host"?

The item on /usr/local says "for local data, specific to this host" and the attached footnote (currently 12) expands with "historically and strictly according to the standard, /usr/local/ is for data that must be stored on the local host (as opposed to /usr/, which may be mounted across a network)." "Historically" is as it may be but looking at the standard I can see nothing that that supports the "local host" assertion. Instead it says "[it] may be used for programs and data that are shareable amongst a group of hosts", which would seem to imply exactly the opposite. The unfortunate word "local" seems no to be specifically defined. I will thus plan reword this section unless someone can show me how I'm reading this wrong ... 192.75.165.180 (talk) 20:43, 27 August 2010 (UTC)

The sentence "historically and strictly according to the standard, /usr/local/ is for data that must be stored on the local host (as opposed to /usr/, which may be mounted across a network)", is bogus. Actually, the word "local" here simply referred to the customer organization, as opposed to the Unix vendor. For a long time, the directory didn't even exist out of the box; the sysadmin had to create it. It was common to mount /usr/local/ site wide over the LAN. For more about the history of the filesystem hierarchy, see this article. --Sumafi (talk) 17:30, 3 November 2012 (UTC)

Pronunciation of etc.

I have /never/ heard etc pronounced as et-see. This is after 10 years working with Linux, numerous workshops and classes. I have heard it pronounced as E-T-C and sometimes as etcetera. Not sure what wiki policy is on pronunciation guides (and much too lazy to look it up), but I have found that uncited pronunciations are usually reflecting the bias of a particular community of speakers, and usually there is more than one accepted pronunciation. Tagged as citation needed, but probably worth deleting in the absence of a citation 60.240.207.146 (talk) 00:25, 5 March 2011 (UTC)

I agree that this seems suspicious (I've never heard it that way over an even longer time). I guess it's a possible pronunciation, but it's uncited and obviously not common knowledge (even contradicts it), so I'm going to remove it. Definitely not critical to the article at hand, so no need to keep a trivial contested detail for now. DMacks (talk) 18:43, 12 March 2011 (UTC)

Recursive link

"/var/tmp/", which is linked to on this page, redirects to this (same) page. — Preceding unsigned comment added by 173.242.240.81 (talk) 22:25, 25 November 2012 (UTC)

"/tmp" has the same problem; User:Calinucs replaced the /tmp link with a link to tmpfs, but the FHS doesn't say that /tmp has tmpfs mounted on it (even though that might be the case in practice), so that's not really the right fix. The right fix for both /tmp and /var/tmp is to get rid of the link; I did that for both. (I also fixed both of them to point to Unix directory structure, as both /tmp and /var/tmp long antendate the FHS.) Guy Harris (talk) 17:30, 2 December 2012 (UTC)

Agree about the redirect on /tmp. I just thought that, since FHS is Linux specific, a link to tmpfs (perhaps in the description) would still be helpful for people using this page to learn about Linux (like the description of /boot links to initrd even if initrd is not in the spec). Calinucs (talk) 11:46, 3 December 2012 (UTC)

Maybe something such as "May have tmpfs mounted on it." would be useful; I considered it, but as the FHS doesn't say anything about tmpfs, I wasn't sure whether it was the right thing to do or not (I didn't want readers to think the FHS was speaking of tmpfs - that's an implementation detail). Guy Harris (talk) 19:53, 3 December 2012 (UTC)

Solaris, HP-UX or other certified UNIX systems using the LSB?

The current release of LSB appears to be 4.1 (see https://www.linuxbase.org/lsb-cert/productdir.php?by_lsb), and 5.0 is forthcoming (see http://www.linuxfoundation.org/collaborate/workgroups/lsb). Incidentally, Sun used it for the Java Desktop System. Oracle, of course, uses it. TEDickey (talk) 18:40, 15 February 2015 (UTC)

The Linux FHS is based on a standard agreed on by UNIX vendors (under Sun leadership) around 1988, where e.g. /usr/local was outdated and /opt was introduced. The Linux FHS is however in conflict with Solaris (e.g. as it re-introduced the long outdated /usr/local, but also e.g. because of wrong numbering in the manual pages). I recommend you to read the FHS standard to understand that it contains claims that are in conflict with the filesystem layout of Solaris and at least HP-UX. The fact that Solaris introduced /media is definitely not a proof for your claim. Schily (talk) 10:56, 16 February 2015 (UTC)

I pointed to a few sources; your reply provides no sources. No facts from you have been forthcoming TEDickey (talk) 23:33, 16 February 2015 (UTC)

You did not give a single source to verify you false (see my explanations) claim "Sun and Oracle use the Linux FHS". Schily (talk) 09:37, 17 February 2015 (UTC)

The first link above cites both. Before spewing accusations, you might try reading the suggested link. I found more, but kept my response brief and to the point. You might also try keeping to the point. TEDickey (talk) 09:07, 18 February 2015 (UTC)

We are talking about the relevance of the Linux FHS standard for UNIX - did you miss this main topic? It seems that you did not read your own citations, otherwise you did know that it does not list a single UNIX but only Linux distros. Please try to understand what a trustworthy on-topic citation is. So please do not try to play for time with off-topic responses. Schily (talk) 09:47, 18 February 2015 (UTC)

The current release of the LSB might be 4.1, but the article on the FHS makes no claim as to the current LSB release. The current release of the FHS is 2.3 (see http://refspecs.linuxfoundation.org/fhs.shtml); the LSB and FHS version numbers aren't connected. Guy Harris (talk) 11:03, 18 February 2015 (UTC)

Well, the original question (that caused this talk topic) was whether there is a real UNIX that fully follows the Linux FHS standard. All I can see is that UNIX partially met FHS requirements because FHS was derived from the filesystem structuring standards of the UNIX vendors, but there is no UNIX that completely follows FHS. Do you have information about this? If there is no evidence regarding UNIX, I like to mark the FHS article as Linux specific. Schily (talk) 11:13, 18 February 2015 (UTC)

As stated, that would be WP:OR. We don't create new information for any reason, including the absence of other information. So if there's a WP:RS which clearly analyzes the OS landscape and states such things, then maybe we could say that that RS says that. But that's a huge idea that probably bears analysis by a lot more than one RS, and ultimately isn't true as you've literally stated it. That would amount to something like a Reception section though, because the standard is what it is. It's a neutral thing, and adoption is completely separate. — Smuckola (Email) (Talk) 11:21, 18 February 2015 (UTC)

The current text in the article claims that this is a standard for UNIX systems. As long as there is no verification for this claim, it must be seen as unverified WP:OR and thus is subject for removal. Schily (talk) 11:32, 18 February 2015 (UTC)

Yeah it says that, because that's exactly what it is. That's not a matter of controversy; it's an a priori fact just like its very name, as stated in the standard itself. The article doesn't say that it's adopted by any particular system; it's just a standard that's offered to any given system. I don't know what you're asserting, but it sounds like you're talking about a claim of adoption, which I'm not seeing anywhere in this article. Right? Am I missing something? — Smuckola (Email) (Talk) 11:39, 18 February 2015 (UTC)

So in other words, no it isn't OR, and the only citation needed is the standard itself which has always been there. The tag you're putting in there is totally inappropriate, both because the citation already exists and because citations are not absolutely required in a lead section. I personally like citations everywhere, but not necessarily in the lead when it comes to simple, obvious, and abundantly cited facts. — Smuckola (Email) (Talk) 11:45, 18 February 2015 (UTC)

If it is not implemented by any UNIX system, then it must be seen as an unaccepted standard. With this background, it is irrelevant whether a self-claimed statement mentions UNIX. If there is no reliable other source, this claim must be seen as irrelevant. You of course are welcome to write a variant of the WP text that explains that FHS likes to be a UNIX standard but is not accepted by UNIX vendors. Schily (talk) 12:04, 18 February 2015 (UTC)

Ok. Well, that's obviously what the current text means, and I'm sorry to say that what you're saying is highly pedantic. It isn't a claim. It's a basic description. The text already says what you're saying that it should say. You're pretty much conflating a proposal with a nonexistent declaration of adoption. It's a standard, which the article clearly states isn't even uniformly followed amongst the systems its was most emphatically intended for. It says all of this throughout the article body, such as "When the FHS was created, other UNIX and Unix-like operating systems already had their own standards." This is exactly why citations aren't needed in this lead, as it says in WP:CITELEAD. The statement can be made more explicit with the word "intended" such as this: The '''Filesystem Hierarchy Standard''' ('''FHS''') is intended to define the [[directory structure]] and directory contents in [[Unix]] and [[Unix-like]]... So with respect, the presence of the "citation needed" warning is mistaken and must be removed. Thanks! — Smuckola (Email) (Talk) 12:53, 18 February 2015 (UTC)

To declare how something must be seen, is called POV-pushing, in violation of WP:NPOV. There is no such "how it must be seen" in an encyclopedia. And there is no such claim as you state, in the first place. It's a neutral description of a notable subject. Yours is the only claim here. — Smuckola (Email) (Talk) 13:18, 18 February 2015 (UTC)

That's a rather long digression. As I mentioned at the beginning, Sun used the LSB (which encompasses FHS) for Java Desktop System 1.3, and commented that Oracle (which bought Sun and got Solaris more or less as a side effect), uses LSB in its own product. Both of those statements were disputed and an unsourced statement was injected claiming that LSB was due to Sun (on the one hand disparaging LSB and then taking credit for it). Here are a couple more links to keep the discussion going:

• http://www.theregister.co.uk/2002/08/16/lsb_certifications_confuse_suns_linux/
• http://h21007.www2.hp.com/portal/download/files/unprot/solaris_linux.pdf TEDickey (talk) 01:12, 19 February 2015 (UTC)

The first of those doesn't speak of Solaris at all, just of Sun's Linux distribution. The second of those doesn't speak of the LSB in the context of Solaris.

As for the Java Desktop System, the article speaks of JDE 2 as being available for Solaris and Linux; the certification probably just means that the Linux version of the Java Desktop System is LSB-compliant, i.e. that it should work on all LSB-compliant distributions. There was also a version that worked on Solaris, but that doesn't necessarily mean that Solaris conforms to the LSB.

So:

1) the fact that the LSB is up to version 4.1 doesn't make anything in this article stale unless version 4.1 of the LSB refers to a released version of the FHS later than 2.3;

2) Sun most definitely did use the LSB;

3) however, there's nothing I can find to say that they used it in Solaris;

4) Oracle may use it in Oracle Linux, but there's nothing I can see that indicates that they use it in Solaris. Guy Harris (talk) 01:27, 19 February 2015 (UTC)

Hi, thank you for your statements. It is obvious that the JDS FHS certification is for a Linux variant and I already mentioned that Sun introduced /media on Solaris for the purpose of making JDS usable on Solaris without having different paths on Linux vs. Solaris. This was possible as Sun decided to move from "volmgt" to the non broken parts of "hald" (the Sun CD insertion detection code from the old volmgt in the disk driver was retained to avoid the known Linux hald bugs on Solaris that still survived in recent Linux versions and cause coasters when writing CDs). Other parts of the Linux FHS are however in conflict with the filesystem hierarchy standard used by various UNIX vendors and this is why I suspect that no UNIX vender is interested in Linux FHS as long as the conflicts are not solved in the Linux FHS. BTW: As my original goal was to find a proof on whether there is a certified UNIX using FHS, I partially modified the subject line. Schily (talk) 09:33, 19 February 2015 (UTC)

The only "obvious" aspect of your comments is that you are not bothering to cite any reliable source of information, and the comments are purely an opinion. TEDickey (talk) 02:06, 20 February 2015 (UTC)

From your repeated behavior in the past, we know that you still need to learn how reliable sources work. Using citations to self-claimed statements is definitely not reliable and this is why I like to either get a verification for the claim in the current article (using a reliable source) or remove the self-claimed statements. Schily (talk) 10:47, 20 February 2015 (UTC)

I see... However, you provide few sources, dismiss (in various derogatory terms) sources provided by others, and the overwhelming majority of your edits are self-promotional, e.e., providing links to your own website. A casual reader might not understand what your comment above actually means. TEDickey (talk) 00:47, 21 February 2015 (UTC)

The Linux FHS is based on a standard agreed on by UNIX vendors (under Sun leadership) around 1988 Correct, in that some of the directories, such as /var and /usr/share, in the FHS originated in that standard, although I don't currently have any sources for it. At least one motivation for the design was to split "stuff that's specific to a machine" and "stuff that could be stored on a file server and be mounted read-only on other machines"; that was done as part of Sun changing the way they handled diskless workstations to use only NFS, without the old "ND" (network disk) protocol, with the server offering per-machine directories to mount for the first set of stuff and both universal and per-instruction-set stuff to mount for the second set of stuff. ("/usr/share" was for stuff that could be used regardless of the client's instruction set, e.g. most text files, and binary files in a byte-order-etc.-independent format.) See, for example, pages 19-21 and Appendix A of Installing the SunOS 4.0.3 (unfortunately Bitsavers doesn't have the 4.0 installation manual, which Release 4.0 Change Notes for the Sun Workstation says has that information as well).

But, again, that needs sources, not just memories from 35 years ago. The installation document there should help, although what I'd also like would be the original Sun proposal that I remember from when I was in the OS group there, and information about other vendors atoption of it.

The FHS probably picked up stuff from what existing UN*Xes were doing, including the Sun changes.

as it re-introduced the long outdated /usr/local

Because, much though Sun might have wanted to promote /opt, a lot of free software, at least, continued to install in /usr/local, so, "outdated" though it might have been, it wasn't going away and didn't go away. Guy Harris (talk) 22:42, 25 September 2023 (UTC)

/usr/local is the default prefix used by GNU Automake. That's probably why a lot of software is installed there. — Vincent Lefèvre (talk) 10:22, 27 September 2023 (UTC)

Need to update page to reflect FHS 3.0 updates

Many of the topics discussed in the FHS Compliance section (such as /run and /sys) have been adopted by FHS 3.0. Need to update this article to reflect those changes. — Preceding unsigned comment added by Nerdenceman (talk • contribs) 17:15, 20 May 2015 (UTC)

I concurr, for instance /etc/opt is not part of the 3.0 revision, it had been proposed and rejected around version 2 - it is awkward to have it outdated - wikipedia is a reference over source documentation for my junior engineers ^^ — Preceding unsigned comment added by 176.158.145.173 (talk) 15:38, 19 November 2018 (UTC)

Should be integrated in the articel

The positions of the BSDs:

https://lists.freebsd.org/pipermail/freebsd-fs/2011-May/011444.html

https://mail-index.netbsd.org/tech-userlevel/2011/05/10/msg005051.html

http://openbsd-archive.7691.n7.nabble.com/Filesystem-Hierarchy-Standard-FHS-and-OpenBSD-td152188.html

--Darktrym (talk) 16:47, 5 June 2015 (UTC)

This is why I added a tag to the claim that LSB is something for UNIX...I don't know a single UNIX system that follows LSB and it seems that LSB is a NIH-me-too action on a template that was written around 1988 by Sun for SunOS-4.0. Schily (talk) 12:30, 8 June 2015 (UTC)

mount point for permanent disks?

If /mnt is for temporary file systems and /media for removable disks, where is the mount point for permanent hard disks, like a NTFS disk? J-m.s (talk) 09:49, 5 June 2016 (UTC)

I had the same question. All I can say, from personal experience, is that I have a flash drive for my OS and my hard disk for data is mounted at /mnt/dat. It seems to me that the system install did this automatically. (Mint 17.1) danindenver (talk) 18:11, 13 August 2016 (UTC)

Same question like for database files for an application shared among several groups of users, but not all users of the system. DGerman (talk) 17:06, 28 November 2018 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified 2 external links on Filesystem Hierarchy Standard. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20160310144541/http://www.debian.org/doc/debian-policy/ch-opersys.html to http://www.debian.org/doc/debian-policy/ch-opersys.html
• Added archive https://web.archive.org/web/20050508015157/http://ftp.gwdg.de/pub/cLIeNUX/descriptive/DSFH.html to ftp://ftp.gwdg.de/pub/cLIeNUX/descriptive/DSFH.html

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

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.—InternetArchiveBot (Report bug) 13:21, 9 December 2017 (UTC)

First one works, but the policy moved, so I updated the link; second one works. Guy Harris (talk) 18:42, 9 December 2017 (UTC)

Indentation in table in Directory column

Since the entries in Directory represent fully qualified directories, it seems irritating to me to additionally indent them. I've seen an indented-only version of similar information, but it doesn't seem very accessible because of the different height of the cells in the Description column. I would therefore suggest removing the indentation in this article. Please let me know what you think of this. Thanks --Uncopy (talk) 14:31, 30 June 2023 (UTC)

 Done I agree, the indentation looks bad and probably harms accessibility. It's gone now. Dexxor (talk) 20:48, 1 July 2023 (UTC)

Thanks a lot. --Uncopy (talk) 21:02, 1 July 2023 (UTC)

/mnt as a temporary mount point

That use of /mnt dates at least back to Version 7 Unix. See, for example, page 18 of the Australian UNIX User's Group Newsletter, Volume III, No III, using /mnt as a temporary mount point, in the 1980 documentation of a stripped-down version of V7 UNIX from Heriot-Watt University. Guy Harris (talk) 02:16, 31 August 2024 (UTC)

Fair enough, that is a nice archive. Perhaps you are considering the greater time span the life of the entire system. Perm mounts would be more like /home /var/log /tmp and / itself. Random or system mount point seems ideal, pretty sure one needs to be root to do that. Tomachi (talk) 19:34, 17 September 2024 (UTC)

Perhaps you are considering the greater time span the life of the entire system Presumably you're referring to the lifetime of a mount. Throughout my time using Unix-like systems, dating back to Bell Labs UNIXes and modified versions of same, I tended to use it when I needed to mount something - whether it's a local volume or an export from a file server - for a short period of time. I don't know whether the Bell Labs folks ever documented the purpose of /mnt, but I suspect "mount something for a short period of time" was the original intent.

Random or system mount point seems ideal "Mount point for temporarily mounting file systems" sounds ideal to me.

pretty sure one needs to be root to do that. Depends on the operating system. macOS allows user mounts, although the user has to be the owner of the mount point directory (and, at least in newer versions of macOS, there is no /mnt and / is mounted read-only and "sealed", which I think means only programs signed by Apple can write to it). I tended to have the root password on the systems in question. Guy Harris (talk) 21:03, 17 September 2024 (UTC)