자원 포크
Resource fork리소스 포크는 애플의 고전적인 Mac OS 운영 체제에 있는 파일의 포크 또는 섹션으로, 호환성을 위해 현대적인 MacOS로 옮겨져 데이터 포크 내에 저장된 구조화되지 않은 데이터와 함께 정형 데이터를 저장하는 데 사용되기도 했다.
리소스 포크는 아이콘 비트맵, 창 모양, 메뉴와 그 내용 정의, 응용 프로그램 코드(기계 코드)와 같은 세부 정보를 포함하는 특정 형식으로 정보를 저장한다.예를 들어 워드 프로세싱 파일은 동일한 파일의 리소스 포크에 포함된 이미지를 저장하면서 데이터 포크에 텍스트를 저장할 수 있다.리소스 포크는 대부분 실행 파일에 의해 사용되지만 모든 파일에는 리소스 포크가 있을 수 있다.
Macintosh 파일 시스템
원래 프로그래머 Bruce Horn에 의해 고안되고 구현된 자원 포크는 Macintosh 파일 시스템에서 세 가지 목적으로 사용되었다.
- 필요한 시점까지 모든 그래픽 데이터를 디스크에 저장한 뒤 검색해 화면에 그려 버리고 버리는 데 사용됐다.이 가상 메모리의 소프트웨어 변형은 애플 리사의 메모리 요구량을 1MB에서 매킨토시의 128KB로 줄이는 데 도움을 주었다.
- 모든 사진과 텍스트는 자원포크에 따로 저장되어 있었기 때문에, 비프로그래머가 해외시장용 어플리케이션, 즉 국제화와 현지화라는 과정을 번역할 수 있도록 할 수 있었다.
- 응용프로그램의 거의 모든 구성요소를 단일 파일로 배포하여 복잡성을 줄이고 응용프로그램 설치 및 제거를 단순화하는 데 사용할 수 있다.
리소스 포크는 Macintosh(MFS, HFS 및 HFS Plus)의 시스템 드라이브에 사용되는 모든 파일 시스템에서 구현된다.리소스 포크가 있으면 파일 이름에 파일 확장자가 없어도 시스템에 파일의 올바른 아이콘을 표시하고 열 수 있는 등 다양한 추가 정보를 쉽게 저장할 수 있다.데이터 포크에 대한 액세스는 다른 운영 체제에서 파일 액세스(파일 선택, 바이트 오프셋 선택, 데이터 읽기)와 마찬가지로 작동하지만 리소스 포크에 대한 액세스는 데이터베이스에서 구조화된 레코드를 추출하는 것과 더 유사하다.(마이크로소프트 윈도에도 "리소스"라는 개념이 있지만, 이는 맥 OS의 리소스와 전혀 무관하다.)
자원 포크는 고전적인 Mac 운영체제의 폰트 파일처럼 실제 데이터를 저장하는 데도 사용될 수 있지만, 파일의 메타데이터를 저장하는 데 가끔 사용된다.또한 Macintosh 파일 시스템은 데이터 또는 리소스 포크와는 다른 메타데이터를 위한 별도의 영역을 가지고 있다는 점에 유의하십시오.파일에 대한 카탈로그 항목의 일부로서, 이 항목에 액세스하는 것이 훨씬 빠르다.그러나 여기에 저장되는 데이터의 양은 생성 및 수정 타임스탬프, 파일 형식 및 작성자 코드, 포크 길이, 파일 이름일 뿐이며,일부 파일에는 리소스 포크만 있다.고전적인 68k 애플리케이션은 실행 가능한 코드조차 'CODE' 유형의 리소스에 포함된 하나의 예다.나중에 PowerPC 이진 파일은 실행 가능한 코드를 데이터 포크로 저장한다.
리소스 포크는 파일 시스템 HFS, HFS Plus, APFS에서만 지원되므로 다른 파일 시스템을 사용하는 운영 체제에서는 사용할 수 없다.현재 HFS는 Macintosh 운영체제에서만 지원되고 있는데, 이는 Mac OS를 실행하는 컴퓨터만이 리소스 포크를 사용할 수 있다는 것을 의미한다.Mac OS 시스템에서도 Unix File System이 설치된 경우 리소스 포크를 사용할 수 없다.HFS Plus 파일 시스템에서 데이터 및 리소스 포크 외에 다른 포크도 "멀티 포크" 애플리케이션을 만들 수 있도록 설정을 만들 수 있다.그러나 포크는 다른 운영 체제와의 파일 교환을 어렵게 할 수 있기 때문에 이 기능은 일반적으로 사용되지 않는다.MacOS에서도 리소스 포크는 거의 사용되지 않는다.
현재 macOS는 " 문자로 숨겨진 파일을 만들어 Windows SMB 공유에서 리소스 포크를 지원한다._"는 파일 이름의 시작 부분에 데이터 포크 파일과 같은 디렉토리에 추가되었다.
리소스 식별자
각 자원은 OSType 식별자(4바이트 값)와 ID(16비트 서명한 단어)와 옵션 이름을 가지고 있다.대화 상자에 표준화된 리소스 유형이 있음(').DITL)), 이미지(').PICT'), 소리('), 소리(')snd ') – 실행 가능한 이진 파일(')에 대해서도CODE ') 파워가 등장하기 전까지는PC프로세서는 예외 없이 리소스 포크에 저장되어 있었다.렌더링 윈도우를 위한 서브루틴은 자체 리소스 유형에 저장된다(').WDEF'), 메뉴를 렌더링하기 위한 하위 경로(')MDEF'), 그리고 표준화된 범주 중 어느 하나에도 맞지 않는다고 생각하는 유형의 데이터가 있는 경우, 자신의 유형(예: ')을 사용하는 것이 좋다.John') – 실제로 4자 또는 32비트 값이 리소스 유형 역할을 할 수 있다.이러한 배열을 통해 사용자는 ResEdit와 같은 도구를 사용하여 애플리케이션 파일 또는 시스템 파일의 리소스를 수정하여 개별 애플리케이션뿐만 아니라 운영 체제 자체도 쉽게 사용자 정의할 수 있었다.
애플리케이션이나 다른 코드 내에서 자원은 자원 포크에 저장되는 방법 및 위치에 관계 없이 자신의 유형, ID 또는 이름의 조합을 사용하여 간단히 로드할 수 있다.클라이언트는 다른 힙 기반 데이터처럼 액세스할 수 있는 로드된 리소스로 핸들을 반환한다.이를 용이하게 하는 OS 구성 요소는 리소스 관리자 입니다.자원관리자는 데이터 자체에서 데이터 저장소의 세부사항을 추상화하는 것 외에도 가장 최근에 열린 파일을 맨 위에 두고 열린 리소스 포크 집합을 스택으로 정렬한다.자원을 로드하려고 할 때, 그것은 먼저 스택의 맨 위, (아마도 현재 문서의 자원 포크), 그 다음 것은 아래(응용프로그램의 자원 포크), 그 다음 것은 아래(시스템 자원 포크)에서 볼 것이다.이러한 배치는 매우 강력하다. 예를 들어, 애플리케이션이 표준 시스템 대신 자체 아이콘이나 글꼴을 제공할 수 있도록 지역 자원이 더 낮은 글로벌 자원을 대체할 수 있다.또한, 애플리케이션이 해당 자원이 저장되는 장소나 방법에 관계없이 다른 자원과 동일한 API를 사용하여 시스템에서 리소스를 로드할 수 있도록 한다. 즉, 모든 자원은 동등하게 사용할 수 있고 사용하기 쉽다.시스템은 이로 인해 발생하는 리소스 충돌을 방지하기 위해 일정 범위의 리소스 ID를 예약한다.리소스 관리자 API를 통해 프로그래머는 스택을 조작하고 검색 동작을 수정할 수 있다.
리소스 포크 편집
ResEdit와 같은 리소스 편집기로 리소스 포크를 편집할 수 있기 때문에 소프트웨어를 로컬라이징하고 사용자 정의하는 데 사용할 수 있다.또한 대부분의 리소스 편집기는 데이터의 시각적 편집을 허용한다.MacOS에서는 응용프로그램을 개발할 때 자원을 사용하는 것이 가능하다.그러나 애플리케이션을 UFS에서 사용해야 할 경우 원시 리소스 파일 설정을 사용하여 전체 리소스 포크를 데이터 포크로 이동하도록 구성할 수도 있다.MPW와 애플 개발자 도구 등이 포함된 애플사가 무료로 배포하는 통합 개발 환경에는 레즈(Rez)라는 컴파일러가 포함돼 있다.이것은 레즈(Rez)라고도 하는 전용 언어를 사용하는데, 소스 코드를 컴파일하여 자원 포크를 만드는 데 사용할 수 있다.리소스 포크를 다시 레즈 코드로 변경하는 데 사용할 수 있는 디컴파일러 데레즈도 포함되어 있다.
자원포크의 구조에는 자원 데이터 항목의 위치를 저장하는 「자원 맵」이라고 하는 데이터가 있다.이것은 정의된 ID와 이름에 기반한 자원 데이터에 무작위 액세스를 허용하는 데 사용될 수 있다.리소스 포크는 기본적으로 리소스 맵과 리소스 데이터 자체라는 두 개의 개체로 구성된다고 생각할 수 있지만, 사실 각 데이터 유형은 여러 데이터 항목을 저장하는 계층 구조다.리소스 데이터의 정보가 저장되는 형식은 "리소스 유형"이라고 알려진 정보의 유형을 기반으로 정의된다.리소스 데이터는 종종 다른 유형의 데이터를 참조한다.
MacOS에서 포크 이름은 file/..namedfork/forkname, 예: IMG_0593.jpg 파일의 리소스 포크는 IMG_0593.jpg/..namedfork/rsrc.그ls명령어는 a를 지원한다.-l@파일의 포크를 나열하는 옵션.
리소스 포크 액세스 방법
리소스 포크는 확장 특성 com.apple로 나타난다.ResourceFork.[1]
이전에 리소스 포크는 '리소스 관리자' API를 통해 액세스되었다.이 API는 이제 더 이상 사용되지 않는다.[2]
사용되지 않는 API에서:
- 리소스 포크가 액세스되면 리소스 데이터 및 리소스 맵의 시작 위치와 길이를 포함한 데이터가 헤더에서 읽힌다.
- 읽을 리소스 유형이 지정된 경우 리소스 목록에 해당 유형이 있는지 확인하고 리소스 맵의 시작 위치에서 리소스 참조 목록에서 해당 유형과 해당 오프셋을 포함하는 데이터 항목의 수가 있는지 확인하십시오.
- 리소스 ID, 리소스 이름의 오프셋, 리소스 속성 및 리소스 데이터의 시작 위치에서의 데이터 오프셋이 발견된다.
- 리소스 데이터에 지정된 ID 또는 이름을 가진 리소스 데이터가 있으면 위에서 얻은 오프셋에 액세스하여 데이터 길이를 찾고, 여기에 저장된 모든 데이터를 읽고 반환 값으로 반환한다.
다음과 같은 File Manager APIPBOpenRF()또한 원시 리소스 포크의 액세스가 허용되지만, 이러한 포크는 파일 복사 같은 애플리케이션에만 사용해야 한다. 애플은 리소스 포크를 "제2의 데이터 포크"로 사용하는 것에 대해 강력히 경고한다.
POSIX 인터페이스에서 리소스 포크는 다음과 같이 액세스할 수 있었다.filename/..namedfork/rsrc또는 로서filename/rsrc; 짧은 형태는 Mac OS X v10.4에서 사용되지 않고 Mac OS X v10.7에서 완전히 제거되었다.[3]
리소스 포크의 데이터 유형
자원 포크를 구성하는 가장 작은 원소를 데이터 유형이라고 한다.몇 가지 데이터 유형이 있다.자원포크에 접속한 후 미리 정의된 데이터 유형에 맞는 내용을 읽어보면 그 내용을 알 수 있다.데이터 처리 방법을 명시한 정의를 프로그램 내부에 배치하면 TMPL 자원이라고 불리는 자원도 저장할 수 있다.이 방법을 사용하면 ResEdit와 같은 프로그램으로 볼 때 데이터의 가시성이 향상되어 나중에 편집이 더 간단해진다.매킨토시 플랫폼이 모토로라 기반 프로세서(68k, PPC)에서 비롯되면서 데이터는 빅엔디안 형식으로 디스크에 직렬화된다.
다음은 알파벳 순으로 주요 데이터 유형 목록이다.
| 데이터 유형 | 실명 | 설명 |
|---|---|---|
| 비트 | 이진 비트 | 단일 부울 비트(true 또는 false)를 나타낸다.보통 BB의 수IT는 8의 배수여야 한다. |
| BOOL | 부울 | 부울 값을 나타낸다.그것은 2바이트로 구성되어 있다; 256은 참이고, 0은 거짓이다. |
| CHAR | 캐릭터 | 1바이트 문자를 나타낸다. |
| CSR | C끈 | C 프로그래밍 언어에 사용되는 형식의 문자열을 나타냄: null-terminated of byte. |
| DLNG | 십진수 장단어 정수 | 10진수 긴 단어(4바이트 정수)약 - 21억에서 21억 사이의 값을 나타낸다. |
| 헥스드 | 육각 덤프 | 이 위치에서 끝까지의 데이터가 16진수임을 나타낸다.이것은 코드 자원이나 압축된 데이터를 나타내기 위해 사용된다. |
| HLNG | 긴 단어 16진법 | 이 데이터는 4바이트 16진수 값으로 처리된다.C의 부호 없는 긴 값과 같이 21억 이상의 정수를 나타내기 위해 무엇보다도 사용된다. |
| PSTR | 파스칼 끈 | 첫 번째 바이트가 문자열 길이를 제공하는 Pascal 문자열을 나타낸다. |
| TNAM | 타이프 이름 | 크리에이터 코드와 같은 값을 나타내는 문자열로, 항상 4바이트 길이. |
| 직장 | 직사각형 | 직사각형의 모서리에 대한 좌표(위, 왼쪽, 아래, 오른쪽)를 나타낸다.항상 8바이트 길이. |
주요 리소스 유형
위의 데이터 유형과 마찬가지로 아래의 유형 코드는 리소스 포크 자체 이상의 유형 식별자로 사용된다. 유형 코드는 파일 자체를 식별하고 클립보드의 데이터를 설명하는 데 사용된다.
형식은 4바이트여야 하므로 snd나 STR과 같은 형식은 끝에 실제로 공백(0x20)이 있다.
| 리소스 유형 이름 | 실명 | 설명 |
|---|---|---|
| 알리스 | 가명 | "alias" 속성 비트가 설정된 파일의 리소스 포크에 별칭을 다른 파일에 저장 |
| 앨럿 | 빈틈이 없는 | 응용 프로그램 경고 상자의 모양 정의 |
| APPL | 신청 | 응용 프로그램 정보 저장 |
| BNDL | 보따리를 싸다 | 응용프로그램에 사용되는 파일 형식 아이콘과 같은 데이터 정의 |
| icn | 컬러 아이콘 | 데이터에 사용되는 색상 아이콘 정의 |
| 어수선하게 하다 | 컬러 룩업 테이블 | 데이터에 사용되는 색상 팔레트 정의 |
| CNTL | 통제를 하다 | 창에 배치된 구성 요소의 세부 정보 정의 |
| 코드 | 코드 자원 | 프로그램의 컴퓨터 코드 저장 |
| 필기체 | 커서 | 단색 커서의 모양 정의(8 x 8비트 사각형) |
| 디틀 | 대화 상자 항목 목록 | 창의 구성 요소 정의 |
| DLOG | 대화 | 응용프로그램 대화상자의 모양 정의 |
| FREF | 파일 참조 | 응용 프로그램에서 처리하는 파일 형식 정의 |
| hfdr | 아이콘 풍선 도움말 | 커서가 Finder에 있는 파일 위로 이동할 때 표시되는 Balloon 도움말의 내용 및 모양 정의 |
| icl8 | 8비트 아이콘 목록 | Finder에 표시되는 아이콘 정의 |
| icns. | 32비트 아이콘 목록 | Finder에 표시되는 아이콘 정의 |
| 아이콘 | 아이콘 | 데이터에 사용되는 단색 항목 정의 |
| 친절한 | 파일 설명 | 파일 형식에 대한 설명 정의 |
| 엠바 | 메뉴바 | 응용 프로그램의 메뉴 및 메뉴 모음 정의 |
| 엠디프 | 메뉴 정의 | 응용 프로그램의 메뉴를 정의하십시오.컬러 팔레트와 같이 복잡한 모양의 메뉴를 정의하는 데도 사용할 수 있다. |
| 메뉴 | 메뉴판 | 응용 프로그램의 메뉴 항목 정의 |
| 무브 | 영화 | QuickTime 동영상 저장 |
| 개방된 | 개방된 | 응용 프로그램이 열 수 있는 파일 형식 정의 |
| 픽트 | 사진을 | 파일에 포함된 PICT 이미지 저장 |
| 프리프 | 선호 | 응용 프로그램의 환경 설정 저장 |
| 코를 납작하게 만들다 | 소리가 나다 | 파일에 사용된 사운드 저장 |
| STR | 끈을 매다 | 파일에 사용된 문자열 또는 16진수 데이터 저장 |
| STR# | 문자열 목록 | 파일에 사용되는 여러 문자열 저장 |
| 스타일링하다 | 문체를 하다 | 텍스트의 글꼴, 색상 및 크기와 같은 스타일 정보 정의 |
| 텍스트 | 문자 메시지를 보내다 | 텍스트 저장 |
| TMPL | 템플릿 | 리소스 데이터의 형식 정의 |
| 버시 | 버전 | 파일의 버전 또는 사용 영역 정의 |
| WDEF | 창 정의 | 응용 프로그램의 창을 정의하십시오.지정되지 않은 모양의 창도 정의할 수 있다. |
| 바람 | 창문의 | 응용 프로그램 창의 모양을 정의 |
주요 리소스 편집기
- 다시 편집
- Apple에서 무료로 배포.리소스 데이터의 시각적 편집에 사용할 수 있다.데이터의 구조가 알려지면 다양한 유형의 데이터를 시각적 형식으로 표시할 수 있다.최신 MacOS에서는 실행되지 않는다.
- 주문자
- ResEdit보다 더 많은 유형의 데이터를 시각적으로 편집하는 데 사용할 수 있기 때문에 비싸지만 인기가 있다.
- HexEdit
- 일반적으로 리소스 포크보다 데이터 포크 편집에 더 많이 사용되는 바이너리 편집기.
- 레스나이프
- Mac OS X용 오픈 소스 편집기, 더 이상 유지 관리 안 함.
- 레지클
- 리소스 포크의 리소스를 별도의 이진 파일로 추출하는 동시에 많은 유형을 현대적 개발에 적합한 형식으로 변환하는 MacOS 도구.
- resource_dasm
- MacOS용 오픈 소스 리소스 추출기로, 또한 많은 리소스를 현대적인 형식으로 변환할 수 있다.
호환성 문제
리소스 포크를 사용한 프로그래밍의 복잡성은 AFP, SMB, NFS 및 FTP와 같은 파일 공유 프로토콜을 통해 다른 파일 시스템에 액세스할 때, 비 HFS 볼륨에 저장할 때 또는 다른 방식으로(예: e-메일을 통해) 파일을 다른 시스템에 전송할 때 호환성 문제로 이어졌다.AFP 프로토콜은 기본적으로 Resource Forks를 지원하므로, 리소스 포크는 일반적으로 이러한 볼륨에 그대로 전송되고 서버에 의해 클라이언트에 투명하게 저장된다.SMB 프로토콜은 대체 데이터 스트림(ADS 이후)으로 알려진 매킨토시 포크와 유사한 파일 메타데이터 시스템을 지원한다.MacOS는 Mac OS X v10.6까지는 기본적으로 SMB 볼륨의 ADS에 리소스 포크 저장을 지원하지 않았다.10.6의 업그레이드된 버전을 포함한 이전 버전의 OS에서는 이 기능을 파라미터를 변경하거나 특수 파일을 생성하여 실행할 수 있다.[4]
NFSv3이나 FTP와 같은 네트워크 파일 공유 프로토콜은 파일 메타데이터의 개념이 없기 때문에 리소스 포크를 기본적으로 저장할 방법이 없다.이는 UFS를 비롯한 특정 유형의 로컬 파일 시스템과 대체 데이터 스트림 지원이 실행되지 않는 SMB 볼륨에 쓸 때도 마찬가지다.이 경우, MacOS는 데이터 포크를 하나의 파일로 작성하고, 리소스 포크와 메타데이터는 ""가 선행하는 완전히 별개의 파일로 작성되는 AppleDouble이라는 기법을 사용하여 메타데이터와 리소스 포크를 저장한다._" 명명 규칙.예: 예제File.psd는 데이터 포크를 포함하며 ._ExampleFile.psd는 리소스 포크 및 메타데이터를 포함할 것이다.
호환성 문제는 MacOS 버전, 설정, 파일 시스템 유형에 따라 MacOS가 리소스 포크의 스토리지를 다르게 처리하기 때문에 발생할 수 있다.예를 들어, 10.5와 10.6 클라이언트가 혼합된 SMB 네트워크.새로 설치된 10.6 클라이언트는 리소스 포크를 ADS의 SMB 볼륨에서 찾아 저장하지만, 10.5 클라이언트는 ADS를 무시하고(기본적으로) AppleDouble 형식을 사용하여 포크를 처리한다.파일 서버가 AFP와 NFS를 모두 지원하는 경우 NFS를 사용하는 클라이언트는 AppleDouble 형식으로 파일을 저장하는 반면 AFP 사용자는 리소스 포크를 기본적으로 저장하게 된다.이 경우 클라이언트에게 AppleDouble 형식을 사용하거나 사용하지 않도록 강제함으로써 호환성을 유지할 수 있다.
AFP 지원을 제공하는 많은 파일러는 기본적으로 로컬 파일 시스템에서 리소스 포크를 지원하지 않는다.그러한 경우, 포크는 특별히 명명된 파일, 특수 디렉토리 또는 대체 데이터 스트림과 같은 특별한 방법으로 저장될 수 있다.
또 다른 과제는 비리소스 포크 인식 응용프로그램을 사용하거나 이메일, FTP 등 특정 전송 방법으로 파일을 전송할 때 리소스 포크를 보존하는 것이다.이를 처리하기 위해 MacBinary 및 BinHex와 같은 많은 파일 형식이 생성되었다.명령줄 시스템 도구SplitForks그리고FixupResourceForks리소스 포크의 수동 평탄화 및 병합 허용또한, Macintosh 클라이언트에 파일 시스템을 제공하고자 하는 파일 서버는 파일의 데이터 포크뿐만 아니라 리소스 포크도 수용해야 한다; AFP를 지원하는 UNIX 서버는 보통 이것을 숨겨진 디렉토리로 구현한다.
Carbon API로 작성된 이전 애플리케이션은 현재 Intel Mac에 포팅될 때 잠재적인 문제가 발생할 수 있다.리소스 관리자 및 운영 체제는 '과 같은 공통 리소스에 대해 데이터를 올바르게 역직렬화하는 방법을 알고 있지만snd ' 또는 'moov'. TMPL 리소스를 사용하여 생성된 리소스는 PPC와 Intel 기반 애플리케이션 버전 간의 파일 상호 운용성을 보장하기 위해 수동으로 바이트 교환되어야 한다.(리소스맵과 기타 구현 세부사항은 빅엔디안이지만, 리소스 관리자 자체는 일반 리소스의 내용에 대한 지식이 없으므로 바이트 스와핑을 자동으로 수행할 수 없다.)
Mac OS X v10.4가 등장하기 전까지 MacOS의 표준 UNIX 명령줄 유틸리티(예:cp그리고mv)는 리소스 포크를 존중하지 않았다.리소스 포크가 있는 파일을 복사하려면ditto또는 CpMac 및 MvMac.
기타 운영 체제
그래픽 오브젝트에 대한 자원 관리자의 개념은, 메모리를 절약하기 위해, 스몰토크-76의 제록스 알토에 있는 OOZE 패키지에서 비롯되었다.[5]그 개념은 현재 모든 현대적 운영체제에서 보편적으로 사용되고 있다.그러나, 자원 포크의 개념은 매킨토시 특유의 것으로 남아 있다.대부분의 운영 체제는 리소스를 포함하는 이진 파일을 사용했는데, 이는 기존 프로그램 파일의 끝에 "택시"된다.예를 들어 이 솔루션은 마이크로소프트 윈도우즈에서 사용되며, 자원은 종종 별도의 파일로 남겨지지만 X 윈도우 시스템과 유사한 솔루션이 사용된다.
Windows NTFS는 대체 데이터 스트림이라고 하는 지원을 제공하는 기본 기능인 포크(Mac 파일용 파일 서버)를 지원할 수 있다.Windows 운영 체제 기능(비 Office 파일의 속성 페이지의 표준 요약 탭 등)과 Windows 응용 프로그램이 이를 사용하고 있으며 Microsoft는 이러한 기능을 기본으로 하는 차세대 파일 시스템을 개발하고 있었다.
BeOS의 초기 버전은 리소스 포크와 유사한 방식으로 사용될 수 있는 파일 시스템 내에 데이터베이스를 구현했다.성능 문제는 이후 릴리스에서 복잡한 파일 시스템 속성의 시스템으로 변경되었다.이 시스템 하에서 자원은 맥과 다소 유사한 방식으로 처리되었다.
AmigaOS는 포크 파일을 사용하지 않는다.그것의 실행 가능한 파일들은 내부적으로 코드, 데이터, 그리고 추가 정보를 저장할 수 있는 큰 조각들 (hunk)의 모듈 구조로 나뉜다.마찬가지로, 데이터와 프로젝트 파일에는 IFF 표준으로 코드화된 청크 구조가 있다.다른 파일 형식은 다른 운영 체제와 유사하게 저장된다.엄밀히 말하자면 자원 포크는 아니지만, 아미가OS는 메타 데이터를 다음 이름으로 알려진 파일에 저장한다..info파일..info파일을 식별하는 방법은.info예를 들어, 프로젝트를 디스크에 저장하면 두 개의 파일이 저장된다.MyProject그리고MyProject.info.MyProject실제 프로젝트 데이터가 될 수 있고MyProject.info프로젝트 아이콘, 프로젝트를 여는 데 필요한 프로그램에 대한 정보(아미가에는 애플리케이션 바인딩이 없으므로)를 포함할 수 있음OS), 특수 프로젝트 옵션 및 사용자 의견 .info파일이 Amiga의 데스크톱(Workbench)에서 보이지 않음.바탕 화면에 있는 아이콘(에서 가져온 아이콘.info그 자체로, 사용자가 프로젝트 자체와 관련된 것 둘 다와 상호작용하는 인터페이스 은유다..infofile. 아이콘을 마우스 오른쪽 버튼으로 클릭하여 액세스할 수 있는 대화 상자를 통해 사용자는 에 있는 메타데이터를 보고 수정할 수 있다..info파일.info파일은 명령줄 인터페이스 또는 파일 관리자에서 개별 파일로 볼 수 있다.모던 아미가OS 클론(AROS, MorphOS, AOS4)은 의 구조(메타데이터로 완성)를 상속한다..info오래된 아미가들의 파일들OS 버전 및 표준 PNG 그래픽 파일을 아이콘 비트맵으로 사용할 수 있음.info파일.
NeXT 운영 체제인 NeXTSTEP과 OPENSTEP, 그 후속 시스템인 MacOS, 그리고 RISC OS와 같은 다른 시스템들은 다른 솔루션을 구현했다.예를 들어, 이러한 시스템 하에서 자원은 원본 형식으로 남겨진다. 예를 들어, 사진은 일종의 컨테이너로 인코딩되는 대신 완전한 TIFF 파일로 포함된다.그런 다음 이러한 리소스는 실행 코드 및 "원시 데이터"와 함께 디렉토리에 배치된다.그런 다음 디렉토리("bundle" 또는 "응용프로그램 디렉토리"라고 함)는 사용자에게 응용프로그램 자체로 제시된다.이 솔루션은 리소스 포크와 동일한 기능을 모두 제공하지만, 모든 애플리케이션에 의해 리소스를 쉽게 조작할 수 있도록 한다. 즉, "리소스 편집기"(ResEdit와 같은)는 필요하지 않다.명령줄 인터페이스에서 번들은 일반 디렉터리로 나타난다.파일 시스템(MFS)이 별도의 카탈로그 디렉토리를 지원하지 않기 때문에 이 접근 방식은 클래식 맥 OS에서는 선택사항이 아니었다.카탈로그 파일 지원이 Mac OS에 포함되었을 때 HFS 파일 시스템을 사용하여 리소스 포크는 유지되었다. MacOS는 이전 버전과의 호환성을 위해 Carbon 라이브러리의 일부로 클래식 리소스 관리자 API를 유지한다.그러나 이제 리소스 자체는 파일 시스템 내의 별도의 데이터 파일에 저장될 수 있으며, 리소스 관리자는 이러한 구현 변경사항을 클라이언트 코드에서 숨긴다.
참고 항목
참조
- ^ "Mac OS X Resource Forks". Retrieved 2012-10-22.
- ^ "Resource Manager Reference". Retrieved 2012-10-22.
- ^ "Using Pathnames". developer.apple.com. 2002-12-18. Archived from the original on 2002-12-18. Retrieved 2002-12-18.
{{cite web}}: CS1 maint : bot : 원본 URL 상태 미상(링크) - ^ "OS X v10.5, v10.6: About named streams on SMB-mounted NAS, OS X, and Windows servers". Retrieved 2010-04-19.
- ^ "The Early History of Smalltalk". Retrieved 2008-07-24.
외부 링크
- 리소스 파일 형식 설명
- Apple Developer 리소스 라이브러리: 리소스 관리자 참조
- Apple Developer 리소스 라이브러리: 리소스 관리, 번들
- Grand Unified Model – 리소스 포크의 역사, folklore.org
- Rezycle – 리소스 추출 도구
- Mac OS X 서비스 – 상황에 맞는 메뉴를 통해 파일의 리소스 포크를 삭제하는 Mac OS X 서비스
- Mac OS X 리소스 포크, 확장 속성, NTFS 스트림 및 Dot-Underscore 파일은 어떤가?
- SMB 프로토콜을 사용하여 파일을 저장할 때 "dot-underscore"(._) 파일에 저장되는 정보는?이 정보는 NTFS 파일 시스템에 어떻게 저장되는가?
