디렉토리 항목에 자체 및 상위 링크 (. 및 ..)를 저장하는 이유는 무엇입니까?

파일을 계층 적 디렉토리 구조로 저장하는 것 이상의 기능을 수행하는 일부 임베디드 장치를 대상으로하는 파일 시스템을 고려하십시오. 이 파일 시스템에는 유닉스 및 Windows와 같은 시스템에서 사용할 수있는 많은 작업이 없습니다 (예를 들어, 액세스 권한이 완전히 다르고 디렉토리에 저장된 메타 데이터에 연결되지 않음). 이 파일 시스템은 모든 종류의 하드 링크 또는 소프트 링크를 허용하지 않으므로 모든 파일은 엄격한 트리 구조에서 고유 한 이름을 갖습니다.

디렉토리를 나타내는 온 디스크 데이터 구조에 디렉토리 자체 및 상위 링크에 대한 링크를 저장하면 어떤 이점이 있습니까?

대부분의 유닉스 파일 시스템이 .와 ..디스크의 항목. VFS (일반 파일 시스템 드라이버) 계층에서 처리하지 않는 이유가 궁금합니다. 역사적인 유물입니까? 정당한 이유가 있습니까? 그렇다면 어떤 경우에 정확하게 내 임베디드 시스템과 관련이 있는지 확인할 수 있습니까?

부모 디렉토리에 대한 링크를 갖는 것이 나에게 좋습니다. 그것들이 없다면 항상 전체 디렉토리 목록으로 작업해야합니다. 예를 들어 /home/svick/Documents/로 표현되어야합니다 { /, /home/, /home/svick/, /home/svick/Documents }. 그렇게하지 않으면 부모 디렉토리를 전혀 찾을 수 없거나 매우 비쌉니다. 이것은 비효율적 일뿐만 아니라 위험합니다. 이러한 목록이 겹치는 경우 디렉토리를 이동하면 쉽게 비 동기화 될 수 있습니다.

반면에 상위 디렉토리에 대한 참조가 있으면 더 효율적이고 안전합니다.

실제로 현재 디렉토리에 대한 링크를 가질 이유가 없습니다. 일부 디렉토리를 나타내는 구조가 있고 해당 디렉토리에 액세스하려는 .경우 항상 사용 하지 않아도됩니다. 이 때문에 .링크는 실제로 파일 시스템 구조에 존재하지 않으며 가상에만 있을 것으로 기대합니다 .

특별한 경우가 적습니다. 많은 상황에서 VFS는 다른 디렉토리 이름을 처리하므로 ".."를 처리 할 수 ​​있습니다.

내가 상상할 수있는 유일한 이유는 다음 시나리오입니다.

1. 파일 시스템의 원래 구현은 동일한 디렉토리 형식으로 존재했지만 파일 경로 및 서브 디렉토리 개념은 고려되지 않았습니다 ( PDP-7 Unix 파일 시스템 참조 ).

2. 그런 다음 사람들은 경로 확인과 하위 디렉토리가 유용 할 것이라고 생각했습니다!

3. 이전의 구현과 이전 버전과의 호환성의 일부 금액을 유지하기 위해, 그것은 결정했다 .및 ..다른 모든 디렉토리와 같은 디스크에 저장됩니다.

40 년 된 소프트웨어와의 역 호환성을 위해 쓸모없는 인공물이 남아 있을까요? 믿을만한 시나리오?

참고 : 어쨌든 어딘가에 실제 상위 디렉토리의 inode 번호를 저장해야하므로 (이 시점에서 디렉토리의 하드 링크가 허용되었음을 기억하십시오) 디렉토리 목록에 이러한 항목을 추가하는 것은 완전히 어리석지 않았습니다. 자신의 아이 노드 번호는 좋은 위생 검사 일 수 있습니다.

내가 구현하는 이유가 표시되지 않습니다 .하고 ..오히려 다른 것보다 두 수준을. 그러나 임베디드 시스템을 대상으로하는 경우 절약 할 수있는 모든 계층에서 비용이 발생할 수 있으므로 모든 것을 가능한 한 낮게 구현하려고 시도하는 것이 좋습니다.

.and 의 일반적인 필요성에 관해서는, ..상대 경로가없는 상대 경로를 어떻게 표현 하시겠습니까? ..현재 하위 트리를 떠나는 경로 에는 최소한 필수 요소입니다. 이러한 경로가 필요하지 않은 경우 (트리가 액세스 권한을 인코딩하는 기본 방법 일 수 있습니까?) 필요하지 않습니다 ...