Fuchsia 上的子項程序只能存取他們提供的資源，這是一個圍繞「功能型」系統的重要概念。如果將控制代碼提供給服務，則存取該帳號代碼意味著用戶端可以使用。
理論上，這個概念可以應用在檔案系統：如果把控制代碼提供給目錄，它應直接存取該目錄 (以及其子目錄) 中的資源。不過，來自 POSIX 的保留可避免目錄控點與能力系統中的這些概念完美整合：「..」。如果把控制代碼提供給目錄，用戶端可直接要求「..」，而控點將「升級」，存取範圍更廣的父項目錄。因此，這表示您可以任意升級目錄的控制代碼，以便存取整個檔案系統。
傳統上，檔案系統會嘗試使用「chroot」解決這個問題，改變檔案系統根的概念，在常見的路徑週遊情況下，防止「..」以外的存取。不過，這個方法有一些問題：
- Chroot 以「按程式」為基礎，而非根據個別描述元改變根的概念
- Chroots 經常遭到濫用 (例如從區塊根處前往其他開放式控制代碼)
- Chroots 並非「預設為開啟」，因此可能會想程式暗中不使用此類應用程式。
為了克服這些缺陷，Fuchsia 不會在檔案系統伺服器上實作傳統的 點點語意，因為這樣開啟的目錄可以向上週遊。更具體來說，此設定不允許存取「..」，導致用戶端不利於存取父項目錄。這提供了一些可靠的程序建立屬性：如果應用程式管理員只想授予「/data/my_private_data」程序的存取權，只要為該開啟目錄提供一個控制代碼給子項程序即可，這樣系統就會「自動」採用沙箱機制。
沒有檔案系統伺服器可以解析的路徑為何？
特定路徑 (例如「foo/../bar」) 可在沒有符號連結時 (而且在撰寫時也不存在於 Fuchsia 中) 存取，而無需存取檔案系統伺服器即可辨識，例如可轉換為「bar」。在用戶端將路徑型要求傳送至檔案系統伺服器之前，這些路徑可能會經過標準化或清理：在用戶端將路徑型要求傳送至檔案系統伺服器之前：libfdio 程式庫會對最終傳送至函式 __fdio_cleanpath 函式中檔案系統伺服器的任何 fdio 作業。
殼層週遊呢？
例如，如果有人「cd」進入目錄，他們該如何離開？在內部，CWD 的概念並非僅傳至開啟目錄的檔案描述元，而是「檔案描述元」和「被解譯為代表 CWD 的絕對路徑」。如果所有要對這個絕對路徑執行 cd 的作業，一律在用戶端進行解析，而不是傳送至檔案系統伺服器。舉例來說，如果 CWD 是「/foo/bar」，而使用者呼叫「cd .」，則基礎呼叫可能會轉換為「chdir /foo/bar/.」，進而標準化為「/foo」。
這些障礙克服後，移除「..」的優點就會非常大：在能力系統中可自然地存取檔案系統資源、採用沙箱機制的新程序變得更容易，而資源存取也能更自然地透過檔案系統命名空間組合。