ARFC-1018: Case-Sensitive Asset Pathnames

Status

Draft

Date: 2026-09-05

Version: 0.3

---

Abstract

This ARFC states the rule for comparing pathnames in the asset store: two pathnames name the same object only when they are the same sequence of characters. Letter case, accents, and character width are all significant. Lessons/notes.md, lessons/notes.md and léssons/notes.md are three different paths.

ARFC-1019 generalizes this rule to every value the platform stores; pathnames are its Address class.

The platform has never stated this rule, and today behaves two ways at once: files are compared exactly, while directories are compared under a fold that treats A and a — and also a and á, ae and æ, o and ø — as the same character. This ARFC resolves that inconsistency in favor of exact comparison, and states what an author sees when two names differ only in case.

Table of Contents

• Introduction
• Motivation
  • Current State
  • Prior Art
  • Use Cases
  • Design Goals
• Specification
  • Core Rules
  • What an Author Observes
  • Names Are Not Compared for Similarity
  • Version 1 Scope
• Security Considerations
• Backward Compatibility
• References
• Author

---

Introduction

Instructors and students address their work in the asset store by pathname — a realm, a zone, and a path such as lessons/Prime Numbers/panels/intro.md. Every read, write, delete and directory listing resolves a pathname to an object.

Until now the platform has published no rule about whether two pathnames that differ only in letter case name the same object. In the absence of a stated rule, two different answers took hold in different parts of the system. This ARFC states one rule and applies it everywhere.

Motivation

Current State

• Files are compared exactly. Notes.md and notes.md are two files, and both can exist in the same directory.
• Directories are compared under a fold. Notes/ and notes/ are one directory. Whichever spelling was created first is the one that persists; a later author writing the other spelling is silently served the first.
• The fold is wider than case, and inconsistent. Verified against the platform’s current behavior: A = a, a = á, a = â, ae = æ, o = ø, and A = Ａ (full-width) — while s ≠ ß and i ≠ ı. No author could state that rule from memory, and none was ever documented.
• The disagreement is not merely cosmetic. A save addressed to lessons/… in a zone that already contained Lessons/ produced a request that never completed and had to be cleared by an operator (codermerlin.academy-backend#4707).

Prior Art

Platform	Comparison	Preserves spelling
Linux / POSIX filesystems	Exact	Yes
Object storage (S3 and equivalents)	Exact	Yes
URL paths (RFC 3986)	Exact	Yes
Git index	Exact	Yes
Windows / NTFS	Folded (case only)	Yes
macOS / APFS (default volume)	Folded (case only)	Yes

The desktop operating systems fold; the network, storage and version-control layers do not. No mainstream platform folds accents. A platform whose content is addressed by URL, stored in object storage, and edited from a Linux shell sits on the exact-comparison side of that divide.

Use Cases

1. Naming is consistent with identity. Objects in this platform are also named by URN, and URNs are compared exactly apart from documented exceptions (ARFC-1001). Two ways of naming the same object should not disagree about whether two names are the same.
2. Work moves between the shell and the asset store. Students work in a case-sensitive shell workbench and move files between it and their asset zone. A pair of names that is two files in the shell and one file in the store cannot round-trip without loss.
3. Character identity is stated, not guessed. Treating A, a, á and â as four distinct characters is a rule an author can hold in their head. Conflating the first two but not the last two — or, as today, conflating some accents but not others — is not.
4. Published content is served over URLs. Lesson content published for students is addressed by URL path, where comparison is already exact. A store that folds while its delivery layer does not will eventually disagree with itself.

Design Goals

• One rule for files and directories, in every zone and every operation.
• What an author writes is what is stored, returned, and delivered.
• No silent substitution: a request never resolves to an object the caller did not name.
• A mistake in case surfaces as a name that does not resolve, never as a silent substitution.

Specification

Core Rules

1. Exact comparison. Two pathnames name the same object only if every segment is the same sequence of characters. Case, accents, and character width are significant.
2. Spelling is preserved. The path an author supplies is the path that is stored, listed, and returned.
3. Distinct names are distinct objects. Lessons/ and lessons/ may both exist in the same zone and hold different content.
4. No approximate resolution. A request naming a path that does not exist exactly is refused as not found. It is never served by an object whose name differs only in case, accent, or width.
5. The rule is uniform. It governs files and directories alike, in both personal and realm zones, for reads, writes, deletes, and directory listings.

What an Author Observes

Action	Result
Write Lessons/intro.md, then read lessons/intro.md	Not found
Write Notes.md and notes.md in one directory	Two files, as today
Create Lessons/ when Lessons/ exists	Resolves to the existing directory
Create lessons/ when Lessons/ exists	Creates a second, separate directory
List a directory	Names appear exactly as they were written

Names Are Not Compared for Similarity

The platform makes no judgment about whether two different names were meant to be the same. It does not warn, refuse, or suggest when a new name differs from an existing one only by case, accent, or width. A different name is a different name, whatever the reason for the difference.

This is deliberate. Any similarity check would have to decide which differences are suspicious and which are ordinary — precisely the judgment call whose inconsistency this ARFC exists to remove. A rule that can be stated in one sentence can be relied on; a rule with an exception for names that look alike cannot. Authors and authoring clients are responsible for the names they choose, and a name that turns out to be wrong is corrected the way any other wrong name is.

Version 1 Scope

Included

• Exact comparison for every pathname resolution, files and directories.
• Preservation of the author’s spelling on write, list, and read.
• Not-found for a path that does not match exactly.

Excluded

• Renaming or merging any existing content. No author’s tree changes as a result of adopting this rule.
• Any detection, warning, or refusal based on similarity between names — see Names Are Not Compared for Similarity.
• A case-insensitive search or “find similar names” capability. Useful, but a separate proposal.
• Any change to how names are displayed or sorted in client applications.
• Unicode normalization policy — whether two different encodings of the same visible character are the same name is a distinct question, deliberately left to a later ARFC.

Security Considerations

Silent substitution is removed. Under a folding rule, a request for /Config/keys can be served by an object named /config/keys that the caller never named and may not have expected. Exact comparison eliminates that class of confusion, which matters most where a pathname is used to select something privileged.

Visually similar names remain distinct. Because A and Ａ are now different characters, two directories may look nearly identical in a listing. Authorization is determined by grants on the object, never by name similarity, so this does not create an access-control risk — but interfaces that present paths to a human should not treat visual distinctness as a safety property. Since the platform does not compare names for similarity, a client that needs to draw a reader’s attention to look-alike names is the place to do it.

No new exposure. The rule narrows which names resolve to an object; it never widens it. Any request that succeeds under this rule would also have succeeded before.

Backward Compatibility

• Files: no change. They are already compared exactly.
• Directories: a visible change. A path that previously resolved through a fold now must match exactly. A write that previously landed in an existing differently-cased directory now creates a separate one alongside it, and a read of the spelling that does not exist returns not found.
• No existing content moves. No object is renamed, merged, or deleted by adopting this rule, and no existing pair of names becomes ambiguous under it.
• Clients must preserve the author’s spelling. Any client that constructs paths from user input, or that assumes a fold when re-addressing something it previously wrote, should be reviewed. An authoring client that defaults to a fixed spelling — for example writing lessons/… into a zone that already contains Lessons/… — will create a second tree beside the first, with no error, so which spelling a client writes becomes part of that client’s design rather than something the platform will catch.
• Integrators addressing assets by URN are unaffected; URN resolution does not depend on this rule.

References

• ARFC-1019 — Exact String Comparison and Value Normalization (generalizes this ARFC’s rule to every stored value; pathnames are its Address class)
• ARFC-1001 — URN-Based Asset Identifiers (case rules for URN identifiers)
• RFC 3986 — Uniform Resource Identifier: Generic Syntax (path comparison)
• RFC 8141 — Uniform Resource Names
• codermerlin.academy-backend#4707 — the incident that prompted this ARFC

Author

ĀYŌDÈ Development Team