KR100613788B1 - 파일 관리 방법 - Google Patents

Abstract

애플리케이션들 사이에서 상당히 일반적인 다용성을 갖는 파일 관리 방법은 기록 영역을 낭비하지 않고, 불연속이고 그룹화된 다량의 파일들 및 그룹 정보의 취급을 용이하게 한다. 파일 관리 방법에는 기록 매체가 사용된다.

컨텐츠 관리 파일(CMF)은 필요한 파일 전부와 모든 그룹들에 대해 총괄적으로 제공되고, 애플리케이션은 파일 시스템과의 직접통신 및 필요화(necessitating)없이 CMF를 통해 디스크 상의 다량의 파일을 다룰 수 있으며, 그룹화는 상당히 일반적인 다용성으로 수행될 수 있다.

애플리케이션, 파일 관리 방법, 그룹화, 기록 매체, 컨텐츠 관리 파일(CMF), 파일 시스템

Description

파일 관리 방법{FILE MANAGEMENT METHOD}

본 발명은 기록 매체에 포함된 파일을 관리하는 방법에 관한 것이다.

종래 기술에 있어서, 화상 표시 소프트웨어, 전자 앨범 소프트웨어 등과 같은 애플리케이션이 광디스크, 자기 디스크, 광자기 디스크 등과 같은 기록 매체에 포함된 이동 화상, 정지 화상, 오디오 등의 정보를 취급할 때, 그들은 도 2A에 도시된 바와 같이, UDF, FAT 등과 같은 파일 시스템을 통해 디스크 상의 각 정보에 액세스하도록 되어 있었다.

일부 파일의 그룹화가 프린팅, 리스트 표시, 슬라이드 쇼 등에 필요하게 되었을 때, 멤버 파일을 설명하는 관리 파일 및 필요한 정보는 플레이 리스트 파일, DPOF 파일 등과 같은 각각의 그룹에 따라 준비되었고, 그룹화 파일의 관리가 수행되었다.

그러나, 애플리케이션이 도 2A에 도시된 종래 시스템에서와 같이 각각의 파일에 액세스하기 위해 파일 시스템을 직접 사용할 때, 일반적으로 파일수와 그룹수의 증가로 인해 파일 및 그룹의 관리가 어려워졌고, 필요한 정보를 검색하는데 상당히 많은 시간이 필요하게 된다는 문제가 발생하였다. 또한, 파일 시스템을 통해 파일을 구체화하기 위해, 파일의 타입은 그것의 확장자로부터 판단되어야하고, 동 일한 타입의 확장자를 갖는, 예컨대, 비디오 및 오디오 파일을 서로에게서 구별하는 것은 쉽지 않았으며, 이는 신속한 탐색을 방해하게 되었다.

복수의 기록된 파일의 시계열 재생을 위해, 모든 파일을 액세스함으로써 기록 시간 순서대로 파일을 분류하는 것이 필요했다. 이러한 경우에, 디렉토리 구조 및 파일명을 위해, 임의의 수단을 갖는 시계열 정보를 안전하게 하는 체계를 채용하는 것이 필수적이지만, 이러한 체계는 디렉토리 구조 및 파일명에 있어 자유도를 감소시키므로, 파일 관리의 관점에서 불편했다.

관리 파일을 사용하는 상술한 방법의 경우에, 각각의 그룹에 대해 관리 파일을 준비하는 것이 필요했다. 이러한 이유로 인해, 각각의 관리 파일에 포함된 멤버들 등에 대한 정보를 얻기 위해, 각각의 관리 파일은 명백하게 오픈되고 체크되어야 했고, 이는 파일 관리의 관점에서 불편했다. 또한, 임의의 파일이 관리 파일중 어느 하나에 포함되었는지 여부를 판정하기 위해, 모든 관리 파일이 오픈되고 체크되어야 했으며, 관리 파일에 삭제될 파일이 포함되었는지 여부를 판정하는 것이 어려웠다. 또한, 관리 파일은 관리 파일을 이용하는 애플리케이션에 따라 다른 포맷으로 설명되었기 때문에, 임의의 애플리케이션에 대한 관리 파일이 또 다른 애플리케이션에 적용가능하지 않아, 일반적인 다용성에 있어 문제가 있었다.

관리 파일의 사용에 있어, 각각의 파일을 액세스하기 위해 애플리케이션이 파일 시스템을 직접 사용했기 때문에, 필요한 정보를 검색하기 위해 상당한 시간이 필요하게 된다는 문제에 대한 해결책이 제시되지 않았다.

본 발명은 상기 문제의 관점에서 이루어진 것으로, 본 발명의 목적은 애플리케이션들 사이에서 상당히 일반적인 다용성을 갖고, 다량의 파일 및 그룹 정보의 취급을 용이하게 하는 파일 관리 방법을 제공하는 것이다.

이하, 상기 목적을 달성하기 위한 실시예를 나타낸다.

본 발명에 따른 파일 관리 방법은 정보 기록 매체 상에 기록된 파일들을 관리하는 방법으로, 그룹에 대한 그룹 정보를 포함하는 컨텐츠 관리 파일(Contents Management File)이 제공되는데, 매체에 기록된 복수의 파일은 그룹화되고, 그룹 및 파일의 관리는 컨텐츠 관리 파일에 의해 수행된다.

본 발명에 있어서, 도 2B에 도시된 바와 같이, 필요한 파일 및 그룹 모두를 일반적으로 관리하는 파일인 CMF(Contents Management File)가 제공되는데, 이는, 파일 시스템과의 직접 통신없이 CMF를 통해 디스크 상의 많은 파일을 취급하고, 일반적인 다용성을 갖는 그룹화 등의 필요한 처리를 수행하는 애플리케이션을 허용한다.

도 1은 컨텐츠 관리 파일의 전체 구조를 도시하는 도면.

도 2A 및 2B는 컨텐츠 관리 파일의 역할을 도시하는 도면.

도 3은 관리 정보의 구조를 도시하는 도면.

도 4는 일반 정보의 구조를 도시하는 도면.

도 5는 파일 타입 표의 구조를 도시하는 도면.

도 6은 벤더 ID 표의 구조를 도시하는 도면.

도 7은 블록 타입 표의 구조를 도시하는 도면.

도 8은 정보 블록 타입 기술자(Information Block Type Descriptor)의 구조를 도시하는 도면.

도 9는 정보 타입 리스트를 도시하는 도면.

도 10은 번호 관리 표의 구조를 도시하는 도면.

도 11은 정보 블록 기술자의 구조를 도시하는 도면.

도 12는 블록 상세 데이터의 구조를 도시하는 도면.

도 13은 부모/자식 그룹 정보 블록의 구조를 도시하는 도면.

도 14는 그룹 기술자의 구조를 도시하는 도면.

도 15는 확장된 데이터의 구조를 도시하는 도면.

도 16은 데이터 엘리먼트의 구조를 도시하는 도면.

도 17은 데이터 타입 리스트를 도시하는 도면.

도 18은 분실한 그룹 ID들의 일례를 도시하는 도면.

도 19는 부모/자식 그룹 멤버 정보 블록의 구조를 도시하는 도면.

도 20은 부모/자식 그룹 멤버 기술자의 구조를 도시하는 도면.

도 21은 파일 정보의 구조를 도시하는 도면.

도 22는 파일 기술자의 구조를 도시하는 도면.

도 23은 분실한 파일 ID들의 일례를 도시하는 도면.

도 24는 텍스트 정보의 구조를 도시하는 도면.

도 25는 텍스트 기술자의 구조를 도시하는 도면.

도 26은 디스크에 있어서 디렉토리 구조를 도시하는 도면.

도 27은 디스크의 초기화시에 디렉토리 구조를 도시하는 도면.

도 28은 디스크의 초기와 직후의 CMF 구조를 도시하는 도면.

도 29는 파일 (TAKE0001.MPG)의 추가 직후의 디렉토리 구조를 도시하는 도면.

도 30은 파일 (TAKE0001.MPG)의 추가 직후의 CMF 구조를 도시하는 도면.

도 31은 플레이 리스트 (PLAY0001.XML)의 추가 직후의 디렉토리 구조를 도시하는 도면.

도 32는 플레이 리스트 (PLAY0001.XML)의 추가 직후의 CMF 구조를 도시하는 도면.

도 33은 많은 파일을 포함하는 코멘트를 갖는 자식 그룹의 추가 직후의 CMF 구조를 도시하는 도면.

도 34는 자식 그룹에 멤버를 추가한 새로운 멤버 기술자의 추가 직후의 CMF 구조를 도시하는 도면.

도 35는 코멘트를 갖는 부모 그룹의 추가 직후의 CMF 구조를 도시하는 도면.

도 36은 초기화시에 얻어진 CMF의 전체 용량을 파일업하는 데이터 수를 도시하는 도면.

도 37은 CMF에 새로운 파일 정보 블록을 추가한 경우를 도시한 도면.

도 38은 CMF에 새로운 자식 그룹 멤버 정보 블록을 추가한 경우를 도시하는 도면.

도 39는 CMF에 새로운 자식-그룹/텍스트 정보 블록을 추가하는 경우를 도시하는 도면.

도 40은 빈 영역이 없는 정보 블록에 그룹 멤버 기술자를 추가하는 경우를 도시하는 도면.

도 41은 하나의 파일을 삭제하는 경우를 도시하는 도면.

도 42는 두 개의 멤버 기술자로 이루어진 코멘트를 갖는 하나의 자식 그룹을 삭제하는 경우를 도시하는 도면.

도 43은 CMF 파일의 처리 루틴을 도시하는 도면.

도 44는 새로운 정보 블록을 추가하는 루틴을 도시하는 도면.

도 45는 새로운 그룹 정보/파일 정보/텍스트 정보를 추가하는 루틴을 도시하는 도면.

도 46은 새로운 그룹 멤버 정보를 추가하는 루틴을 도시하는 도면.

도 47은 파일 정보를 삭제하는 루틴을 도시하는 도면.

도 48은 텍스트 정보를 삭제하는 루틴을 도시하는 도면.

도 49는 자식 그룹 정보를 삭제하는 루틴을 도시하는 도면.

도 50은 부모 그룹 정보를 삭제하는 루틴을 도시하는 도면.

도 51은 그룹 멤버 정보를 이동시키는 루틴을 도시하는 도면.

도 52는 그룹에 멤버를 추가하는 루틴을 도시하는 도면.

도 53은 그룹으로부터 멤버를 삭제하는 루틴을 도시하는 도면.

도 54는 CMF에서 기술자들 간의 관계를 도시하는 도면.

도 55는 부모 그룹 리스트를 표시하는 일례를 도시하는 도면.

도 56은 자식 그룹 리스트를 표시하는 일례를 도시하는 도면.

도 57은 파일 리스트를 표시하는 일례를 도시하는 도면.

1. CMF의 구조

우선, CMF(Contents Management File)의 구조를 설명한다. 이하 설명될 디렉토리 구조, 파일명, CMF의 특정값 등은 단지 일례일 뿐이고, 본 발명은 본 실시예와 다른 경우들에 대해서도 적용될 수 있음에 유의해야 한다. 디스크 등에 데이터를 기록하기 위해, FAT, UDF 등의 파일 시스템에 기초한 디렉토리 구조를 사용하는 것과 거기에 파일을 기록하는 것은 공통 업무이다. 도 26은 CMF에 의해 금번에 관리된 디렉토리 구조의 일례를 도시하는 것으로, ROOT 디렉토리[80] 하에, 프린트 등의 관리를 위한 MISC 디렉토리[81], 정지 화상의 기록을 위한 DCIM 디렉토리[82], 및 이동 화상(영화), 오디오, 플레이 리스트 등의 기록을 위한 VIDEO 디렉토리[83]가 존재한다. DCIM 디렉토리[82] 하에는, 그 헤드에 다수의 3 디지트(digits)를 각각 갖는 정지 영상 디렉토리들[84]이 존재한다. VIDEO 디렉토리[83] 하에는, 그 헤드에 다수의 3 디지트들을 각각 갖는 영화 디렉토리[85]들, 오디오 디렉토리들[86], 및 플레이 리스트 디렉토리들[87]이 존재한다. 각각의 디렉토리명의 헤드에 3-디지트 수들이 판정되어, 동일한 3-디지트 수는 동일한 종류의 다른 디렉토리들에 할당되지 않는다. 정지 화상, 영화, 오디오, 및 플레이 리스트 디렉토리 하에는, 정지 화상 파일[92], 영화 파일[93], 오디오 파일[94] 및 플레이 리스트 파일[95]이 각각 기록되어 있고, 이들 각각은 그 헤드에 4개 문자의 알파벳 및 숫자들을 따르는 복수의 4 디지트를 갖는 파일명을 구비한다. 파일명에 있어 4-디지트 수들이 판정되어, 동일한 4-디지트 수는 동일한 디렉토리 내의 동일한 종류의 다른 파일들에 할당되지 않는다. CMF는 이러한 파일들 및 파일의 그룹화를 관리하는 파일이고, CMF는 일반적인 다용성을 가져 복수의 애플리케이션으로부터 액세스될 수 있다.(도 2A 및 2B) CMF 그 자체는 파일 시스템에 의해 관리된 파일[90]이고, 그것은 디스크상 어딘가(본 실시예에 있어 ROOT 디렉토리[80] 하에)에 저장된다.

도 1은 CMF의 전체 구조를 도시한다. CMF는 16 KB의 사이즈를 갖는 하나의 관리 정보(Management Information [1])와 8 KB의 사이즈를 각각 갖는 정보 그룹들의 여러 타입을 조합한 구조를 갖는데, 8 KB 정보의 각 그룹은 정보 블록으로 칭해질 것이다. 정규 정보 블록은 다음과 같은 6 타입, 즉, 부모 그룹 정보[2], 부모 그룹 멤버 정보[3], 자식 그룹 정보[4], 자식 그룹 멤버 정보[5], 파일 정보[6], 및 텍스트 정보[7]를 포함하고, 그룹들은 부모 그룹 및 자식 그룹 층들의 2-레벨 계층에서 생성될 수 있다. 이후 설명되는 것과 같이, 또 다른 정보 블록, 즉, 벤더 상세 정보[8] 및 더미 정보[9]가 존재한다. 벤더 상세 정보[8]는 벤더에 상세한 정보의 기록을 위해 사용되고, 더미 정보[9]는 사전에 영역을 남겨두기 위해 사용된다. 블록에 있어 공간 영역의 관리를 위한 공간 비트맵은 각각의 정보 블록의 맨 위(top)에 놓이고, 데이터 존재 영역에 "1"을 포함하고, 공간 영역에 "0"을 포함한다. 초기 단계에, 각각의 정보 블록에는 공간 영역들이 존재하지만, 정보를 추가한 결과, 정보 블록이 데이터를 채우게 될 때, 8KB의 새로운 정보 블록이 CMF의 맨 끝에 추가된다. 정보 블록의 사이즈는 8KB 이외의 다른 사이즈일 수 있고, 정보 블록은 그들 각각이 서로 다른 사이즈를 가질 수도 있다. 그러나, 각 정보 블록의 사이즈는 기록 매체의 에러 정정 유닛(ECC 블록)을 2의 멱수(1, 2, 4, 8, 16, ...) 중 하나로 나눈 몫(quotient)이다. 즉, ECC 블록이 32KB인 곳에, 각 정보 블록의 사이즈는 32KB, 16KB, 8KB, 4KB, ... 중 어느 하나일 수 있다. 이는 각 정보 블록의 맨 위가 항상 ECC 블록의 맨 위와 일치하도록 허용하고, 이로써, 하나의 정보 블록에 두 개 이상의 ECC 블록을 초과하여 기록되는 것을 막는다.

관리 정보[1]는 전체 CMF의 관리를 위한 부분이고, 일반 정보의 기록을 저장하는 일반 정보[11], 파일의 타입에 대한 표를 저장하는 파일 타입 표[12], CMF를 생성하거나 편집한 벤더의 ID의 표를 저장하는 벤더 ID 표[13], 정보 블록의 타입에 대한 표를 저장하는 블록 타입 표[14], 각각의 정보 블록에서 객체의 수를 관리하는 수 관리 표[15], 및 정보 블록을 관리하는 정보 블록 표[16]로 구성된다. 부모 그룹 정보[2]는 부모 그룹에 대한 정보의 기록을 저장하는 부분이고, 공간 영역의 관리를 위한 공간 비트맵[21]과 실제 정보의 설명을 포함하는 부모 그룹 기술자[22]로 구성된다. 부모 그룹 멤버 정보[3]는 부모 그룹에 포함된 자식 정보에 대한 정보의 기록을 저장하는 부분으로, 공간 영역의 관리를 위한 공간 비트맵[31]과 멤버들의 표인 부모 그룹 멤버 기술자[32]로 구성된다. 한편, 자식 그룹 정보[4]는 자식 그룹에 대한 정보의 기록을 저장하는 부분으로, 공간 영역의 관리를 위한 공간 비트맵[41]과 실제 정보의 설명을 저장하는 자식 그룹 기술자[42]로 구성된다. 자식 그룹 멤버 정보[5]는 자식 그룹에 포함된 파일에 대한 정보의 기록을 저장하는 부분으로, 공간 영역의 관리를 위한 공간 비트맵[51]과 멤버들의 표인 자식 그룹 멤버 기술자[52]로 구성된다. 파일 정보[6]는 파일의 정보의 기록을 저장하는 부분으로, 공간 영역의 관리를 위한 공간 비트맵[61]과 파일 정보로서의 파일 기술자[62]로 구성된다. 텍스트 정보[7]는 텍스트의 정보의 기록을 저장하는 부분으로서, 공간 영역의 관리를 위한 공간 비트맵[71]과 텍스트 정보로서의 텍스트 기술자[72]로 구성된다.

이하, 정보 블록 각각의 상세한 구조에 대해 설명한다. 도 3은 전체 CMF를 관리하는 관리 정보[1]의 구조를 도시한다. 상술한 바와 같이, 관리 정보[1]는 일반 정보[11], 파일 타입 표[12], 벤더 ID 표[13], 블록 타입 표[14], 수 관리 표[15], 및 정보 블록 표[16]로 구성되며, 여기서, 정보 블록 표[16]는 각각의 정보 블록에 대응하는 정보 블록 기술자[17]로 이루어진다. 정보 블록 기술자[17]의 기록 시퀀스는 정보 블록의 기록 시퀀스와 일치하기 때문에, CMF 파일들 중에서 임의의 원하는 정보 블록의 기록 부분은 정보 블록 표[16]를 참조하여 찾을 수 있다. 데이터 사이즈는 다음과 같이 설정된다: 일반 정보[11]에 대해 512 바이트; 파일 타입 표[12]에 대해 1024 바이트; 벤더 ID 표[13]에 대해 512 바이트; 블록 타입 표[14]에 대해 512 바이트; 수 관리 표[15]에 대해 512 바이트; 정보 블록 표[16]에서 각 정보 블록에 대해 8 바이트. B 정보 블록이 존재할 때, 전체 사이즈는 3072+8×B 바이트이다. 따라서, 관리 정보 블록 [1]에 저장될 수 있는 정보 블록 기술자의 최대 수는 1664이다.

도 4는 관리 정보[1]에 포함된 일반 정보[11]의 구조를 도시한다. 이 섹션은 식별 정보와, 데이터 및 시간, CMF에 포함된 정보 블록의 수, 코멘트 등과 같은 일반 정보를 포함한다. CMF 식별자는 CMF의 맨 위에서 파일 식별 정보의 기록을 저장하고, CMF 버전은 CMF 구조의 이후 버전의 경우에 대한 설명을 위해 채용된 구조에 대한 식별 정보를 안전하게 하기 위해 제공된다. 파일 사이즈는 전체 CMF의 사이즈이고, 디스크의 초기 상태에서 64 KB이다. 벤더 식별자 및 제품 식별자는 CMF 생성기 및 생성 기계의 식별을 위한 식별자들로서, 각각의 벤더는 문자열에 자유롭게 할당될 수 있다. 디스크 식별자는 디스크 컨텐츠의 식별 정보를 포함하고, 여기에 UUID(Universally Unique Identifier)가 기록된다. 이러한 정보는 디스크가 초기화될 때 정정되므로, 각 디스크에서 불변하는 것이 아니다. 디스크의 카피가 이루어질 때, 디스크 식별자 역시 그것과 같이 카피된다. 따라서, 디스크 식별자는 각 디스크에 특정되는 것이 아니다. 이러한 디스크 식별자는 2개의 디스크 중 하나가 나머지 하나의 카피로서 생성되는지 여부를 판정하는데 사용될 수 있다.

초기 시간, 생성 시간, 및 수정 시간은 초기화의 데이터&시간, CMF의 생성의 데이터&시간, 및 CMF의 갱신 데이터&시간을 각각 나타내고, 각 정보는 UDF 파일 시스템의 데이터&시간 정보와 동일한 포맷에서 12 byte 정보이다. 초기 시간 및 생성 시간은 통상적으로 동일한 데이터를 포함한다. 디스크의 카피를 위해, 그러나, 초기 시간은 오리지널 디스크의 정보를 포함하지만, 생성 시간은 카피의 생성의 데이터&시간의 정보를 포함한다. 이는, 디스크가 오리지널인지 카피인지 여부는 생성 시간과 초기 시간을 비교함으로써 판정될 수 있음을 의미한다. 디스크의 컨텐 츠가 수정될 때, 수정 역시 CMF에 반영되고, 수정 시간은 갱신된다. 2개 디스크의 디스크 식별자와 수정 시간을 서로 비교함으로써, 그들이 동의한다면, 2개 디스크의 컨텐츠가 동일하다는 것을 판정하는 것 또한 가능하다.

자동 개시 타입, 자동 개시 속성, 및 자동 개시 객체 식별자는 디스크를 삽입하거나 전원을 적용할 때, 자동 개시 정보를 포함한다. 자동 개시 타입은 자동적으로 개시된 데이터(그룹 또는 파일)의 타입을 포함하고, 자동 개시 속성은 자동 개시가 활성화되는지 여부에 대해 설정하고, 자동 개시 객체 식별자는 그룹의 객체 ID 또는 자동적으로 개시될 그룹 및 파일의 수를 나타낸다. 정보 블록의 수는 CMF에 포함된 정보 블록의 수를 저장하고, 코멘트 길이는 코멘트의 길이를 나타내며, 코멘트는 127 바이트의 문자열을 표기한다. 문자열은 파일 시스템에 사용된 것과 동일한 문자 코드를 사용하여 기술된다. 예비 영역은 일반 정보의 전체 사이즈가 512 바이트가 되는 사이즈에서 맨 끝에 제공된다.

도 5는 관리 정보[1]에 포함된 파일 타입 표[12]의 구조적인 예를 도시한다. 이러한 표는 파일의 확장자에 대한 기본적인 표로서, 동일한 확장자(영화, 오디오 등) 등의 서로 다른 타입의 파일 조차 서로 식별된다. 예를 들어, 동일한 확장자 "MPG,"를 갖는 파일의 경우에, 이동 화상 및 오디오(Movie)를 포함하는 파일은 타입 ID=3에 의해 식별되고, 단지 오디오(Audio)를 포함하는 파일은 타입 ID=4에 의해 식별된다. 각각의 확장자는 4 바이트까지의 길이의 저장 영역을 갖고, 4 바이트 보다 짧은 확장에서 초과 영역은 0x00으로 채워진다. 총 256 타입의 확장자를 등록하는 것이 가능하고, 벤더에 대한 지정 확장자는 128 254의 수 내에서 등록될 수 있다. 수 0에서 널(Null)은 확장되지 않은 파일을 나타내고, 수 255에서 지정되지 않음(Not Specified)은 파일 타입 표[12] 내에 확장자가 등록되지 않음을 나타낸다.

도 6은 관리 정보[1]에 포함된 벤더 ID 표[13]의 구조를 도시하고, 이러한 표는 벤더 지정 정보 블록을 생성한 벤더의 독자성(identity) 위해 사용된다. 각 벤더 ID는 4 바이트의 영역을 갖는데, 이들 중 3 바이트는 이는 이더넷 등의 네트워크 카드에서 MAC 어드레스(의 처음 3 바이트)로서 사용되는, IEEE에 의해 관리된 벤더에 특정 ID를 위해 사실상 사용되며, 나머지 1 byte는 0x00으로 채워진다. 총 128 ID를 등록하는 것이 가능하지만, 126 벤더는 사실상 등록될 수 있는데, 이는 ID=0은 공통 정보 타입을 나타내기 위해 사용된 디폴트 ID이고, ID=127은 ID가 없음(정보 없음)을 나타낸다.

도 7은 관리 정보[1]에 포함된 블록 타입 표[14]의 구조를 도시하고, 표는 정보 블록의 타입의 리스트를 저장한다. 도 8에 도시된 2 바이트의 256 정보 블록 타입 기술자를 저장하는 것이 가능하고, 각 기술자들은 정보 타입(도 9)과 벤더 ID(도 6)를 1비트씩 조합한 것을 나타낸다. 정보 타입은 도 9에 도시된 바와 같이, 256 타입씩 분류될 수 있고, 이들 중 타입 0 ~ 127은 시스템을 위해 사용되고 타입 128 ~ 255는 사용자를 위한 것이다.(벤더 지정). 시스템에 대한 타입들 중, 타입 0 ~ 8(통상 객체 정보) 및 타입 127(더미 정보)은 사전에 지정되고, 타입 9 ~126은 예비다. 타입 0, 7 및 8은 이하의 이유로 인해 사용되지 않는다. 블록 타입 표(도 7)에서, 타입 0 ~ 8은 선정되고 0의 벤더 ID(디폴트 ID)와 0 ~ 8의 정보 타입을 포함한다. 블록 타입 0, 7 및 8은 정보 타입으로서 사용되지 않는다.(도 9)

도 10은 관리 정보[1]에 포함된 수 관리 표[15]를 도시하고, 각 블록 타입은 블록 타입 표[14]에 지시된 대응 정보 블록 타입에 포함된 모든 객체의 수를 나타낸다(도 7). 이것은 동일 정보 블록 타입의 모든 정보 블록에 포함된 객체의 총수이고, 예를 들어, CMF는 10 파일 정보 블록[6]을 포함하고, 이러한 경우에 객체의 수는 10 파일 정보 블록에 포함된 모든 파일의 총수이다. 정보 블록 타입에 따른 256 객체 수(도 7)는 2 바이트씩 저장될 수 있다.(또는 65536 객체 내에) 즉, 정보 블록 타입 1 ~ 6의 경우에, 그들의 컨텐츠 각각은 부모 그룹의 수, 부모 그룹 멤의 수, 자식 그룹의 수, 자식 그룹 멤버의 수, 파일의 수, 및 텍스트의 수이다. 정보 블록 타입 0은 사용되지 않지만, 정보 블록 타입, 7, 8에 대응하는 부분들은 부모 그룹 및 자식 그룹을 위한 코멘트의 수를 각각 나타낸다. 이는 다른 것들을 위해 사용된 것으로부터 그룹을 위해 사용된 코멘트의 수를 분리하기 위한 것인데, 이는 텍스트 정보가 그룹 정보 및 그 외의 것들(벤더 상세 정보 및 그 이외)을 포함할 수 있기 때문이다. 그룹 정보 이외의 정보에 사용된 텍스트 기술자의 수는 텍스트의 총수로부터 그룹을 위해 사용된 코멘트 수를 빼는 것에 의해 결정될 수 있다.

도 11은 정보 블록 표[16]에서 엘리먼트인 정보 블록 기술자[17]의 구조를 도시한다. 그러한 정보 블록 기술자[17]의 수집은 정보 블록 표[16]를 구성한다. 블록 타입은 정보 블록의 타입을 나타내고 블록 타입 표[14]에 나타난 값을 포함한 다. 블록 속성은 정보 블록의 속성 정보를 나타내고, 여기 포함된 컨텐츠는 정보 블록의 타입에 따라 다르다. 파일 정보 블록을 위해, 블록 속성은 파일 정보 및 디렉토리 정보 각각이 포함되었는지 여부에 대한 정보를 포함한다. 텍스트 정보 블록을 위해, 블록 속성은 부모 그룹, 자식 그룹, 및 그 외 코멘트 정보 각각이 포함되었는지 여부에 대한 정보를 포함한다. 블록 속성은 공간 비트맵이 포함되는지 여부에 대한 속성 정보를 포함하고, 이는 모든 정보 블록에 공통이다.

블록 사이즈는 정보 블록의 사이즈를 나타내며 2 KB의 정수배로 표현된다. 본 실시예에서는, 모든 정보 블록이 8 킬로바이트의 사이즈를 가지기 때문에 블록 사이즈는 4이다. 기술자(Descriptor) 사이즈는 정보 블록 내에 포함된 하나의 기술자의 사이즈를 나타내며 이를 이용하여 정보 블록 내에 포함된 최대 기술자 수(n) 및 상위 기술자 위치(p)를 계산하는 것이 가능하다(블록 사이즈 = b 바이트, 기술자 사이즈 = d 바이트인 것으로 가정함).

최대 기술자 수 : n = int((b ×8)/(1 + 8 ×d))

상위(top) 기술자 위치 : p = b - d ×n

도 12에 도시된 바와 같이, 시스템 정보 블록(정보 타입 0 내지 127)의 경우, 블록 지정 데이터는 정보 블록에 지정 정보를 나타내며 데이터 길이 및 객체 수에 관한 정보를 저장한다. 데이터 길이는 정보 블록 내의 유효 데이터 길이로서 이는 데이터 중간에 공간 영역이 있는지 여부에 관계없이 마지막 데이터까지의 길이이다. 객체 수는 정보 블록에 포함된 데이터의 수이며 기술자의 수를 포함한다. 각 블록 내의 공간 영역은 각 블록 내의 공간 비트맵에 의해 관리되며, 각 블 록 내의 공간 영역의 수 및 데이터 길이는 전술한 바와 같이 CMF의 헤드에서의 관리 블록에 의해 관리된다. 따라서, 메모리 상에 주재하는 데이터의 부피를 감소시키고 또한 검색량을 감소시키는 것이 가능하다.

각 정보 블록 내의 기록될 수 있는 객체의 수는 각 타입에 대해 고정되기 때문에, 공간 영역의 수는 최대 기록가능 수로부터 객체의 수를 감산함으로써 산출될 수 있다. 또한, 필요한 데이터 길이는 객체의 수에 기술자 사이즈를 곱합으로써 산출될 수 있으며, 이를 데이터 길이와 비교함으로써 데이터의 중간에 공간 영역이 존재하는지 여부를 판별할 수 있다.

도 13은 부모 그룹(parent groups) 및 자식 그룹(child groups)에 대한 일반 정보의 기록을 저장하는 부모 그룹 정보 블록 [2] 및 자식 그룹 정보 블록 [4]의 구조를 나타낸 도면으로 두 블록은 동일한 구조를 가지고 있다. 이는 8 킬로바이트의 정보 블록 내의 64 바이트 유닛(셀)의 부모/자식 그룹 기술자 [24, 44]의 그룹 정보의 표이다. 그룹 정보 [24, 44]의 수집은 부모/자식 그룹 기술자 [22, 42]이다. 부모/자식 그룹 기술자 공간 비트맵 [21, 41]은 64 바이트 유닛의 각 셀이 유효 그룹 정보를 저장하는지 여부를 나타낸다. 127 개의 그룹 정보 피스 [24, 44]가 하나의 정보 블록 내에 최대로 저장될 수 있으며, 각 셀 내의 유효 데이터의 존재 유무는 공간 비트맵 [21, 41]에 의해 16 바이트를 사용하여 하나의 비트/셀 내에서 관리된다. 즉, 유효 그룹 정보는 공간 비트맵 [21, 41] 내의 "1"로 나타나는 비트를 갖는 셀 내에 저장되며 유효 정보가 아닌 것은 "0"을 갖는 셀 내에 기록된다. 따라서, 정보는 "0"을 갖는 셀에 기록될 수 있다. 예비 영역(reserved area) [23, 43]은 공간 비트맵 [21, 41] 내의 64 바이트 유닛의 셀로부터의 초과 영역이다. 부모/자식 그룹 기술자 [24, 44]의 그룹 정보의 수가 G일 때, 유효 데이터 사이즈는 64 + 64 ×G 바이트이다. 본 실시예에서, 부모 그룹 및 자식 그룹의 그룹 기술자의 최대 수는 전체 CMF 각각 내에서 16384이다.

도 14는 그룹 기술자 [24, 44]의 구조를 나타낸 도면으로서, 부모 그룹 및 자식 그룹은 동일한 구조를 갖는다. 그룹 타입은, 그룹이 부모 그룹인지 혹은 자식 그룹인지에 대한 정보와, 그룹이 사용자에 의해 생성되는 사용자 정의 그룹인지 혹은 시스템에 의해 자동으로 생성되는 시스템 그룹인지에 대한 정보를 포함한다. 시스템 그룹의 경우, 그룹의 타입이 기록되며 반면에 사용자 정의 그룹인 경우 사용자는 그룹의 타입을 결정할 수 있다. 본 실시예에서, 시스템에 의해 자동적으로 생성되는 그룹은, 기록 시퀀스에 근거한 날짜 그룹과, 플레이 리스트 내에 포함된 파일의 표로서의 플레이 리스트 그룹을 포함한다. 날짜 자식 그룹의 표는 날짜 부모 그룹이며, 플레이 리스트 자식 그룹의 표는 플레이 리스트 부모 그룹이다. 날짜 자식 그룹의 멤버는 모든 타입의 파일을 포함할 수 있기 때문에, 날짜 그룹의 사용에 의해, 파일의 타입에 관계없이 기록 시퀀스를 재생할 수 있다.

그룹 특성은 그룹의 특성 정보를 포함하는데, 이는 그룹이 삭제된 그룹인지 여부에 대한 정보와, 기록 금지된 특성에 대한 정보와, 대표 썸네일 화상이 그룹 멤버의 썸네일인지 여부에 대한 정보와, 그룹 기술자가 확장된 데이터를 포함하는지 여부에 대한 정보 등이다. 멤버 기술자 ID는 그룹 내에 포함된 멤버의 기록을 저장하는 그룹 멤버 기술자를 특정하기 위한 정보이며, 그룹 멤버 정보 블록 내의 자신의 기록 위치에 의해 표시된다. 이는 전체 CMF에 포함된 그룹 멤버 기술자의 기록 시퀀스에 따라 2바이트의 일련 번호에 의해 표현된다. 번호가 주어지면, 정보 블록 내의 그룹 및 위치를 포함하는 정보 블록을 특정화할 수 있다. 하나의 그룹 멤버 정보 블록은 최대 127 개의 그룹 멤버의 정보를 저장할 수 있다. 예를 들어, 멤버 기술자 ID가 300이면, 이 정보는 세 번째 그룹 멤버 정보 블록 내의 46번째 그룹 멤버의 정보를 나타낸다. 코멘트 ID는 그룹에 부가되는 코멘트를 나타내며, 이는 그룹 표의 표시와 그룹에 대한 검색 등에 사용되며, 코멘트의 내용은 텍스트 정보 내에 있다. 그룹 멤버 기술자의 지정 방법의 경우에서와 같이, 코멘트 ID는 텍스트의 기록 시퀀스에 따라 2 바이트의 일련 번호로 표현되며 코멘트가 없는 경우 0xFFFF를 포함한다.

링크 카운트는 자식 그룹의 경우 부모 그룹으로부터의 기준 링크의 수를 나타낸다. 링크 카운트가 0이면, 자식 그룹은 어떤 부모 그룹에도 속하지 않는다. 자식 그룹의 링크 카운트가 1보다 크면, 부모 그룹으로부터 기준 링크를 가지며 이에 따라 삭제되어도 그 위에 중복 기입하는 것이 금지된다. 즉, 삭제된 영원한 자식 그룹의 위치는, 삭제된 자식 그룹이 속하는 그룹 정보 블록 [2, 4] 내의 공간 비트맵 [21, 41] 내의 사용된 영역("1")으로서 유지된다. 이로 인해, 자식 그룹이 삭제되어 있는 경우, 영원한 자식 그룹이 속해 있는 부모 그룹의 정보 내의 수정에 대한 필요성이 없게 된다. (원래, 부모 그룹에 속해 있는 자식 그룹이 삭제되면, 부모 그룹 정보는 수정되어야 하지만, 부모 그룹에 속해 있는 자식 그룹의 자식 그룹 ID에 대한 검색이 필요하기 때문에 수정에는 소정의 시간이 걸릴 것이다.) 반 면에 부모 그룹이 삭제되면, 각 링크 카운트는 부모 그룹 내에 포함된 자식 그룹에 대해 1씩 감소된다. 그 포인트에서 0의 링크 카운트를 갖는 자식 그룹이 이미 삭제된 것일 경우, 영원한 자식 그룹의 정보의 위치는 공간 비트맵 [21, 41] 내의 공간 영역("0") 내에 설정되어 그 위에 겹쳐 쓰기가 허용된다. 본 실시예에서, 부모 그룹은 다른 그룹으로부터 참조되지 않으며, 따라서 링크 카운트의 값은 부모 그룹에 대해 항상 0이다.

그룹명(Group Name)은 그룹의 명칭을 나타내며, 사용자는, 시스템에 의해 자동적으로 생성되는 그룹을 제외하고는 그룹의 명칭을 자유롭게 설정할 수 있다. 시스템 그룹의 경우, 날짜(YYYY:MM:DD)는 날짜 그룹에 대해 그룹명 내에 기록되며, 디렉토리 번호 및 파일명(nnn:PLAYxxxx)은 플레이 리스트 그룹에 대해 그룹명 내에 기록된다. 그룹명은 유니코드(UDF 파일 시스템의 것과 동일한 문자 코드)에 의해 표현되는데, 여기서 상위 1바이트는 문자 코드의 식별에 사용되며 나머지 영역은 0x00으로 채워진다. 생성/수정 날짜 및 시간은 그룹 정보의 생성/갱신의 날짜 및 시간을 나타내며 이는 UDF의 날짜 및 시간 정보와 동일한 포맷의 12 바이트에 저장된다. 썸네일 멤버 ID는 그룹 표의 표시 등에 사용되는 대표적인 썸네일 화상을 갖는 대표 멤버를 나타낸다. 이 썸네일 멤버 ID(ID=0xFFFF)의 설정없이, 그룹 멤버 기술자 내의 상위 멤버는 대표 멤버로 정의된다. 그룹이 자식 그룹이면, 썸네일 멤버 ID는 파일 기술자에 기록된 파일 번호를 나타낸다. 그룹이 부모 그룹이면, 썸네일 멤버 ID는 자식 그룹 또는 파일을 나타낸다. 지정된 것에 관한 정보는 그룹 특성에 기록된다. 자식 그룹의 기술자의 ID는 자식 그룹의 경우에 주어지며 파일 기술자의 ID는 파일의 경우에 주어진다. 부모 그룹의 대표 멤버가 자식 그룹이면, 대표 썸네일은 대표 자식 그룹의 대표 화상이다. 총 멤버의 수는 이 그룹에 속하는 모든 그룹 멤버 기술자 내에 포함된 총 멤버 수이다.

확장된 데이터는 전술한 바를 제외한 그룹 정보의 저장을 위한 구조로서 도 15에 도시된 구조를 갖는다. 확장된 데이터 내에는 복수 개의 데이터 엘리먼트가 저장될 수 있으며, 모든 데이터 엘리먼트의 사이즈(데이터 길이)의 합은 상위 1 바이트에 기록된다. 도 16은 데이터 엘리먼트의 구조를 나타낸 도면이다. 데이터 타입은 데이터 엘리먼트의 타입을 나타내며, 데이터 길이는 실질적인 데이터의 사이즈를 나타내며 데이터는 실질적인 데이터를 나타낸다. 도 17은 총 256 개의 데이터 타입을 저장할 수 있는 데이터 타입을 나타내며 여기서 타입 0 내지 127은 시스템 데이터를 나타내며 타입 128 내지 225는 사용자 데이터를 나타낸다. 시스템 데이터 중에서 타입 0 내지 4는 사전 정의된 것이며, 이하에서는 각 데이터 타입의 실질적인 데이터 컨텐츠를 기술하기로 한다. 확장된 데이터의 초과 영역의 패딩을 위해, 널 데이터(타입 0)가 확장된 데이터의 맨 끝에 사용된다. 그룹의 타입이 날짜 그룹이며 UDF의 타임스탬프와 동일한 구조를 가질 때 날짜 정보(타입 1)는 생성 날짜 및 시간의 기록을 저장한다. 그룹의 타입이 플레이 리스트 그룹이며 파일 정보 내에 기록된 플레이 리스트 파일의 파일 기술자 ID에 의해 표시될 때 플레이 리스트 정보(타입 2)는 플레이 리스트 파일 ID를 저장한다. 링크 정보(타입 3)는 링크 정보를, 이 그룹과 관련된 다른 객체 기술자에 나타내며 복수의 객체 기술자를 저장할 수 있다. 이 때, 각 객체 기술자는 1 바이트의 정보 블록 타입(도 7) 및 2 바이트의 기술자 ID에 의해 표시된다. 복수 개의 식별 날짜 또는 플레이 리스트 그룹이 존재하고 2 바이트의 기술자 ID에 의해 표시되는 경우, 다음 그룹 정보(타입 4)는 다음 그룹 기술자를 나타내는 데에 사용된다. 벤더 ID(도 6)가 상위 1 바이트에 기록될 때 나머지 사용자 데이터(타입 128 내지 255)는 사용자 지정 정보를 기록하기 위해 예비된다. 확장된 데이터는 24 + 64 ×n 바이트(n은 0 이상)의 사이즈를 갖는다. 확장된 데이터가 하나의 그룹 기술자로부터 겹쳐 쓰기할 경우(n이 1 이상일 때), 오버플로잉 데이터는 그 후 즉시 다음 그룹 기술자 내에 연속적으로 기록된다. 이 때, 확장된 데이터만을 저장하는 그룹 기술자는 그룹 ID를 잃어버리게 된다. (도 18은 그 예를 나타낸 도면이다.)

본 실시예에서, 각 그룹 기술자의 사이즈는 64 바이트이기 때문에, 최대 127 개의 그룹만이 하나의 정보 블록 내에 기록될 수 있다. 그러나, 정보의 일부를 그룹 멤버 기술자에 이동시킴으로써, 하나의 정보 블록 내에 저장될 수 있는 그룹의 최대 수를 증가시키는 것이 가능하다. 예를 들면, 생성/수정 날짜 및 시간과 확장된 데이터는 그룹 멤버 기술자로 이동되며, 그룹 기술자의 사이즈는 32 KB로 감소되며 하나의 정보 블록은 255 개의 그룹을 저장할 수 있다. 또한, 8 바이트의 정보만이 예비 경우, 하나의 정보 블록은 1008 개의 그룹을 저장할 수 있으며, 이에 따라 메모리 상에 기록될 수 있는 그룹의 수를 증가시킬 수 있게 된다. 모든 정보가 그룹 멤버 기술자에 저장되는 경우, 그룹 멤버 기술자 ID(2 바이트)만이 그룹 기술자 내에 유지되며 이는 그룹에 대한 모든 정보를 저장하는 그룹 멤버 기술자의 위치를 나타내기 위한 포인터로서 기능한다.

도 19는 부모 그룹 및 자식 그룹의 멤버 정보의 기록을 저장하는 부모 그룹 멤버 정보 블록 [3] 및 자식 그룹 멤버 정보 블록 [5]의 구조를 나타낸 도면이다. 두 개의 정보 블록은 동일한 구조를 갖는다. 이는 8 킬로바이트의 정보 블록 내의 64 바이트 유닛(셀)의 부모/자식 그룹 멤버 기술자 [34, 54]의 그룹 멤버 정보의 표이며, 그룹 멤버 정보 [34, 54]의 수집은 부모/자식 그룹 멤버 기술자 [32, 52]이다. 부모/자식 그룹 멤버 기술자 공간 비트맵 [31, 51]은, 유효 그룹 정보가 64 바이트 유닛의 각 셀 내에 저장되어 있는지 여부를 나타낸다. 하나의 정보 블록은 최대 127 개의 그룹 멤버 정보 피스 [34, 54]를 저장할 수 있으며, 공간 비트맵 [31, 51]은 16 바이트의 사용을 통해 하나의 비트/셀 내의 각 셀에서의 유효 데이터의 유무를 관리한다. 즉, 유효 그룹 멤버 정보는 공간 비트맵 [31, 51] 내의 "1"로 표시되는 비트를 갖는 셀 내에 저장되며 "0"으로 표시되는 비트를 갖는 셀은 유효 정보를 포함하지 않으며 겹쳐 쓰기를 허용한다. 예비 영역 [33, 53]은 공간 비트맵 [31, 51] 내의 64 바이트 유닛의 셀로부터의 초과 영역이다. 부모/자식 그룹 멤버 기술자 [34, 54]의 그룹 멤버 정보의 수가 M이면, 유효 데이터 사이즈는 64 + 64 ×M 바이트이다. 본 실시예에서, 부모 그룹 멤버 및 자식 그룹 멤버 각각에 대해 16384 개의 멤버 기술자가 전체 CMF 내에 최대로 기록될 수 있다.

그룹 멤버 기술자 [34, 54]는 그룹 내에 포함된 멤버(자식 그룹 또는 파일)의 표를 저장하기 때문에, 기술자의 사이즈는 포함된 멤버의 수에 따라 달라진다. 따라서, 그룹 멤버 정보의 편집을 용이하게 하기 위해, 기록 유닛은 64 바이트로 고정되며 큰 수의 멤버의 경우 정보는 복수의 그룹 멤버 기술자를 통해 기록된다. 본 실시예에서, 그룹 멤버 정보의 블록은 단일 그룹 멤버 정보 블록에 포함되기 때문에, 연속적으로 사용되는 그룹 멤버 기술자 [34, 54]의 최대 수는 127이다. 본 실시예에서, 각 부모 그룹은 자식 그룹만을 포함하며, 각 자식 그룹은 파일만을 포함하며, 플레이 리스트 등의 복수의 파일(그룹화 파일)의 관리를 위한 각 파일, 프린팅의 관리를 위한 DPOF 등은 자식 그룹으로서 취급된다.

도 20은 그룹 멤버 기술자 [34, 54]의 구조를 나타낸 도면이며 부모 그룹 멤버 기술자 및 자식 그룹 멤버 기술자는 동일한 구조를 갖는다. 그룹 멤버 타입 및 그룹 멤버 특성은 그룹 멤버 기술자가 속해 있는 그룹 기술자의 컨텐츠와 동일한 컨텐츠를 포함한다. 다음 멤버 기술자 ID는, 그룹 멤버가 하나의 그룹 멤버 기술자로부터 겹쳐 쓰기될 때 다음 그룹 멤버를 나타내며 그룹 멤버 정보 블록 내의 기록 위치에 의해 표시된다. 이는 전체 CMF에 포함되는 그룹 멤버 기술자의 기록 시퀀스에 따른 2 바이트의 일련 번호에 의해 표현된다. 다음 멤버 기술자가 없는 경우(마지막 그룹 멤버 기술자의 경우), 다음 멤버 기술자 ID는 0xFFFF를 포함한다. 멤버의 수는 이 그룹 멤버 기술자 [34, 54]에 포함된 멤버의 수를 나타내며 멤버 ID는 멤버의 표를 포함한다. 하나의 그룹 멤버 기술자(64 바이트)는 최대 29 개의 멤버들을 저장할 수 있다. 집합적인 그룹이 큰 멤버 수를 포함할 경우, 둘 이상의 그룹 멤버 기술자 [34, 54]가 멤버들을 저장하도록 연결된다. 단일 그룹에 속해 있는 모든 그룹 멤버 기술자가 단일 그룹 멤버 정보 블록 [3, 5]에 포함되어야 할 경우 하나의 그룹 내에 포함되는 최대 멤버 수는 3683이다. 멤버 ID의 지정 방법은 다음 멤버 기술자 ID의 지정 방법과 동일하다. 자식 그룹 ID는 자식 그룹 정보 [4]에 기록된 자식 그룹 기술자 [44]의 순서에 따른 번호(2 바이트)에 의해 지정되며 파일 ID는 파일 정보 [6]에 기록된 파일 기술자 [64]의 순서에 따른 번호(2 바이트)에 의해 지정된다.

그룹 기술자의 사이즈를 감소시키기 위해 그룹 정보의 일부가 그룹 멤버 기술자에 기록되는 경우, 이동된 정보는 제1 그룹 멤버 기술자에 저장될 것이다. 즉, 제1 그룹 멤버 기술자는 그룹 기술자로부터의 정보와, 그룹 멤버 기술자에 원래 기록되는 정보 양자를 포함한다. 그러나, 이 경우 그룹 멤버 기술자의 사이즈는 64 바이트이기 때문에, 멤버 ID에 포함된 멤버의 수(N)는 더 작게 된다. 그룹 멤버의 표가 제1 그룹 멤버 기술자로부터 겹쳐 쓰기될 경우, 나머지는 새로운 그룹 멤버 기술자에 기록될 것이다. 제2 및 후속 그룹 멤버 기술자는 통상적인 구조를 갖는다(도 20).

도 21은 파일의 정보의 기록을 저장하는 파일 정보 [6]의 구조를 나타낸 도면이다. 이는 8 킬로바이트의 정보 블록 내의 16 바이트 유닛(셀)의 파일 기술자 [64]의 파일/디렉토리 정보의 표이며, 여기서 파일 기술자 [64]의 수집은 파일 기술자 [62]이며 파일 기술자 공간 비트맵 [61]은 16 바이트 유닛의 각 셀이 유효 파일/디렉토리 정보를 저장하는지 여부를 나타낸다. 하나의 정보 블록은 최대 508 개의 파일 기술자 [64]를 저장할 수 있으며, 공간 비트맵 [61]은 64 바이트의 사용을 통해 하나의 비트/셀 내의 각 셀 내의 유효 데이터의 유무를 관리한다. 즉, 공간 비트맵 내의 "1"에 의해 표시된 비트를 갖는 셀은 유효 파일 기술자를 저장하며, "0"에 의해 표시된 비트를 갖는 셀은 유효 정보를 포함하지 않으며 겹쳐 쓰기 를 허용한다. 파일 기술자 [64]의 수가 F이면, 유효 데이터 사이즈는 64 + 16 ×F 바이트이다. 65534 개의 파일/디렉토리 정보가 전체 CMF 내에서 최대로 기록될 수 있다.

도 22는 파일 및 디렉토리 정보로서 파일 기술자 [64]의 구조를 나타낸 도면이다. 파일 특성은 파일 또는 디렉토리의 특성 정보를 나타내며, 파일 또는 디렉토리인지에 대한 정보와, 삭제된 파일인지 여부에 대한 정보와, 기록 금지된 속성에 대한 정보 등을 포함하며, 또한 천이를 위한 기록 후 오디오, 비디오, 및 설명을 위한 텍스트 등의 보조 파일 특성에 관한 정보와, 파일 기술자가 확장된 데이터를 포함하는지에 관한 정보 등을 포함한다. 파일 타입은, 영화, 정지 화상, 오디오 또는 플레이 리스트 등의 파일 타입을 포함하며, 파일 타입 표 [12]에 의해 표시되는 표로부터 선택된 다수의 1 바이트를 나타낸다. 이로 인해 마찬가지로 파일의 확장자를 지정할 수 있게 된다. 디렉토리에 대해 파일 타입은 널("0")을 나타낸다. 링크 카운트는 자식 그룹으로부터의 파일에 대한 참조 링크의 수이며, 0의 링크 카운트는, 파일이 어떤 자식 그룹에도 속해 있지 않음을 나타낸다. 파일의 카운트 링크가 1보다 크면, 파일은 자식 그룹으로부터 참조되어 파일이 삭제되어도 겹쳐 쓰기가 금지된다. 즉, 영구 삭제된 파일의 위치는, 삭제될 파일이 속해 있는 파일 정보 블록 [6] 내의 공간 비트맵 [61] 내의 사용 영역("1")으로서 유지된다. 이로 인해, 파일이 삭제될 때, 영구 파일이 속해 있는 자식 그룹의 정보를 수정할 필요가 없게 된다. (원래, 자식 그룹에 속해 있는 파일이 삭제되는 경우, 자식 그룹 정보는 수정되어야 하지만, 자식 그룹에 속해 있는 파일의 파일 ID를 검색할 필 요가 있기 때문에 수정에는 소정의 시간이 걸릴 것이다.) 반면에 자식 그룹이 삭제되면, 자식 그룹에 포함된 파일의 링크 카운트는 각각 1씩 감소된다. 그 포인트에서 0의 링크 카운트를 갖는 파일이 이미 1 삭제된 경우, 영구 파일의 정보의 위치는 공간 비트맵 [61] 내의 공간 영역("0")으로서 설정되어 겹쳐 쓰기를 허용할 것이다. 파일 기술자가 디렉토리 정보이면, 링크 카운트는 항상 0이다.

부모 디렉토리 ID는 부모 디렉토리의 파일 ID를 나타내며 파일 정보 [6]에 기록된 파일 기술자 [64]의 디렉토리 정보의 순서에 따른 수(2 바이트)를 나타낸다. 명칭 길이 및 명칭은 각각 파일 또는 디렉토리의 길이 및 실제 명칭을 나타내며, 명칭은 유니코드(UDP 파일 시스템과 동일한 문자 코드)에 의해 표현된다. 명칭 영역의 상위 1 바이트는 문자 코드의 식별자이며 문자당 8비트의 경우 0×08을 포함하며 혹은 문자당 16 비트의 경우 0×10을 포함한다. 명칭 길이는 또한 문자 코드 식별자를 포함하는 바이트 길이이며, 명칭 셀은 최대 255 바이트까지의 사이즈의 확장자 없이 명칭을 저장할 수 있다. 확장된 데이터는 그룹 정보의 확장된 데이터와 동일한 구조를 갖는다(도 15, 16, 17). 명칭 및 확장된 데이터는 가변 길이를 가지기 때문에, 파일 기술자 [64]의 사이즈가 16 바이트보다 크면(N+E는 10 바이트 이상임), 데이터는 그 후 즉시 다음 파일 기술자에 계속해서 기록되며 확장된 데이터의 사이즈는, 하나의 파일 기술자가 16 바이트의 정수배가 되도록 조정된다. 이 때, 파일명 및 확장된 데이터의 기록에 사용되는 각 파일 기술자 영역은 파일 정보 [6]의 공간 비트맵 [61] 내의 사용 영역("1")으로서 설정되며 그 위치에 의해 지정된 파일 ID는 누락된 파일 ID이다. (도 23은 그 예를 나타낸 도면이다.)

본 실시예에서, 실제 문자열은 각 파일명으로서 저장되지만, 또한 2 바이트의 수치에 의해 각 디렉토리 명칭 또는 파일명을 표현하는 것도 가능하며, 이에 따라 파일 기술자의 사이즈가 16 바이트보다 작은 값으로 된다. 보다 구체적으로, 파일 기술자(도 22) 내에서, 명칭 길이 및 명칭은 2 바이트의 값(명칭 ID)으로 대체되어서 파일 기술자의 사이즈가 8 바이트로 감소된다. 도 26의 디렉토리 구조에 도시된 바와 같이, 영화, 정지 화상, 오디오, 플레이 리스트 등을 포함하는 디렉토리의 명칭은 상위 세 개의 문자로서 3 디지트 수에 의해 표현되며 그 수들은 동일 타입의 파일을 포함하는 디렉토리들의 명칭간에 서로 겹치지 않도록 본 실시예가 구성된다. 따라서, 파일 타입에 의해 파일의 타입을 특정하고 디렉토리 명칭으로서 디렉토리 번호를 지정함으로써 디렉토리가 고유하게 결정될 수 있다. 파일명에 대해, 파일명에 포함된 4 디지트 수는, 디렉토리 명칭의 경우에서처럼 동일한 타입의 파일 중에서 서로 중첩되지 않는다. 즉, 파일 타입에 의해 확장자가 주어지기 때문에, 파일명에서 파일의 번호를 지정함으로써 파일이 고유하게 결정될 수 있다. 이 구성에서, 하나의 정보 블록 내에 포함된 파일 기술자의 수는 1008이므로, 더 많은 파일의 정보가 메모리에 저장될 수 있다.

도 24는 그룹의 코멘트 및 벤더(Vendors)에 고유한 코멘트에 사용되는 텍스트 정보의 기록을 저장하는 텍스트 정보 [7]의 구조를 나타낸 도면이다. 이는 8 킬로바이트의 정보 블록 내의 128 바이트 유닛(셀)의 텍스트 기술자 [74]의 텍스트 정보의 표이며, 여기서 텍스트 정보 [74]의 수집은 텍스트 기술자 [72]이며 텍스트 기술자 공간 비트맵 [71]은 유효 텍스트 정보가 128 바이트 유닛의 각 셀 내에 저 장되어 있는지를 나타낸다. 하나의 정보 블록은 최대 63 개의 텍스트 정보[74]를 저장할 수 있으며, 공간 비트맵 [71]은 8 바이트의 사용을 통해 하나의 비트/셀 내의 각 셀의 유효 데이터의 유무를 관리한다. 즉, 공간 비트맵 [71] 내의 "1"에 의해 표시되는 비트를 갖는 각 셀 내에 유효 텍스트 정보가 저장되며, "0"에 의해 표시되는 비트를 갖는 각 셀 내에는 유효 정보가 기록되지 않는다. 예비 영역 [73]은 공간 비트맵 [71]의 128 바이트 유닛의 셀로부터의 초과 영역이다. 텍스트 기술자 [74]의 텍스트 정보의 수가 T이면, 유효 데이터 사이즈는 128 + 128 ×T 바이트이다.

관리 정보 [1]는 최대 1664 개의 정보 블록 기술자를 저장할 수 있으며, 이 중 부모 그룹 정보 [2], 부모 그룹 멤버 정보 [3], 자식 그룹 정보 [4], 자식 그룹 멤버 정보 [5], 및 파일 정보 [6] 각각은 최대 130 개의 블록을 사용한다. 부모 그룹 및 자식 그룹의 코멘트에 대해 521 개의 텍스트 정보 [7]의 블록을 얻어야 하기 때문에, 사용자는 텍스트 정보 [7] 및 벤더 지정 정보 [8]를 합하여 총 493 개의 블록을 자유롭게 사용할 수 있게 된다.

도 25는 텍스트 정보로서 텍스트 기술자 [4]의 구조를 나타낸 도면이다. 텍스트 특성은 텍스트의 특성 정보이며, 텍스트가 삭제된 것인지에 관한 정보와, 기록 금지된 특성을 갖는지 등에 관한 정보를 포함한다. 객체 타입은 텍스트 기술자를 참조하는 정보(객체)의 타입을 포함하며, 블록 타입 표 [14]의 타입 값에 의해 표시된다(도 7). 객체 ID는 객체 정보(그룹 정보 등)에 기록된 객체 기술자(그룹 기술자 등)의 순서에 따라 다수의 2 바이트를 지정한다. 객체 타입 및 객체 ID는 텍스트를 참조하는 정보(그룹 등)에 대한 역참조를 가능하게 한다. 텍스트 길이는 문자열의 길이의 기록을 포함하며, 영역 내에서 실제 문자열은 UTF-8 또는 UTF-16(파일 시스템과 동일한 문자 코드)에 의해 기록된다. 텍스트 영역의 상위 1 바이트는 문자 코드의 식별자이며, UTF-8의 경우 0x08을 포함하며, UTF-16의 경우 0x10을 포함한다. 텍스트 길이는 문자 코드 식별자도 또한 포함하는 바이트 길이이며 텍스트 영역은 최대 123 바이트까지 데이터를 저장할 수 있다.

2. CMF로의 동작 절차

이후, 도 43을 참조하여 CMF로 파일을 관리하는 절차를 설명한다. 도 43은 전원 공급 또는 디스크의 삽입으로부터 전원 중단 또는 디스크의 배출까지의 처리를 보여준다. CMF의 전체 사이즈는 가변적이나, 모든 정보가 CMF의 앞부분에 있는 16킬로바이트의 관리 정보에 기초하여 관리되는 8킬로바이트 단위의 정보 블록에 포함된다. 따라서, CMF의 전체 구조는 관리 정보를 판독함으로써 알려질 수 있다. 이런 이유로, 관리 정보는 전원의 공급 시각에 또는 디스크의 삽입 시각에 디스크로부터 먼저 판독된다. 이후에, 애플리케이션은 상황이 일어남에 따라 디스크로부터의 관리 정보에 기초하여 필요한 정보 블록을 취한다. 그러나, 디스크의 초기화 시점에 구성된 48킬로바이트의 그룹 정보, 그룹 멤버 정보, 파일 정보, 및 텍스트 정보가 관리 정보와 함께 먼저 판독되도록 본 시스템은 구성될 수도 있다.

그룹 또는 파일의 리스트를 표시하는 다음 단계로서, 애플리케이션은 이렇게 판독된 관리 정보에 기초하여 원하는 표시를 제공한다. 표시 형식은 애플리케이션 쪽에서의 설정에 좌우되고 이후에 자세히 설명된다. 디스크의 내용이 개정되거나, 또는 그룹 정보가 추가 정보를 제공받거나 또는 편집되었을 때, CMF의 내용은 편집된다. 이 시점에서, 그룹화 방법은 두개의 방법을 포함하는데, 하나는 사용자의 지시에 따라서 그룹화하는 것이고, 다른 하나는 시스템에 의해 날짜 등에 따라서 자동으로 그룹화가 실행되는 것이다. 어느 쪽이나, 필요한 정보 블록이 메모리에 없을 때, 관리 정보의 정보 블록 표를 사용함으로써 디스크로부터 정보 블록을 판독하는 작동을 실행하는 것이 필요하다. 순차적 처리의 종료후의 전원 중단 또는 디스크의 배출 시점에서, CMF 파일의 내용이 변경되었다면 CMF가 갱신되고, 갱신된 CMF는 디스크에 역기입된다. CMF를 디스크에 역으로 기입하는 타이밍은 종료 처리의 시점을 제외하고는 한번에 설정될 수 있다.

3. CMF 정보를 사용한 표시 예

다음에서 CMF를 사용해 그룹 또는 파일을 레퍼런싱하는 절차의 한 예를 설명한다. 도 54는 CMF의 전체 구조의 한 예를 도시하였다. 먼저, 정보 블록 기술자 [17]는 CMF [B2에서 B8]에 포함된 개별 정보 블록에 포인트하고, 위치, 타입, 컨텐츠, 및 등등의 것의 정보를 관리한다. 부모 그룹(parent group) 기술자 [24]는 그 자신의 그룹 [G2]에 포함된 멤버의 표인 부모 그룹 멤버 기술자 [34]에 포인트하고, 부모 그룹 멤버 기술자 [44]는 그룹[G3]의 멤버인 자식 그룹(child group) 기술자 [44]에 포인트한다. 자식 그룹 기술자 [44]는 그 자신의 그룹[G4]에 포함된 멤버의 표인 자식 그룹 멤버 기술자[54]에 포인트하고, 자식 그룹 멤버 기술자 [54]는 그룹 [G5]의 멤버인 파일 기술자 [64]에 포인트한다. 본 예에서, 역 방향을 표시하는 어떤 정보도 없으며, 각각의 부모 그룹은 자식 그룹만을 포함하고, 각 각의 자식 그룹은 파일만을 포함한다. 텍스트 기술자[74]는 부모 그룹 기술자[24], 자식 그룹 기술자[44], 및 벤더 지정 정보 블록[8] [T2, T4, T8]에 의해 레퍼런싱되고, 텍스트 기술자 [74] 자체가 레퍼런싱 기술자 정보를 갖기 때문에 양 방식으로 또한 링크된다. CMF의 맨 끝에 있는 더미 정보 블록[9]은 CMF의 사이즈를 ECC 블록(예로, 32KB)의 정수배로 만들기 위해 8KB 추가된 더미 블록이다. 이는 다른 데이터가 CMF를 포함하는 ECC 블록에 기록되는 것을 방지하기 위한 것이고, 더미 정보 블록은 정보 블록을 CMF의 맨 끝에 추가하는 경우에, 정보 블록에 의해 대체된다. 각각의 정보 블록의 상위가 ECC블록의 상위에 배치되면 각각의 정보 블록이 다수의 ECC 블록 상에 기록되는 것을 방지할 수 있으며, 정보 블록의 갱신 및 추가는 효율적으로 실행될 수 있다.

예로, 그룹 리스트를 도 55에 도시한 대로 표시하기 위해 애플리케이션은 먼저, 그 블록 타입이 그룹 정보인 정보 블록 기술자[17]을 추출하기 위해, 예비적으로 판독된 관리 정보에서 정보 블록 기술자[17]을 체크한다. 정보 블록 기술자[17]의 기록 순서가 연관 블록[2,3,4,5,6,7,...]의 기록 위치를 직접 표시하기 때문에, 애플리케이션은 이들의 기록 순서를 어드레스로 변환하고 관련 그룹 정보[2,4]에 액세스한다. 그러면, 애플리케이션은 이름, 코멘트, 등등을 그룹 정보[2,4]에 포함된 그룹 기술자 [24,44]로부터 추출하고, 표시 상에 필요한 아이템을 표시한다. 그러나, 코멘트는 텍스트 정보 블록[7]에 기록되고, 그룹 기술자 [24,44]는 코멘트를 표시하는 텍스트 ID 만을 포함한다. 이런 이유로, 애플리케이션은 정보 블록 기술자 [17]에 근거할 필요가 있고, 텍스트 기술자 [74]를 판독하 기 위해 오브젝티브 텍스트 ID의 텍스트 정보 블록[7]에 액세스한다. 텍스트 기술자[74]는 그 자체를 레퍼런싱하는 그룹 기술자 [24,44]에 대한 역 레퍼런싱 정보를 포함하기 때문에, 코멘트를 포함하는 그룹 정보를 검색하기 위해 역 레퍼런싱 정보의 사용을 통해 코멘트를 검색하는 것이 쉬워진다.

다른 표시 타입이 도 56 및 도 57을 참조해 아래에 설명된다. 도 55에서, 윈도우 [101]의 타이틀과 부모 그룹 [104]의 코멘트가 표시 [100] 상에 리스트되고, 표시 영역은 스크롤 바 [102]에 의해 대표된다. 프레임[103]의 부모 그룹이 선택되었을 때, 이렇게 지정된 부모 그룹에 속하는 자식 그룹의 리스트는 도 56에 도시된 대로 표시 된다. 이는 애플리케이션이 선택된 부모 그룹과 관련된 부모 그룹 멤버 기술자 [34]로부터의 포함된 자식 그룹의 그룹 ID를 획득하고, 그룹 ID에 기초하여 자식 그룹 기술자[44]를 액세스하고, 선택된 부모 그룹에 속하는 자식 그룹의 리스트를 표시하도록 구현된다. 이 시점에서, 대표 화상 및 코멘트의 엔터티가 자식 그룹 기술자[44]에 포함되지 않기 때문에, 애플리케이션은 썸네일 ID 및 코멘트 ID에 기초하여 객체 파일 기술자 [64] 및 텍스트 기술자[74]에 액세스하고 엔터티를 판독할 필요가 있다. 이 표시동안에 삭제된 자식 그룹이 발견되었을 때 자식 그룹의 링크 카운트는 1씩 감소된다. 링크 카운트가 0에 도달하였을 때, 연관 영역에서의 값은 자식 그룹이 속한 정보 블록의 공간 비트맵에서 "0"으로 변환되고(겹쳐 쓰기 가능해지고) 객체의 수는 정보 블록 기술자에서 1씩 감소되고, 데이터 길이는 또한 필요한 경우 감소된다.

도 56의 표시 예에서, 윈도우[101]의 타이틀, 자식 그룹의 대표적 화상 [106] 및 코멘트[105]가 표시[100] 상에 배치되고, 표시 영역은 스크롤 바[102]에 의해 대표된다. 자식 그룹의 썸네일은 썸네일 ID에 의해 표시된 대표 파일의 썸네일이고, 대표 파일이 지정되지 않은 자식 그룹에 대해 자식 그룹의 대표 멤버는 자식 그룹에 포함된 파일 리스트의 상위 파일로서 정의된다. 선택된 자식 그룹은 프레임[103]에 인클로우즈된다. 이 상태에서 결정이 이뤄졌을 때, 지정된 자식 그룹에 속하는 파일의 리스트가 표시되거나, 또는 파일은 계속적으로 재생된다. 계속적으로 파일을 재생하는 경우에, 부가의 속성을 갖는 파일은 재생되지 않고 건너 뛸 수 있다. 자식 그룹이 플레이 리스트 그룹이면, 플레이 리스트가 재생된다. 파일 리스트의 표시 동안, 또는 순차적 재생 동안, 삭제된 파일이 발견되었을 때, 파일의 링크 카운트가 1씩 감소된다. 링크 카운트가 0 에 도달하면, 관련 영역에서의 값은 이 파일이 속하는 정보 블록의 공간 비트맵에서 "0"으로 변화되고(겹쳐 쓰기 가능해지고), 객체의 수는 정보 블록 기술자에서 1씩 감소되고, 데이터 길이는 필요한 경우 또한 감소된다.

도 57은 선택된 자식 그룹에 속하는 파일의 리스트의 표시 예를 도시하였다. 표시에 필요한 정보는 앞서와 유사한 처리에 따라서 획득되고, 썸네일 화상만이 본 예에서 표시된다. 윈도우[101]의 타이틀 및 파일[107]의 썸네일 화상은 표시 [100] 상에 배치되고, 표시 영역은 스크롤 바[102]에 의해 대표된다. 선택된 파일은 프레임[103] 내에 인클로우즈된다. 이 상태에서 결정이 이뤄졌을 때, 지정된 파일이 재생된다. 파일이 정지 화상이라면, 정지 화상이 표시된다. 파일이 영화라면, 영화의 재생이 시작된다. 부가적 속성을 갖는 파일은 리스트에서 항상 표시 될 필요는 없다.

상기 설명에서는 세 가지 타입의 표시 예가 제시되었는데, 부모 그룹, 자식 그룹 및 파일을 표시하는 방법은 상기 표시 예에 제한되지 않는다는 점을 알아야 한다. 예를 들어, 부모 그룹의 표시는 대표 자식 그룹의 썸네일과 코멘트의 동시 표시를 포함할 수 있지만, 코멘트만이 파일 리스트의 화상에 대해 사용될 수도 있다.

4. CMF의 갱신 절차

아래에서 CMF의 내용을 갱신하는 절차를 설명할 것이다. 먼저, 갱신으로 인한 CMF의 데이터 구조의 변화가 개별 상황에 따라서 설명된다.

도 27은 디스크의 초기화 시점에서의 디렉토리 구조를 도시하였고, 도 28은 이 시점에서의 CMF 구조를 도시하였다. 초기화된 상태에서는, ROOT[80], MISC[81], DCIM[82], 및 VIDEO[83]의 디렉토리만이 있고, 어떤 파일도 존재하지 않는다. CMF는 16Kbyte의 하나의 관리 정보와 각각이 8KB인 여섯 개의 정보 블록으로 구성되고, 네 개의 디렉토리 정보 피스(piece)와 두개의 그룹 정보 피스를 포함한다. 본 실시예는 날짜 그룹 및 플레이 리스트 그룹을 디폴트로서 갖도록 구성되었기 때문에, 이들의 부모 그룹, 즉, 부모 그룹 기술자 [22] 및 상응하는 부모 그룹 멤버 기술자[32]는 각각 두개씩 먼저 생성된다. 이 시점에서, 부모 그룹 멤버 기술자[32]는 어떤 멤버도 포함하지 않는다. 네 개의 디렉토리가 있기 때문에, 디렉토리 정보에 대한 네 개의 파일 기술자[62]가 생성된다. 이런 정보 블록의 공간 비트맵에서, "1"은 데이터의 엔트리를 갖는 객체 기술자의 위치에 상응하는 비트에 설정된다. 자식 그룹 정보 [42,52] 및 텍스트 정보 [72]에는 어떤 데이터도 없다. 정보 블록 표[16]는 관리 정보[1]를 제외하여 여섯 개의 블록에 대한 정보를 포함한다. 각각의 정보 블록의 예비된 영역은 공간 비트맵 영역에 포함되기 때문에, 본 예시는 이들을 보여주지 않는다.

도 29는 초기화 후에 즉시 기록된 단지 하나의 영화 파일(TAKE0001.MPG)을 갖는 디렉토리 구조를 보여준다. 영화 디렉토리(100MOVIE)[85]는 VIDEO 디렉토리 [83]에 자동 생성되고, 영화 파일은 이 영화 디렉토리에 기록된다. 도 30은 이 시점에서의 CMF 구조를 도시하였다. 도 28과 비교하였을 때에, 디렉토리 정보 피스와 파일 정보 피스는 파일 정보[6]의 파일 기술자[62]에 각각 하나씩 더해진다. 파일이 더해졌을 때, 날짜 그룹에 자동 등록되어 날짜 자식 그룹의 자 그룹 기술자[42]와 이것의 멤버인 자식 그룹 멤버 기술자[52]가 각각 하나씩 자동 생성된다. 생성된 신규 파일은 날짜 자식 그룹 멤버 기술자[52]의 멤버로서 등록되고, 이 시점에 생성된 날짜 자식 그룹 기술자[42]는 또한 날짜 자식 그룹 멤버 기술자[32]의 멤버로서 등록된다. 이 시점에서, 기록 위치에 상응하는 비트는 기술자가 더해진 정보 블록의 공간 비트맵에서 "0"에서 "1"로 변화되고, 정보 블록 표[16]의 정보는 또한 동시에 갱신된다.

도 31은 신규 플레이 리스트 파일(PLAY0001.XML)[95]가 두개의 영화 디렉토리[85] 및 60 개의 영화 파일[93]의 기록 상태에 더해지는 디렉토리 구조를 도시하였다. 본 예에서 60개의 파일은 두개의 디렉토리에 개별로 기록되기 때문에, 두개의 영화 디렉토리[85]가 만들어진다. 신규 플레이 리스트 파일[95]가 생성되었을 때, 플레이리스트 디렉토리(300PLIST)[87]은 VIDEO 디렉토리[83]에 자동 생성되고 플레이 리스트 파일은 이 플레이 리스트 디렉토리에 기록된다. 도 32는 이 시점에서의 CMF 구조를 도시하였고, 여기서 파일 기술자 [62]의 수는 68인데, 이는 디렉토리 및 파일이 전체로 카운트 68이 되기까지 각각 1씩 증분되기 때문이다. 만약, 추가의 플레이 리스트 파일이 더해진다면, 이는 플레이 리스트 그룹에 자동적으로 등록되어 각각 하나씩 플레이 리스트 자식 그룹의 자식 그룹 기술자[42]와 그것의 멤버의 자식 그룹 멤버 기술자[52]를 생성하는 것으로 귀결된다. 신규의 플레이 리스트 파일은 플레이 리스트 자식 그룹 멤버 기술자[52]의 멤버로서 등록되고, 이 시점에 생성된 플레이 리스트 자식 그룹 기술자[42]는 플레이 리스트 그룹의 플레이 리스트 부모 그룹 멤버 기술자[32]의 멤버로서 또한 등록된다. 이 시점에서, 기록 위치에 상응하는 비트는 기술자가 더해졌던 정보 블록의 공간 맵에서 "0"으로부터 "1"로 변화되고, 정보 블록 표[16]의 정보는 또한 자동 갱신된다.

도 33은 도 32의 상태에 대해서, 30 이상의 파일을 포함하는 코멘트를 구비한 자식 그룹이 더해진 CMF 구조를 도시하였다. 플레이 리스트 또는 등등의 것과 같은 파일을 그룹화하는 것을 제외하고 그룹화하는 경우에, 어떤 실제의 파일도 생성되지 않고, 디렉토리 구조는 도 31에 도시된 것과 같다. 30 이상의 (59 이하의) 파일을 갖는 자식 그룹은 두개의 자식 그룹 멤버 기술자 [52]를 필요로 하기 때문에, 자식 그룹 멤버 기술자[52]의 자식 그룹 멤버의 개수는 2씩 증분되고, 이쪽에 레퍼런스 링크를 갖는 하나의 자식 그룹 기술자[42]가 더해진다. 단지 하나의 그룹 기술자[42]가, 하나의 블록 그룹에 의해 사용된 그룹 멤버 기술자[52]의 개수에 관계없이, 하나의 그룹에 대해 더해진다. 코멘트가 텍스트 정보[7]에 기록되기 때문에, 하나의 텍스트 기술자[72]가 더해진다. 세 개의 영역에서의 상기 수정에 따라서, 정보는 상응하는 정보 블록의 공간 비트맵 [41,51,71]에서 및 정보 블록 표[16]에서 갱신된다.

도 34는, 도 33의 상태에 대해서, 멤버가 자식 그룹에 더해지고, 신규의 자식 그룹 멤버 기술자[52]가 생성된 CMF 구조를 도시하였다. 멤버를 그룹에 더하기 위해서는, 멤버는 만약 있다면 기존 그룹 멤버 기술자의 공간에 배치될 수 있다. 그러나, 공간이 없는 경우에는, 신규의 그룹 멤버 기술자가 생성되어야 한다. 본 예에서, 하나의 자식 그룹 멤버 기술자[52]가 더해진다. 그것과 동시에, 신규의 자식 그룹 멤버 기술자[52]에 앞서서 자식 그룹 멤버 기술자[52]의 다음의 멤버 기술자 ID 를 갱신시키는 것이 또한 필요하다. 이것과 함께, 정보는 상응하는 정보 블록의 공간 비트 맵[51]에서 및 정보 블록 표[16]에서 갱신된다.

도 35는, 도 34의 상태에 대해서, 코멘트를 갖는 하나의 부모 그룹만이 더해지는 CMF 구조를 도시하였다. 이 경우에, 도 31의 상태로부터의 디렉토리 구조에는 어떤 변화도 없다. 신규로 더해진 부모 그룹은 29 또는 그 이하의 자식 그룹만을 갖기 때문에, 하나의 부모 그룹 기술자[22]와 하나의 부모 그룹 멤버 기술자[32]가 더해진다. 코멘트가 텍스트 정보[7]에 기록되기 때문에, 하나의 텍스트 기술자[72]가 더해진다. 세 개의 영역에서의 상기 변경에 대해서, 정보는 상응하는 정보 블록의 공간 비트맵 [21, 31, 71]에서 및 정보 블록 표[16]에서 갱신된다.

도 36은 초기화 시점에 확보된 전체 CMF 용량을 채우는 데이터 수를 도시하였는데, 여기서, 부모 그룹의 수, 부모 그룹 멤버의 수, 자식 그룹의 수, 및 자식 그룹 멤버의 수는 모두 127이며, 파일의 수는 508이며, 텍스트의 수는 63이다. 실제상, 그룹의 개수는 그룹 멤버의 수를 절대 초과하지 않는다.

도 37은 파일이 초기화 시점에 획득된 CMF의 꽉 찬 상태에서의 구조에 더해진 CMF 구조를 도시하였다. 먼저, CMF의 꽉 찬 상태가 부모 그룹의 수와 자식 그룹의 수가 각각 127이며 파일의 수는 508이며, 텍스트의 수는 63인 상태라고 가정하자. 본 예는 그룹 기술자 당 하나의 그룹 멤버 기술자 만이 존재하는 것을 보여준다. 하나의 파일 정보가 이 상태에서 더해졌을 때에 기존의 파일 정보 블록 1[61,62]에는 공간 영역이 전혀 없고, 따라서, CMF의 맨 끝에 신규의 파일 정보 블록 2[65,66]을 더하는 것이 필요하다. 이후에 파일 기술자 2[66]는 신규로 더해진 파일 정보 블록 2[65,66]에 기록된다. 동시에, 신규 파일은 자동으로 날짜 그룹에 등록되고, 따라서 상응하는 날짜 자식 그룹 멤버 기술자[52]의 멤버로서 등록된다. 이와 함께, 정보는 상응하는 공간 비트맵 2[65]에서 갱신되고 블록의 수는 정보 블록 표 [16]에서 1 씩 증분된다.

도 38은, 도 37의 상태에 대해서, 파일이 자식 그룹에 더해지고 신규의 자식 그룹 멤버 정보 블록이 더해지는 CMF 구조를 도시하였다. 멤버를 그룹에 더하는 것에 대해서, 만약 있다면, 기존의 그룹 멤버 기술자의 공간에 배치될 수 있다. 그러나, 공간이 전혀 없는 경우에, 신규의 그룹 멤버 기술자를 생성하는 것이 필요하다. 또한, 본 예에서, 기존의 자식 그룹 멤버 정보 블록1[51,52]에는 공간이 전 혀 없다. 따라서, 신규의 자식 그룹 멤버 정보 블록 2[55,56]은 CMF의 맨 끝에 더해지고, 자식 그룹 멤버 기술자 2[56]가 생성된다. 동시에, 신규의 자식 그룹 멤버 기술자 2[56]전에 자식 그룹 멤버 기술자 1[52]의 다음 멤버 기술자 ID를 갱신하는 것이 또한 필요하다. 이것과 함께, 정보는 상응하는 공간 비트맵 2[55]에서 갱신되고, 블록의 수는 정보 블록 표[16]에서 1씩 증분된다.

도 39는 코멘트를 갖는 자식 그룹이 도 38에 계속적으로 더해지는 CMF 구조를 도시하였다. 기존의 정보 블록은 채워졌으므로, 신규의 자식 그룹 정보 블록 및 텍스트 정보 블록이 더해진다. 먼저, 신규 자식 그룹을 위한 자식 그룹 정보 블록 2[45,46]은 CMF에 더해지고 신규 자식 그룹의 멤버는 자식 그룹 멤버 기술자 2[56]에 더해진다. 더나아가, 자식 그룹으로부터 레퍼런스 링크를 갖는 코멘트를 기억하기 위해, 텍스트 정보 블록 2[75,76]이 CMF에 더해지고 하나의 텍스트 정보가 텍스트 기술자 2[76]이 더해진다. 이와 함께, 정보는 상응하는 공간 비트 맵[45,55,75]에서 갱신되고 블록의 수는 정보 블록 표[16]에서 2씩 증분된다.

도 40은, 파일이 도 38에서와 같이, 기존의 자식 그룹에 더해지고, 더해진 파일을 수용하기 위해 자식 그룹을 포함하는 정보 블록 1[51,52]이 이미 데이터로 채워져 있어서 관련 그룹 멤버 정보의 전체가 또다른 정보 블록 2[55,56]로 옮겨지는 CMF 구조를 도시하였다. 파일의 추가 전에 하나의 자식 그룹 멤버 기술자만이 있고 하나의 신규 자식 그룹 멤버 기술자가 이것에 더해진다고 가정하자. 전체 그룹을 하나의 정보 블록에 배치하기 위해서는, 원래의 자식 그룹 멤버 기술자 1[52]가 먼저 자식 그룹 멤버 기술자 1[52]로부터 자식 그룹 멤버 기술자 2[56]로 옮겨 지고 신규의 자식 그룹 멤버 기술자2[56]는 그에 더해진다. 그 결과, 자식 그룹의 수는 신규 자식 그룹 멤버 기술자 2[56]에서 2씩 증분되고, 자식 그룹의 수는 원래의 자식 그룹 멤버 기술자 1[52]에서 1씩 감소된다. 더나아가, 자식 그룹 멤버 기술자 레퍼런스 링크를 갖는 자식 그룹 기술자 1[42]의 그룹 멤버 기술자 ID의 값을 갱신하는 것이 또한 필요하다. 최종 단계로, 본 정보는 상응하는 공간 비트맵[51,55]에서 및 정보 블록 표[16]에서 또한 갱신된다.

이후 파일 또는 그룹을 삭제하는 경우에 대해 설명한다. 도 41은 파일 기술자 1[62]내의 파일이 삭제되고 삭제 속성이 삭제된 파일 기술자에 더해지는 경우를 보여준다. 이 시점에서, 공간 비트맵 1[61]의 관련 영역에서의 값이 "0"으로 변화되어야하는지(삭제되어야 하는지)의 여부는 삭제된 파일의 링크 카운트의 값에 좌우된다. 링크 카운트가 0 이면 공간 비트맵 1[61]의 값이 "0"으로 변화될 수 있다. 링크 카운트가 1 보다 크면, 파일은 어느 쪽의 자식 그룹으로부터든지의 레퍼런스 링크를 갖고 따라서 공간 비트맵 1[61]의 값은 겹쳐 쓰기를 금지하기 위해 "1"로 유지된다. 공간 비트맵 1[61]의 값에서 변화가 이뤄진다면, 정보는 정보 블록 표[16]에서 또한 갱신된다.

도 42는 멤버 정보로서 두개의 자식 그룹 멤버 기술자를 갖는 코멘트를 구비한 자식 그룹의 정보인, 하나의 자식 그룹 기술자가 삭제된 경우의 CMF 구조를 도시하였다. 먼저, 삭제 속성이 자식 그룹 기술자1[42]의 삭제된 그룹 기술자에 더해진다. 이 시점에서, 공간 비트맵 1[41]의 관련 영역에서의 값이 "0"으로 변화되어야 하는지(삭제돼야 하는지)의 여부는 삭제된 그룹의 링크 카운트의 값에 좌우되 어 결정된다. 링크 카운트가 0 이면, 공간 비트맵1[41]의 값은 "0"으로 변화될 수 있다. 링크 카운트가 1보다 크면, 그룹은 어느 부모 그룹으로부터든지의 레퍼런스 링크를 가지며 따라서 공간 비트맵 1[41]의 값은 겹쳐 쓰기를 금지하기 위해 "1"로 유지된다. 부모 그룹의 링크 카운트가 항상 0 이면, 공간 비트맵의 관련 영역에서의 값은 부모 그룹 삭제의 경우에 "0"에 설정될 수 있다(삭제될 수 있다). 다음 단계는 삭제된 자식 그룹의 멤버 정보를 표시하는 두개의 자식 그룹 멤버 기술자 1[52]를 삭제하는 것이다. 이는 삭제된 멤버 기술자의 위치 정보에 상응하는 공간 비트맵 1[51]의 관련 영역에서 "0"으로 값을 설정함으로써(삭제함으로써) 실현될 수 있다. 다음 순서로, 텍스트 정보는 삭제된 그룹으로부터 레퍼런스 링크를 갖는 텍스트 기술자1[72]로부터 삭제된다. 이는 삭제된 텍스트에 상응하는 공간 비트맵1[71]의 관련 영역에서 "0"으로 값을 설정함으로써(삭제함으로써) 또한 구현된다. 상기 설명한 대로 세 개의 변경된 정보 블록의 공간 비트맵 [41,51,71]의 값들에 대해 변화가 이뤄졌을 때, 정보는 정보 블록 표[16]에서 또한 갱신된다.

도 44는 신규의 정보 블록을 더하는 루틴을 보여준다. 신규 정보 블록은 객체 기술자의 추가의 정보에 대해 쓸 수 있는 공간 영역이 없을 때에 추가된다. 제1 단계는 CMF의 종단에서 8KB의 영역을 획득하는 것이다. 추가될 신규 기술자의 정보 또는 그와 같은 것이 있다면, 필요 정보는 공간 비트맵과 예비 영역을 뒤이은 기술자 기록 영역의 상위로부터 기록되고, 기록 위치에 상응하는 공간 비트맵의 영역에 "1"이 설정된다. 이후에 신규 정보 블록 기술자는 관리 정보의 정보 블록 표에 더해지고 필요 아이템은 거기 기록된다. 정보 블록 표가 변경되었을 때, 관련 아이템, 즉, 객체의 수 및 그와 같은 것은 일반 정보에서 갱신된다.

도 45는 기술자 사이즈가 고정된 길이일 때의 신규 정보, 파일, 또는 텍스트 정보(객체)를 더하는 루틴을 보여준다. 이런 정보가 고정된 길이의 기록 사이즈를 갖기 때문에, 하나의 공간 영역이 있는 한 이는 기록될 수 있다. 먼저, 기존의 정보 블록에 자유 공간이 있는지가 판정된다. 관련 객체에 대한 정보 블록의 객체의 수가 최대 기록가능한 수보다 작다면 자유 공간이 있는 것이다. 기존의 정보 블록에 자유 공간이 있다면, 관련 객체는 여기에 기록될 수 있다. 공간이 없다면, 신규의 정보 블록이 생성되고 관련 객체는 그 내에 기록된다. 기존의 정보 블록에 기록시에 객체의 수(공간 비트맵 영역의 사이즈 + 예비된 영역의 사이즈 + 객체의 수 ×셀 사이즈)로부터 계산된 데이터 사이즈가 데이터 길이의 값과 동일하다면, 데이터 길이까지의 영역을 위한 공간은 없고 따라서 신규 객체의 정보는 데이터 길이 바로 다음의 사이트로부터 기록될 수 있다. 데이터 길이의 값이 객체의 수로부터 계산된 데이터 사이즈보다 크다면, 중앙에 공간 영역이 존재하고, 따라서 공간 영역은 공간 비트맵 용도로 검색되고 신규 객체의 정보는 여기에 기록된다. 중앙의 공간 영역을 쓰고서도 데이터 길이 후에 충분한 영역이 존재한다면, 신규 객체의 정보의 기록은 공간 비트맵을 검색하지 않고 데이터 길이 바로 후에 개시될 수 있다. 기록 종료 후에, 값은 동일 정보 블록의 공간 비트맵의 관련 영역에서 "1"로 설정되고, 정보 블록 기술자에서의 객체의 수는 1 씩 증분되고, 데이터 길이는 필요한 경우 또한 증가된다. 데이터 길이는 신규 생성된 객체가 유효 데이터 길이의 맨 끝에 더해졌을 때만 증가된다. 신규 객체가 중앙의 삭제된 영역에 기록되었 을 때, 데이터 길이는 증가되지 않는다.

도 46은 그 기술자(Descriptor) 사이즈가 가변 길이인 신 그룹 멤버 정보(객체)를 추가하는 루틴을 도시한다. 그 정보는 가변 길이의 기록 사이즈를 갖기 때문에, 충분한 공간 영역이 있는지 여부를 결정할 필요가 있다. 기존의 정보 블록 내에 충분한 공간이 있는지 여부를 먼저 결정하기 위하여, 관련 객체에 대한 정보 블록 중의 객체의 수와 최대 기록 가능한 수 사이의 차이와 기록 사이즈가 비교된다. 만일 기존의 정보 블록이 충분한 공간을 갖고 있다면 객체는 거기에 기록될 수 있다. 만일 충분한 공간이 없다면 새로운 정보 블록이 생성되고 관련 객체는 거기에 기록된다. 기존의 정보 블록에 기록하는 경우에, 객체의 수로부터 계산된 데이터 사이즈(공간 비트맵 영역의 사이즈 + 예비 영역의 사이즈 + 객체의 수 × 셀 사이즈)가 데이터 길이의 값과 같다면, 그 영역에 데이터 길이까지의 공간이 없으므로 신 객체 정보는 데이터 길이 바로 뒤의 사이트로부터 기록될 수 있다. 데이터 길이의 값이 객체의 수로부터 계산된 데이터 사이즈보다 클 경우, 중간에 공간 영역이 존재하고, 이 공간 영역은 공간 비트맵을 이용하여 검색되고, 신 객체 정보는 거기에 기록된다. 만일 중간에 공간 영역을 갖고도 데이터 길이 뒤에 충분한 영역이 존재한다면, 공간 비트맵을 검색하지 않고서 데이터 길이 바로 뒤로부터 기록이 시작될 수 있다. 기록의 종료 후에, 동일 정보 블록의 공간 비트맵 내의 관련 부분에 "1"의 값이 세트되고, 정보 블록 기술자 중의 객체의 수가 추가된 객체의 수만큼 증가되고 필요하다면 데이터 길이도 증가된다. 데이터 길이는 유효 데이터 길이의 맨 끝 부분에 새로 생성된 객체가 추가될 때만 증가된다. 데이터 길이는 중간에 삭제된 영역에 객체가 기록될 때는 증가되지 않는다. 그룹 멤버 정보가 추가되면, 추가된 그룹 멤버의 그룹 멤버 기술자에 대해 참조 링크를 갖는 그룹 기술자의 그룹 멤버 ID, 또는 추가된 그룹 멤버 기술자 바로 전의 그룹 멤버 기술자의 다음 멤버 ID를 신 멤버 기술자 ID로 갱신할 필요가 있다.

다음으로 객체를 삭제하는 루틴을 설명한다. 도 47은 파일 정보를 삭제하는 루틴을 도시한다. 먼저, 파일 기술자 중의 파일 속성에 삭제 속성이 추가된다. 링크 카운트가 0이면, 동일 정보 블록의 공간 비트맵 내의 삭제된 부분에 "0"의 값이 세트되고, 정보 블록 기술자 중의 객체의 수가 1만큼 감소되고, 필요하다면 데이터 길이도 감소된다. 링크 카운트가 0이 아니면, 겹쳐 쓰기(overwriting)를 피하기 위하여 공간 비트맵 및 관련 정보 블록 기술자에 아무런 변화도 생기지 않는다. 이때, 데이터 길이는 유효 데이터 길이의 맨 끝에 삭제된 객체가 하나 위치할 때만 감소된다. 데이터 길이는 중간 영역이 삭제되는 때는 감소되지 않는다.

도 48은 텍스트 정보를 삭제하는 루틴을 도시한다. 삭제된 객체가 텍스트일 때는, 그 텍스트를 거기에 대해 참조 링크를 갖는 그룹으로부터 분리시킬 필요가 있다. 그러므로, 그룹의 코멘트 ID의 값은 노 코멘트를 나타내기 위해 0xFFFF로 세트된다. 그 후, 동일 정보 블록의 공간 비트맵 중의 삭제된 부분에 "0"이 세트되고, 정보 블록 기술자 중의 객체의 수가 1만큼 감소되고, 필요하다면 데이터 길이도 감소된다. 이때, 데이터 길이는 유효 데이터 길이의 맨 끝에 삭제된 객체가 하나 있을 때만 감소된다. 데이터 길이는 중간 영역이 삭제되는 때는 감소되지 않는다.

도 49는 자식 그룹 정보를 삭제하는 루틴을 도시한다. 먼저, 삭제될 자식 그룹의 그룹 기술자에 삭제 속성이 추가된다. 이때, 0의 링크 카운트인 경우에 삭제된 부분이 겹쳐 쓰기될 수 있으므로, 공간 비트맵 중의 삭제된 부분에 "0"의 값이 세트된다. 정보 블록 기술자 중의 객체의 수가 1만큼 감소되고, 필요하다면 데이터 길이도 감소된다. 만일 그룹이 코멘트를 갖고 있다면, 텍스트 정보 중의 대응 텍스트가 삭제된다. 그 후, 자식 그룹에 포함된 모든 그룹 멤버 기술자들이 그룹 멤버 ID에 따라 삭제된다. 최종 단계에서 자식 그룹에 포함된 파일들의 모든 링크 카운트가 각각 1만큼 감소된다. 이때, 파일이 삭제되고 또한 그 링크 카운트가 0이라면, 겹쳐 쓰기를 허용하기 위하여, 그 파일이 속하는 정보 블록의 공간 비트맵 중의 관련 부분에 "0"의 값이 세트되고, 정보 블록 기술자 중의 객체의 수가 1만큼 감소되고, 필요하다면 데이터 길이도 감소된다. 데이터 길이는 유효 데이터 길이의 맨 끝에 삭제된 객체가 하나 있을 때만 감소된다. 데이터 길이는 중간 영역이 삭제되는 때는 감소되지 않는다.

도 50은 부모 그룹 정보를 삭제하는 루틴을 도시한다. 부모 그룹은 항상 0의 링크 카운트를 갖기 때문에, 그 그룹 기술자는 완전히 삭제될 수 있다. 공간 비트맵 중의 삭제된 부분에 "0"의 값이 세트되고, 정보 블록 기술자 중의 객체의 수가 1만큼 감소되고, 필요하다면 데이터 길이도 감소된다. 이때, 그룹 기술자는 완전히 삭제되고 따라서 자식 그룹의 삭제의 경우와는 다른, 삭제 속성을 추가할 필요가 있다. 만일 부모 그룹이 코멘트를 갖고 있다면, 텍스트 정보 중의 대응 텍스트가 삭제된다. 그 후, 부모 그룹에 포함된 모든 그룹 멤버 기술자가 그룹 멤버 ID에 따라 삭제된다. 최종 단계에서 부모 그룹에 포함된 자식 그룹들의 모든 링크 카운트가 각각 1만큼 감소된다. 이때, 자식 그룹이 삭제되고 또한 그 링크 카운트가 0이라면, 겹쳐 쓰기를 허용하기 위하여, 그 자식 그룹이 속하는 정보 블록의 공간 비트맵 중의 관련 부분에 "0"의 값이 세트되고, 정보 블록 기술자 중의 객체의 수가 1만큼 감소되고, 필요하다면 데이터 길이도 감소된다. 데이터 길이는 유효 데이터 길이의 맨 끝에 삭제된 객체가 하나 있을 때만 감소된다. 데이터 길이는 중간 영역이 삭제되는 때는 감소되지 않는다.

도 51은 그룹 멤버 정보(객체)를 이동시키는 루틴을 도시한다. 이 정보는 가변 길이의 기록 사이즈를 갖기 때문에, 공간 영역이 충분한지 여부를 결정할 필요가 있다. 기존의 정보 블록이 충분한 공간을 갖고 있는지 여부를 먼저 결정하기 위하여, 관련 객체에 대한 정보 블록 중의 객체의 수와 최대 기록 가능한 수 사이의 차이와 기록 사이즈가 비교된다. 만일 기존의 정보 블록이 충분한 공간을 갖고 있다면, 객체는 거기에 이동될 수 있다. 만일 공간이 불충분하다면, 신 정보 블록이 생성되고 관련 객체는 거기에 이동된다. 객체가 기존의 정보 블록에 이동되는 경우에, 객체의 수로부터 계산된 데이터 사이즈(공간 비트맵 영역의 사이즈 + 예비 영역의 사이즈 + 객체의 수 × 셀 사이즈)가 데이터 길이의 값과 같다면, 그 영역에 데이터 길이까지의 공간이 없으며, 이동될 객체 정보는 데이터 길이 바로 뒤의 사이트로부터 기록될 수 있다. 데이터 길이의 값이 객체의 수로부터 계산된 데이터 사이즈보다 크면, 중간에 공간 영역이 존재하고, 이 공간 영역은 공간 비트맵을 이용하여 검색되고, 이동될 객체 정보는 거기에 기록된다. 만일 중간에 공간 영역 을 갖고도 데이터 길이 뒤에 충분한 영역이 존재한다면, 공간 비트맵을 검색하지 않고서 데이터 길이 바로 뒤로부터 기록이 시작될 수 있다. 이동의 종료 후에, 객체가 이동된 정보 블록의 공간 비트맵 내의 관련 부분에 "1"의 값이 세트되고, 정보 블록 기술자 중의 객체의 수가 1만큼 증가되고 필요하다면 데이터 길이도 증가된다. 이동된 그룹 멤버가 속하는 그룹 기술자의 멤버 ID의 값, 또는 이전 그룹 멤버 기술자의 다음 멤버 ID의 값이 새로운 멤버 기술자 ID에 재기록된다. 최종 단계에서, 구 그룹 멤버 정보 블록의 공간 비트맵 중의 관련 부분에 "0"의 값이 세트되고, 정보 블록 기술자 중의 객체의 수가 1만큼 감소되고, 필요하다면 데이터 길이도 감소된다.

다음으로 부모 그룹 또는 자식 그룹에 포함된 멤버(자식 그룹, 파일 등과 같은 객체)의 추가/삭제 루틴에 대해 설명한다. 도 52는 그룹에 멤버를 추가하는 루틴을 도시한다. 만일 소망의 그룹의 그룹 멤버 기술자에 멤버를 추가하기에 충분한 공간 영역이 있다면, 그 객체 그룹 멤버 기술자에 단순히 객체 ID가 추가된다. 멤버의 총수에 관한 정보가 갱신되고, 그 후 각각의 추가된 객체의 링크 카운트가 1만큼 증가된다. 만일 공간 영역이 불충분하다면, 동일한 그룹 멤버 정보 블록에 필요한 수의 그룹 멤버 기술자가 추가된다. 이때, 객체를 추가하기를 원하는 그룹 멤버 기술자를 포함하는 그룹 멤버 정보 블록 중에 그룹 멤버 기술자들을 추가하기에 충분한 공간 영역이 없다면, 하나의 그룹에 속하는 모든 그룹 멤버 기술자들이 다른 그룹 멤버 정보 블록에 이동될 수도 있다. 만일 기존의 그룹 멤버 정보 블록 중에 아무런 공간 영역도 없다면, 새로운 그룹 멤버 정보 블록이 생성된다.

도 53은 부모 그룹 또는 자식 그룹에 포함된 멤버들(자식 그룹, 파일 등과 같은 객체들)을 삭제하는 루틴을 도시한다. 삭제될 멤버들은 그룹 멤버 기술자로부터 먼저 삭제되고, 멤버의 총수에 관한 정보가 갱신되고, 그 후 삭제된 객체들의 링크 카운트가 각각 1만큼 감소된다. 이때, 객체가 삭제되고 또한 그 링크 카운트가 0이면, 그 객체가 속하는 정보 블록의 공간 비트맵 중의 관련 부분에 "0"의 값이 세트되고, 정보 블록 기술자 중의 객체의 수가 1만큼 감소되고, 필요하다면 데이터 길이도 감소된다. 또한, 그룹으로부터 멤버들을 삭제한 결과 그룹 멤버 기술자가 아무런 멤버도 포함하지 않게 되면, 전체 그룹에 걸쳐서 다음 멤버 기술자 ID가 수정되고 불필요한 그룹 멤버 기술자는 삭제된다.

상술한 바와 같이, 모든 필요한 파일 및 그룹을 전적으로 관리하기 위한 파일인 CMF(Contents Management File)가 제공되면 애플리케이션들이 파일 시스템을 사용하지 않고도 CMF를 통하여 다수의 파일을 다룰 수 있게 되고 또한 그룹화 등과 같은 필요한 처리를 다재다능하게 수행할 수 있게 된다. 예를 들면, 복수의 파일의 시계열(time series) 표시의 경우에, 파일들은 날짜 순에 따라서 그룹화되거나, 또는 파일 정보가 CMF에 시계열로 기록되고, 파일들은 순서대로 재현된다. 부모 그룹 및 자식 그룹의 층들 중의 그룹 정보의 계층적 구조 역시 그룹의 관리를 용이하게 한다.

CMF는 각각의 그룹에 포함된 멤버들(자식 그룹, 파일 등과 같은 객체들)의 리스트를 갖고 있고, 각각의 객체는 그 객체가 속하는 그룹의 수인 링크 카운트를 갖고 있으므로, 어떤 그룹에 포함된 멤버들의 리스트를 즉시 검색하고 또한 양쪽 그룹에 어떤 객체가 포함되는지를 용이하게 결정할 수 있게 된다. 따라서 양쪽 그룹에 포함된 객체를 삭제하는 경우에 경고 등이 용이해진다.

CMF 내의 표를 사용하여 확장자가 1바이트로 표현될 때, 파일명에 대한 정보 사이즈는 감소될 수 있다. 또한, 확장자 표는 동일한 확장자라도 그 타입에 따라 다른 확장자로서 다루도록 구성되고, 파일의 타입은 확장자와 관계없이 분류될 수 있다. 파일들 자체가 또한 보조 파일 속성을 구비할 경우, 그것들은 일반 비디오, 오디오 등 중에서 식별될 수 있다.

비록 그룹 멤버 정보는 포함된 멤버의 수에 따라서 가변 사이즈를 갖지만, 고정된 길이 사이즈(64바이트)의 접속된 영역들(셀들)을 이용하여, 추가, 삭제 등의 능률적인 처리를 수행할 수 있게 된다. 그룹 정보 및 멤버 정보는 고정된 길이(8 KB)의 영역들(블록들)에 걸쳐서 분리된 상태로 기록되고 또한 동일 그룹에 속하는 연속하는 멤버 정보는 동일 블록에 기록되기 때문에, 판독 효율이 향상된다. 또한, 그룹의 코멘트가 다른 블록에 기록되기 때문에, 코멘트 등이 없는 그룹이 기록될 때 저장 효율이 향상된다.

각각의 블록 내의 공간 영역은 블록 내의 공간 비트맵에 의해 관리되고 또한 각각의 블록 내의 공간 영역의 수 및 데이터 길이는 CMF의 상단에 있는 관리 블록에 의해 관리되므로, 메모리 상에 주재하는 데이터의 사이즈를 감소시키고 검색 량을 감소시킬 수 있게 된다. 또한, 파일 또는 그룹이 그 기록된 위치의 순서에 의해 지정되므로, 파일 정보 또는 그룹 정보 중의 그 자신의 ID 번호를 소유할 필요 가 제거되어, 그 사이즈가 감소되고, 파일 정보 또는 그룹 정보의 지정에 있어서 검색 처리의 필요가 제거된다.

Claims (44)

1. 정보 기록 매체 상에 기록된 파일들을 관리하는 방법에 있어서,

   상기 매체 상에 기록된 복수의 파일들을 복수의 그룹들로 그룹화하는 그룹 정보를 포함하는 컨텐츠 관리 파일(Contents Management File; CMF)이 제공되고,

   상기 그룹들 및 파일들의 관리가 상기 컨텐츠 관리 파일에 의하여 수행되며,

   상기 컨텐츠 관리 파일은 복수의 파일 각각을 관리하는 파일 정보를 포함하고, 상기 그룹 정보는 각각의 그룹에 속한 멤버들의 표(a table of members)를 포함하며, 상기 파일 정보는 각각의 파일이 속한 그룹에 관한 정보로서 그룹 수 정보만을 포함하는 것을 특징으로 하는

   파일 관리 방법.
2. 제1항에 있어서, 상기 컨텐츠 관리 파일은, 상기 그룹들 및 파일들의 정보를 저장하는 고정된 길이의 복수의 정보 블록들의 레코드를 포함하는 파일 관리 방법.
3. 제2항에 있어서, 각각의 상기 정보 블록은, 고정된 길이의 정보 저장 단위인 복수의 셀들, 및 상기 각각의 셀들의 이용 상태를 관리하기 위한 공간 비트맵(Space Bitmap)을 포함하는 파일 관리 방법.
4. 제3항에 있어서, 각각의 정보 블록에 포함된 상기 셀들의 사이즈 및 수는 상기 셀들을 포함하는 정보 블록의 타입에 따라 다른 파일 관리 방법.
5. 제3항에 있어서, 각각의 상기 셀에 포함된 개개의 정보를 특정하는 ID가 상기 셀의 저장 위치에 대응하는 번호에 의해 관리되는 파일 관리 방법.
6. 제2항에 있어서, 각각의 상기 정보 블록은, 상기 기록 매체의 에러 정정 단위(ECC 블록)를 2의 멱수(1, 2, 4, 8, 16, ...)로 나눈 몫과 같은 사이즈를 갖는 파일 관리 방법.
7. 제2항에 있어서, 상기 정보 블록에 아무런 공간 영역도 존재하지 않을 때, 동일 사이즈의 블록을 추가함으로써 영역이 획득되는 파일 관리 방법.
8. 제1항에 있어서, 상기 컨텐츠 관리 파일은, 일반 정보, 파일 타입의 리스트, 데이터 생성기의 리스트, 정보 블록 타입의 리스트, 각각의 정보 블록에 포함된 데이터 수의 리스트, 및 정보 블록 관리 정보를 포함하는 전체 컨텐츠 관리 파일의 관리 정보의 레코드를 포함하는 파일 관리 방법.
9. 제8항에 있어서, 상기 정보 블록 관리 정보는, 상기 컨텐츠 관리 파일 중의 상기 각각의 정보 블록의 위치에 관한 정보를 지니는 파일 관리 방법.
10. 제8항에 있어서, 상기 정보 블록 관리 정보는, 상기 각각의 정보 블록에 포함된 유효 셀들의 수를 나타내는 정보와 상기 각각의 정보 블록의 유효 데이터 길이를 나타내는 정보의 레코드를 포함하는 파일 관리 방법.
11. 삭제
12. 제10항에 있어서, 상기 정보 블록에 있어서, 유효 데이터 길이 내의 공간 영역이 존재하는지 부재하는지 여부는 상기 유효 셀들의 수와 상기 유효 데이터 길이와의 비교에 의해 결정되고, 그에 따라서 상기 정보 블록에 기록될 데이터의 기록 위치가 상기 공간 비트맵을 이용하지 않고도 결정될 수 있는 파일 관리 방법.
13. 제8항에 있어서, 상기 컨텐츠 관리 파일이, 상기 컨텐츠 관리 파일에 기록될 수 있는 최대수의 정보 블록에 상당하는 블록 관리 정보를 포함하는 경우에도, 상기 관리 정보는 초기 사이즈를 초과하지 않는 파일 관리 방법.
14. 제1항에 있어서, 상기 그룹 정보는 그룹들의 그룹화도 허용하는 계층적 구성으로 되어 있고, 상기 계층적 구성은 파일들의 그룹화의 관리를 위한 자식 그룹 정보 및 상기 자식 그룹 정보의 그룹화의 관리를 위한 부모 그룹 정보로 이루어지는 적어도 2 레벨의 구성인 파일 관리 방법.
15. 제1항에 있어서, 상기 그룹 정보 중 적어도 하나는 상기 파일들의 기록 시퀀스에 기초한 그룹인 파일 관리 방법.
16. 삭제
17. 삭제
18. 삭제
19. 제2항에 있어서, 상기 정보 블록은 문자열을 저장하는 텍스트 정보를 포함하는 파일 관리 방법.
20. 제19항에 있어서, 상기 텍스트 정보는 상기 그룹 정보의 컨텐츠를 기술하는 문자열을 포함하는 파일 관리 방법.
21. 제2항에 있어서, 상기 그룹 정보는 관련 그룹과 관련된 상기 텍스트 정보의 ID 번호를 포함하는 파일 관리 방법.
22. 제19항에 있어서, 상기 텍스트 정보는 텍스트에 대한 참조 링크를 갖는 그룹의 ID 번호를 포함하는 파일 관리 방법.
23. 제19항에 있어서, 상기 텍스트 정보는 텍스트의 길이에 관한 길이 정보 및 파일 시스템의 문자 코드와 동일한 문자 코드로 이루어지는 문자 정보를 포함하는 파일 관리 방법.
24. 제2항에 있어서, 상기 그룹 멤버 정보는 고정된 사이즈의 상기 셀들(그룹 멤버 기술자)의 단위들로 구성되고 상기 사이즈를 초과하는 정보 용량을 갖는 그룹 멤버 정보는 복수의 셀들에 걸쳐서 기록되는 파일 관리 방법.
25. 제24항에 있어서, 하나의 그룹을 구성하는 그룹 멤버 정보는 상기 정보 블록의 단일 블록에 기록되는 파일 관리 방법.
26. 제1항에 있어서, 각각의 파일은 복수의 자식 그룹 정보에 의해 관리될 수 있고, 상기 그룹 수 정보는 속한 자식 그룹의 수(링크 카운트)를 포함하는 파일 관리 방법.
27. 제26항에 있어서, 자식 그룹의 각각의 자식 그룹 정보는 복수의 부모 그룹 정보에 의해 관리될 수 있고, 각각의 자식 그룹 정보는 상기 자식 그룹 자체가 속하는 부모 그룹의 수를 나타내는 정보(링크 카운트)를 포함하는 파일 관리 방법.
28. 제26항에 있어서, 상기 파일의 링크 카운트가 0 이외의 값일 때, 상기 파일이 삭제된 후에도 상기 파일 상에 겹쳐 쓰기가 금지되는 파일 관리 방법.
29. 제27항에 있어서, 상기 자식 그룹 정보의 링크 카운트가 0 이외의 값일 때, 상기 자식 그룹 정보가 삭제된 후에도 상기 자식 그룹 정보 상에 겹쳐 쓰기가 금지되는 파일 관리 방법.
30. 제26항에 있어서, 상기 자식 그룹 정보에 포함된 파일들의 리스트를 이용하는 중에 어떤 파일의 삭제가 발견될 때, 상기 파일은 상기 자식 그룹으로부터 삭제되고, 상기 파일의 링크 카운트는 1만큼 감소되고, 상기 링크 카운트가 0이 될 때 상기 파일 정보의 영역은 겹쳐 쓰기 가능 상태로 설정되는 파일 관리 방법.
31. 제27항에 있어서,

    상기 부모 그룹 정보에 포함된 지식 그룹들의 리스트를 이용하는 중에 어떤 자식 그룹의 삭제가 발견될 때, 상기 자식 그룹은 상기 부모 그룹으로부터 삭제되고, 상기 자식 그룹의 링크 카운트는 1만큼 감소되고, 상기 링크 카운트가 0이 될 때 상기 자식 그룹 정보의 영역은 겹쳐 쓰기 가능 상태로 설정되는 파일 관리 방법.
32. 제1항에 있어서, 상기 컨텐츠 관리 파일은, 자식 그룹 정보의 하나로서, 복 수의 파일들의 재생 또는 표시 또는 프린트의 순서를 기술하는 파일을 관리하는 파일 관리 방법.
33. 제14항에 있어서, 상기 자식 그룹 정보는 각각 대표 파일을 나타내는 정보를 포함하는 파일 관리 방법.
34. 제33항에 있어서, 상기 대표 파일은 상기 자식 그룹 정보에 속하는 상위 멤버(top member)인 파일 관리 방법.
35. 제14항에 있어서, 상기 부모 그룹 정보는 각각 대표 자식 그룹을 나타내는 정보를 포함하는 파일 관리 방법.
36. 제35항에 있어서, 상기 대표 자식 그룹은 그 부모 그룹에 속하는 상위 멤버인 파일 관리 방법.
37. 제1항에 있어서, 상기 파일 정보 중에서 상기 파일들의 확장자는 1바이트의 식별 정보에 의해 관리되고 상기 컨텐츠 관리 파일은 각각의 확장자와 식별 정보 사이의 대응표(파일 타입 표)를 포함하는 파일 관리 방법.
38. 제37항에 있어서, 동일 확장자들이 용도가 서로 다를 때, 서로 다른 정보들 이 각각의 확장자에 할당되는 파일 관리 방법.
39. 제2항에 있어서, 상기 파일 정보는 동일 확장자 내의 파일들의 식별을 용이하게 하기 위하여 파일들의 컨텐츠를 나타내는 보조 속성 정보를 포함하는 파일 관리 방법.
40. 제8항에 있어서, 상기 일반 정보는 디스크 ID로서 UUID 정보를 포함하는 파일 관리 방법.
41. 제8항에 있어서, 복수의 디스크 사이에, 각각의 디스크에 기록된 상기 UUID 정보 및 갱신 날짜 및 시간이 비교되고, 그에 따라서 어떤 하나의 디스크에 포함된 정보가 다른 디스크에 포함된 정보와 일치하는지 여부 및 어떤 하나의 디스크가 다른 디스크의 사본인지 여부가 결정되는 파일 관리 방법.
42. 제8항에 있어서, 상기 일반 정보는 초기화 날짜 및 시간 및 상기 컨텐츠 관리 파일의 생성 날짜 및 시간을 나타내는 정보를 포함하고, 기록된 디스크가 다른 디스크의 사본인지 여부는 상기 초기화 날짜 및 시간 및 상기 생성 날짜 및 시간의 상기 정보가 서로 일치하는지 여부에 기초하여 결정되는 파일 관리 방법.
43. 제8항에 있어서, 상기 컨텐츠 관리 파일은, 디스크의 로딩 시간 또는 전원의 인가 시간에 자동적으로 시작될 파일 또는 그룹의 정보를 나타내는 정보를 포함하는 파일 관리 방법.
44. 제8항에 있어서, 상기 컨텐츠 관리 파일은 디스크가 자동적으로 시작될 것인지 여부를 나타내는 정보를 포함하는 파일 관리 방법.

Images