8

One answer to this question mentions the UNIX 03 certification of OSX. Now AFAIK the standard file system of OSX is/was HFS, which "saves the case of a file that is created or renamed but is case-insensitive in operation" (i.e. it's case-preserving but case-insensitive).

Does the UNIX certification or POSIX require a case-sensitive file system?

Martin Schröder
  • 939
  • 1
  • 10
  • 35

1 Answers1

4

According to the POSIX specification:

The system may provide non-standard extensions. These are features not required by POSIX.1-2008 and may include, but are not limited to:

--snip--

  • Non-conforming file systems (for example, legacy file systems for which _POSIX_NO_TRUNC is false, case-insensitive file systems, or network file systems)

--snip--

So it looks like case sensitivity is the norm, but it is possible to support a non-compliant (case-insensitive) file system and still call your product UNIX as long as it can also support case-sensitive file systems.

(edit)

Actually, see this part of the specification:

Two proposals were entertained regarding case folding in filenames:

  1. Remove all wording that previously permitted case folding.

Rationale

Case folding is inconsistent with the portable filename character set and filename definitions (all bytes except <slash> and null). No known implementations allowing all bytes except <slash> and null also do case folding.

  1. Change "though this practice is not recommended:" to "although this practice is strongly discouraged."

Rationale

If case folding must be included in POSIX.1, the wording should be stronger to discourage the practice.

The consensus selected the first proposal. Otherwise, a conforming application would have to assume that case folding would occur when it was not wanted, but that it would not occur when it was wanted.

So it looks like is purposely left ambiguous - it is neither explicitly permitted nor forbidden.

Wyatt Ward
  • 3,962
  • 2
  • 14
  • 21
  • This answer badly misinterprets the quoted excerpts - while POSIX systems are allowed to offer non-conforming extensions, this obviously doesn't make these extensions conforming. – Remember Monica Jun 07 '17 at 16:12
  • Which is why I interpreted it as I did. It isn't explicitly defined affirmatively or negatively. Basically what you said. – Wyatt Ward Jun 08 '17 at 22:53
  • Uhm - the standard explicitly says these extensions are both non-standard and non-conforming. It doesn't get any more explicit or affirmative or negative than that. – Remember Monica Jun 13 '17 at 09:34
  • @MarcLehmann Re-read the first part. The standard actively allows 'non-standard' extensions. `The system may provide non-standard extensions. These are features not required by POSIX.1-2008 and may include, but are not limited to: Non-conforming file systems (for example, legacy file systems for which _POSIX_NO_TRUNC is false, case-insensitive file systems, or network file systems)` – Wyatt Ward Jun 18 '17 at 05:27
  • 1
    @MarcLehmann also, OS X would be noncompliant if this were actively disallowed. But it's a registered compliant UNIX platform. – Wyatt Ward Jun 18 '17 at 05:28
  • 4
    OS X with a case insensitive filesystem is clearly noncompliant. The fact that is is registered in a non-default (but compliant) configuration obviously does not mean every extension of every unix-like OS is suddenly compliant. If your reasoning would be sound, then every extension by any unix-like OS would somehow be compliant... Take Windows for example: Just because microsoft windows has a POSIX-compliant subsystem does not mean the win32 API is somehow POSIX-compliant, it only means that subsystem is. Same for OSX - it's only compliant with case-sensitive filesystem, which it does support. – Remember Monica Jun 19 '17 at 21:11