KR20060052365A - 컴퓨터 파일 시스템 - Google Patents

컴퓨터 파일 시스템 Download PDF

Info

Publication number
KR20060052365A
KR20060052365A KR1020050103108A KR20050103108A KR20060052365A KR 20060052365 A KR20060052365 A KR 20060052365A KR 1020050103108 A KR1020050103108 A KR 1020050103108A KR 20050103108 A KR20050103108 A KR 20050103108A KR 20060052365 A KR20060052365 A KR 20060052365A
Authority
KR
South Korea
Prior art keywords
file system
item
data
file
stored
Prior art date
Application number
KR1020050103108A
Other languages
English (en)
Inventor
앤드류 지. 바이비
아닐 케이 노리
발란 세투 라만
티모시 피. 맥키
왈터 알. 스미스
Original Assignee
마이크로소프트 코포레이션
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 마이크로소프트 코포레이션 filed Critical 마이크로소프트 코포레이션
Publication of KR20060052365A publication Critical patent/KR20060052365A/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/13—File access structures, e.g. distributed indices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F1/00—Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units

Abstract

본 발명은 그 파일 시스템의 조직 구조 내에 아이템을 포함시키더라도 아이템의 수명이 융합(conflate)되지 않는 파일 시스템을 개시한다. 또한, 파일 시스템의 조직 구조는 디렉토리 트리에 국한되지 않고, 임의의 DAG(directed acyclic graph)를 이용할 수 있다. 아이템이 파일 시스템에 일단 저장되면, 그것이 DAG의 일부인지 여부와 무관하게, 아이템들은 그 파일 시스템의 클라이언트에 의해 확정적으로 삭제(delete)될 때까지 유지될 수 있다. 아이템들은, 클라이언트가 아이템 수명을 제어하고, 유저가 선택한 임의의 DAG 구조로 아이템들을 조직화하는 개념적 작업공간인 파일 영역에 놓여질 수 있다. 아이템들은 복수의 DAG에 동시에 저장될 수 있고, 각 파일 영역은 하나 이상의 독립적인 DAG를 가질 수 있다. DAG 내의 아이템의 배치는 네임스페이스, 보안, 프라이버시, 및 판독/기입 속성 등의 파일 특성들을 제어하는 데 이용될 수도 있다.
파일 시스템, 파일 영역, DAG, API, LOC 테이블

Description

컴퓨터 파일 시스템{COMPUTER FILE SYSTEM}
도 1은 본 발명의 일 실시예에 따른 매체 유저 인터페이스의 실행에 적합한 일반적인 오퍼레이팅 환경을 나타내는 도면.
도 2는 공지의 파일 시스템들의 전형적인 조직 구조를 나타내는 도면.
도 3은 본 발명의 일 실시예에 따른 로케이션 테이블(LOC)을 나타내는 도면.
도 4는 본 발명의 일 실시예에 따른 조직 테이블(ORG)을 나타내는 도면.
도 5는 도 4에 나타낸 조직 테이블에 따른 DAG(Directed Acyclic Graph) 조직 구조를 나타내는 도면.
도 6은 본 발명의 일 실시예에 따른 파일 시스템의 블록도.
도 7은 본 발명의 일 실시예에 따른 파일 영역(region)을 나타내는 도면.
도 8은 도 7의 조직 구조를 정의하는 조직 테이블을 나타내는 도면.
도 9는 본 발명의 일 실시예에 따른 파일 영역을 나타내는 도면.
도 10은 도 9의 조직 구조를 정의하는 조직 테이블을 나타내는 도면.
도 11은 본 발명의 일 실시예에 따른 조직 테이블을 나타내는 도면.
도 12는 도 11에 나타낸 조직 테이블에 따른 파일 영역을 나타내는 도면.
도 13은 본 발명의 일 실시예에 따른 파일 시스템에 저장된 아이템들을 관리하기 위한 방법을 설명하는 도면.
<도면의 주요 부분에 대한 부호의 설명>
144:오퍼레이팅 시스템 148:파일 시스템
165:디지타이저 180:원격 컴퓨터
본 특허 문헌의 공개 중 일부는 저작권 보호의 대상인 요소를 포함한다. 특허청 특허 파일 또는 기록으로서 공개될 경우, 저작권자는 그 특허 문헌 또는 특허 공개의 팩시밀리 복사에 대한 이의제기권이 없지만, 그 외에는 모든 저작권에 대해 권리를 갖는다.
본 발명은 일반적으로 컴퓨터 시스템에 대한 파일 시스템에 관한 것이다. 더 구체적으로, 본 발명은 파일 시스템에 저장된 아이템들의 수명이 파일 시스템에 의해 이용된 하부 조직 구조(underlying organizational structure)와 융합되지 않는 파일 시스템을 제공함으로써, 그 파일 시스템에 저장된 아이템들이 삭제의 위험없이 각각 상기 조직 구조 내에서 0, 1, 또는 그 이상의 부모(parent)를 갖도록 허용한다.
컴퓨터는 디스크 드라이브 등의 기억 장치에 파일을 저장한다. 이 디스크 드라이브는 비어있는 파일 캐비넷과 유사하게, 데이터 저장을 위한 공간만을 제공한다. 빈 파일링 케비넷이 파일에 대해 미리 정의된 임의의 파일 시스템을 수반하지 않는 것처럼(즉, 파일링 캐비넷의 유저는, 예컨대 파일을 알파벳순으로 정리함 으로써 파일링 시스템 또는 조직 구조를 스스로 생성해야 한다), 하드 드라이브도 기본적으로 빈 기억 공간일 뿐이다. 하드 드라이브상의 데이터에 억세스하는 유일한 방법은 데이터의 물리적 로케이션(location)을 특정함으로써(예컨대, 파일이 저장되어 있는 하드 드라이브의 섹터, 헤드, 및 실린더를 특정함으로써), 또는 디스크상의 그 논리 로케이션(예컨대, 21,671번째 블록)에 의해서이다. 컴퓨터에 하드 디스크 드라이브가 일단 인스톨되면, 컴퓨터는 쉽게 억세스가능한 방식으로 하드 디스크 드라이브에 저장된 파일을 추적하기 위해 파일 시스템을 이용한다.
공지의 파일 시스템은 오퍼레이팅 시스템 및 파일 시스템의 유저가 그 파일 시스템 내의 파일들을 조직화할 수 있는 방법을 과도하게 제한한다. 즉, 공지의 파일 시스템은 일반적으로 유저에게 파일 및 디렉토리의 트리 내의 아이템들을 조직화하도록 요구하는데, 여기서 디렉토리는 사실상 파일 시스템에 의해 식별된 특정 종류의 파일이다. 파일 시스템이 추가적인 데이터 구조를 지원할지라도, 이러한 성능은 일반적으로 파일 시스템의 클라이언트(즉, 최종 유저 및 어플리케이션)에게는 드러나지 않는다. 도 2는 현재 파일 시스템들의 전형적인 조직 구조(201)에 대한 간단한 예를 나타낸다. 도 2에 나타낸 바와 같이, 공지의 파일 시스템은 디렉토리들(라운드형 단부로 나타낸) 및 파일들(사각형 단부로 나타낸)을 조직화하는 트리를 이용한다. 트리 구조에 있어서, 아이템의 로케이션 및 조직은 융합되어 있다; 각 아이템은 한 개, 정확히 말해 하나의 디렉토리 내에 있어야 한다. 유저는 이러한 방식으로 자신의 파일들을 조직화해야 하고, 아이템의 새로운 카피의 생성없이 멀티플 조직들 내에 아이템을 위치시킬 수는 없다.
전형적인 파일 시스템은 파일들을 조직화하기 위해 서로 연계되어 있는 데이터베이스들 또는 2개의 테이블들을 이용한다. 제1 테이블 또는 데이터베이스는 파일이 하드 드라이브 등의 기억 장치에 저장되어 있는 물리적 로케이션을 식별하는 룩업 테이블이다. 제2 테이블은 그 파일들의 조직 구조를 정의한다. 여기서, 이들 테이블은 일반적으로 LOC(location table) 및 ORG(organizational table)로 각각 언급된다. 상기 조직 테이블은 홀딩 링크(holding link)에 관한 정보를 저장한다, 즉, 하나의 아이템은 다른 아이템의 부모이다. 어떤 파일 시스템은 로케이션 테이블 및 조직 테이블을 하나의 테이블 또는 구조로 결합시킬 수 있지만, 파일 시스템이 정상적으로 동작하기 위해서는 여전히 양측 테이블의 엘리먼트들이 존재할 것이 요구된다. 예를 들면, 마이크로소프트사에 의해 마케팅된 NT 브랜드 파일 시스템, 또는 NTFS에 있어서, 마스터 파일 테이블(Master File Table)은 로케이션 테이블 및 조직 테이블 양측 모두로서 기능한다. 마찬가지로, 유닉스 파일 시스템, UFS는 파일에 대한 로케이션 테이블 및 조직 테이블 양측 모두로서 기능하는 아이노드(i-node)의 테이블을 이용한다. 디렉토리들은 특정 종류의 파일로서 저장되는데, 그 디렉토리 "파일"은 그 디렉토리 및 각 아이노드 내에 파일명 리스트를 저장한다.
이들 및 다른 공지의 파일 시스템들에 있어서, 파일이 조직 테이블 내의 홀딩 링크로 정의된 적어도 하나의 로케이션에 배치되어 있는 한, 그 파일 시스템은 물리적 기억 장치에 저장된 파일을 보존한다, 즉, 그 파일을 포인팅하는 적어도 하 나의 홀딩 링크가 존재한다. 즉, 파일에 대한 홀딩 링크가 조직 테이블로부터 삭제되고, 그 파일을 포인팅하는 홀딩 링크가 더 이상 존재하지 않는다면, 그 파일 시스템은 로케이션 테이블 내의 파일 엔트리(entry)를 제거(remove)한다(파일이 기억 장치상에서 물리적으로 오버라이트 되는지 여부와 무관하게). 다음, 상기 기억 장치는 새로운 데이터를 기입하기 위한 기억 공간을 이용할 수 있다. 예를 들어, 유저가 도 2에 나타낸 C:＼PROGRAMS＼MICROSOFT＼OFFICE＼WORD＼FILE.DOC 파일을 "삭제(delete)" 하면, 파일 시스템은 조직 테이블로부터 파일 엔트리를 우선적으로 제거한다. 만약 그 파일이 로케이션 테이블 내의 다른 엔트리를 갖지 않는다면, 즉, 그 파일이 다른 곳에도 저장되어 있지 않다면, 파일 시스템은 로케이션 테이블 내의 파일 엔트리를 제거하여, 다른 데이터를 위한 공간으로 비어둔다. 전형적으로, 이 파일 시스템은 임의의 주어진 아이템이 갖는 선조(ancestor)들("홀딩 링크들"이라 함)의 참조 횟수를 유지한다. 아이템에 대한 최후의 홀딩 링크가 제거될 경우, 그 아이템은 로케이션 테이블 내의 파일 레퍼런스를 제거함으로써 "삭제" 된다. 그러나, 이것은 파일 시스템이 이용할 수 있는 조직 구조를 제한하기 때문에, 최종 유저 관점에서는 바람직하지 못하다.
상기 제한들(예컨대, 트리로부터 파일을 제거함에 의한 삭제)로 인해, 파일 시스템들은 클라이언트가 디렉토리들이나 파일들의 트리형 계층 이외의 데이터 구조들 내의 데이터를 조직화하도록 허용하지 않는다. 유저는 주어진 아이템이 삭제될 것에 대한 염려없이, 다양한 조직 데이터 구조내에서 아이템들을 조직화하거나 해체할 수 있기를 원한다. 아이템의 수명이 파일 시스템 내의 조직으로부터 분리 된다면, 이는 당해 기술분야에 있어서 진일보한 것이다. 즉, 아이템을 조직화 또는 해체하는 작용이 그것의 수명에 영향을 주지 않는, 아이템 수명과 조직 구조가 융합되지 않는 파일 시스템을 제공하는 것은 진일보한 것이 될 것이다. 이에 따라, 오퍼레이팅 시스템 및/또는 유저가 파일들을 조직화할 수 있는 데이터 구조들의 타입을 제한하지 않고, 또한 파일 시스템 내의 모든 조직 구조들로부터 제거되었다거나 그 파일을 지정하는 홀딩 링크를 갖지 않는다는 이유만으로 파일을 삭제하지 않는 파일 시스템을 제공하는 것은 그 기술 분야에서 진일보한 것이 될 것이다.
이하, 본 발명의 여러 양태들의 기본적 이해를 제공하기 위해 본 발명의 간단한 요약을 기술한다. 본 요약은 본 발명의 광범위한 개괄은 아니다. 본 발명의 기본적 또는 불가결한 엘리먼트를 확인시키는 것도 아니며, 본 발명의 범위를 묘사하기 위한 것도 아니다. 이하의 요약은 후술할 상세한 설명에 대한 서론으로서 간단한 형태로서 본 발명의 몇 가지 개념을 제시하는 것에 불과하다.
상기 종래 기술에 있어서의 하나 이상의 제한들, 및/또는 본 명세서를 읽고 이해하고자 할 때 명백해질 다른 제한들을 극복하기 위해, 본 발명은 일반적으로 컴퓨터 판독가능 매체에 저장된 컴퓨터 실행가능 명령문들 및 데이터 아이템들로서 구현된 파일 시스템에 주목하고 있다. 데이터 아이템들은 일반적으로, 이에 국한되는 것은 아니지만, 파일들, 폴더들, 데이터, 음악 등을 포함하는 파일 시스템 내에 저장될 수 있는 임의의 데이터를 가리킨다. 파일 시스템은 그 파일 시스템 내 에 저장된 적어도 제1, 제2 및 제3 데이터 아이템들에 대한 아이템 로케이션 정보를 저장하는 제1 데이터 테이블을 이용하며, 제1 및 제2 데이터 아이템들에 대한 조직 정보를 저장하지만 제3 데이터 아이템에 대한 조직 정보는 저장하지 않는 제2 데이터 테이블을 이용한다.
상기 파일 시스템의 파일 시스템 매니저 소프트웨어 모듈은 컴퓨터 판독가능 매체에 저장된 컴퓨터 실행가능 명령문들로서 구현될 수 있다. 이 파일 시스템 매니저는 아이템 로케이션 데이터 및 아이템 조직 데이터에 기초하여 파일 시스템 내에 저장된 데이터 아이템들을 관리한다. 이 파일 시스템 매니저는 그 파일 시스템으로부터 아이템들을 삭제하기 위해 제1 서브루틴을 이용하며, 그 파일 시스템으로부터 아이템들을 제거하기 위해 제2 서브루틴을 이용한다.
이 파일 시스템 매니저는 그 파일 시스템으로부터 제1 아이템을 삭제하기 위한 제1 요청의 수신을 포함하여, 파일 시스템에 저장된 아이템들을 관리하는 방법을 행하며, 상기 제1 요청에 응답하여, 그 파일 시스템에 관련된 로케이션 정보 및 그 파일 시스템에 관련된 조직 정보로부터 제1 아이템에 대한 레퍼런스를 삭제한다. 파일 시스템 매니저는 그 파일 시스템으로부터 제2 아이템을 제거하기 위한 제2 요청을 수신하며, 상기 제2 요청에 응답하여, 그 파일 시스템에 관련된 조직 정보로부터 제2 아이템에 대한 레퍼런스를 삭제하지만, 파일 시스템에 관련된 로케이션 정보로부터 제2 아이템에 대한 레퍼런스를 삭제하지는 않는다.
본 발명의 다른 관점에 따르면, 컴퓨터 판독가능 매체에 저장된 컴퓨터 실행가능 명령문들로서 파일 시스템이 구현되는, 데이터 아이템들을 저장하는 파일 시 스템이 제공된다. 상기 파일 시스템에 있어서, 파일 시스템 내의 데이터 아이템들에 대한 임의의 개념적인 조직 내에서 데이터 아이템 수명은 그 데이터 아이템의 로케이션에 독립적이다.
첨부한 도면을 참조한 이하의 설명으로부터 본 발명 및 그 장점들이 더욱 명확히 이해될 것이며, 유사한 참조 부호는 유사한 특징을 나타낸다.
이하의 다양한 실시예의 설명에 있어서, 그 일부를 형성하고, 본 발명이 실시될 수 있는 다양한 실시예의 설명에 의해 나타낸 첨부 도면을 참조한다. 다른 실시예들이 이용될 수 있으며, 본 발명을 벗어나지 않는 범위 내에서 구조적 및 기능적 변경이 이루어질 수도 있음을 알 수 있을 것이다.
[예시적 컴퓨팅 환경]
도 1은 본 발명이 실시될 수 있는 적절한 연산 시스템 환경(100)의 일례를 나타낸다. 연산 시스템 환경(100)은 적절한 연산 환경의 단지 일례일 뿐이며, 본 발명의 기능성 또는 이용 영역에 대한 어떤 제한을 제시하기 위해 의도된 것은 아니다. 연산 시스템 환경(100)이 예시적 오퍼레이팅 환경(100)에 나타낸 컴포넌트의 하나 또는 그들 조합에 관련된 어떤 요청이나 의존성을 갖는 것으로 해석되어서도 아니된다.
본 발명은 수많은 다른 범용 또는 전용의 연산 시스템 환경들 또는 구성들에 의해 실시가능하다. 본 발명에 적합하게 이용될 수 있는 공지의 연산 시스템들, 환경들, 및/또는 구성의 예는, 이에 국한되는 것은 아니지만, 퍼스널 컴퓨터, 서버 컴퓨터, 핸드 헬드(hand-held) 또는 랩탑 디바이스, 멀티프로세서 시스템, 마이크 로 프로세서-기반 시스템, 셋 탑 박스, 프로그램가능한 가전, 네트워크 PC, 미니컴퓨터, 메인프레임 컴퓨터, 상기 시스템들 또는 디바이스들 중 임의의 것을 포함하는 분산 컴퓨팅 환경 등을 포함한다.
본 발명은, 컴퓨터에 의해 실행되고 있는 프로그램 모듈 등과 같이, 컴퓨터 실행가능 명령문들의 일반 콘텍스트(context)에서 기술될 수 있다. 일반적으로, 프로그램 모듈은 특정 태스크를 행하거나 특정 추상 데이터형을 실행하는 루틴, 프로그램, 오브젝트, 컴포넌트, 데이터 구조 등을 포함한다. 또한, 본 발명은 통신 네트워크를 통해 링크되는 원격 처리 장치에 의해 태스크들이 행해지는 분산 컴퓨팅 환경에서도 실시될 수 있다. 분산 컴퓨팅 환경에 있어서, 프로그램 모듈은 메모리 기억 장치를 포함하는 원격 및 로컬 컴퓨터 기억 매체 모두에 배치될 수 있다.
도 1을 참조하면, 본 발명을 실현하기 위한 예시적인 시스템은 컴퓨터(110) 형태의 범용 컴퓨팅 장치를 포함한다. 컴퓨터(110)의 컴포넌트들은, 이에 국한되는 것은 아니지만, 프로세싱 유닛(120), 시스템 메모리(130), 및 시스템 메모리를 포함하는 각종 시스템 컴포넌트들을 프로세싱 유닛(120)에 연결하는 시스템 버스(121)를 포함할 수 있다. 시스템 버스(121)는 임의의 버스 아키텍처를 이용하는 로컬 버스, 주변 장치 버스(peripheral bus), 및 메모리 버스나 메모리 컨트롤러를 포함하는 여러 타입의 버스 구조들 중 임의의 것이 될 수 있다. 일례로서, 이에 국한되는 것은 아니지만, 그러한 아키텍처들은 ISA(Industry Standard Architecture) 버스, MCA(Micro Channel Architecture) 버스, EISA(Enhanced ISA) 버스, VESA(Video Electronics Standards Association) 로컬 버스, 및 메자닌(Mezzanine) 버스라고도 알려진 PCI(Peripheral Component Interconnect)를 포함한다.
컴퓨터(110)는 일반적으로 각종 컴퓨터 판독가능 매체를 포함한다. 컴퓨터 판독가능 매체는 컴퓨터(110)에 의해 억세스될 수 있는 이용가능한 임의의 매체일 수 있으며, 휘발성 및 비휘발성 매체, 분리형 및 비분리형 매체 모두를 포함한다. 일례로서, 이에 국한되는 것은 아니지만, 컴퓨터 판독가능 매체는 컴퓨터 기억 매체 및 통신 매체를 포함한다. 컴퓨터 기억 매체는 컴퓨터 판독가능 명령, 데이터 구조, 프로그램 모듈 또는 그 외 데이터 등의 정보 기억을 위한 임의의 기술 또는 방법으로 실현되는 분리형 및 비분리형, 휘발성 및 비휘발성 매체 모두를 포함한다. 컴퓨터 기억 매체는, 이에 국한되는 것은 아니지만, RAM, ROM, EEPROM, 플래시 메모리 또는 다른 메모리 기술, CD-ROM, 디지털 다기능 디스크(DVD) 또는 다른 광 디스크 기억장치, 마그네틱 카세트, 마그네틱 테이프, 마그네틱 디스크 기억장치 또는 다른 마그네틱 기억 장치들, 또는 정보를 저장하는 데 이용될 수 있고 컴퓨터(110)에 의해 억세스될 수 있는 임의의 다른 매체나 매체의 조합을 포함한다. 통신 매체는 일반적으로 컴퓨터 판독가능 명령, 데이터 구조, 프로그램 모듈 또는 반송파나 다른 전송 메카니즘과 같은 변조 데이터 신호 내의 다른 데이터로서 구현되며, 임의의 정보 전달 매체를 포함한다. "변조 데이터 신호" 는 그 신호 내의 정보를 부호화하도록, 그와 같은 방식으로 설정 또는 변경된 하나 이상의 특성을 갖는 신호를 의미한다. 일례로서, 이에 국한되는 것은 아니지만, 통신 매체는 유 선 네트워크나 다이렉트-와이어 접속 등의 유선 매체와 어쿠스틱, 적외선 및 기타 무선 매체 등의 무선 매체를 포함한다.
시스템 메모리(130)는 일반적으로 ROM(Read Only Memory)(131) 및 RAM(Random Access Memory)(132) 등의 휘발성 및/또는 비휘발성 메모리 형태의 컴퓨터 기억 매체를 포함한다. 기동시와 같이, 컴퓨터(110) 내의 엘리먼트들 간의 정보 전송을 돕는 기본 루틴들을 포함하는 기본 입/출력 시스템(133)(BIOS)은 일반적으로 ROM(131)에 기억되어 있다. RAM(132)은 일반적으로 프로세싱 유닛(120)에 의해 즉시 억세스가능하며 또한/또는 현재 오퍼레이팅되고 있는 프로그램 모듈 및/또는 데이터를 포함한다. 일례로서, 이에 국한되는 것은 아니지만, 도 1은 오퍼레이팅 시스템(134), 어플리케이션 프로그램(135), 다른 프로그램 모듈(136), 프로그램 데이터(137), 및 파일 시스템(138)을 나타낸다.
또한, 컴퓨터(110)는 다른 분리형/비분리형, 휘발성/비휘발성 컴퓨터 기억 매체를 포함할 수도 있다. 일례로서, 도 1은 비분리형, 비휘발성 마그네틱 매체로부터 판독하거나 그 매체로 기입하는 하드 디스크 드라이브(140), 분리형, 비휘발성 마그네틱 디스크(152)로부터 판독하거나 그 디스크(152)로 기입하는 마그네틱 디스크 드라이브(151), 및 CD ROM이나 그 외 광 매체 등의 분리형, 비휘발성 광 디스크(156)로부터 판독하거나 그 디스크(156)로 기입하는 광 디스크 드라이브(155)를 나타낸다. 예시적 오퍼레이팅 환경에 이용될 수 있는 다른 분리형/비분리형, 휘발성/비휘발성 컴퓨터 기억 매체는, 이에 국한되지는 않지만, 마그네틱 테이프 카세트, 플래시메모리 카드, 디지털 다기능 디스크, 디지털 비디오 테이프, 솔리드 스테이트 RAM, 솔리드 스테이트 ROM 등을 포함한다. 하드 디스크 드라이브(141)는 일반적으로 인터페이스(140) 등의 비분리형 메모리 인터페이스를 통해 시스템 버스(121)에 접속되어 있으며, 마그네틱 디스크 드라이브(151) 및 광 디스크 드라이브(155)는 일반적으로 인터페이스(150) 등의 분리형 메모리 인터페이스에 의해 시스템 버스(121)에 접속되어 있다.
상기 논의된 또한 도 1에 나타낸 드라이브 및 그 관련 컴퓨터 기억 매체는 컴퓨터 판독가능 명령, 데이터 구조, 프로그램 모듈 및 그 외 컴퓨터(110)에 대한 데이터의 기억 장치를 제공한다. 도 1에서는, 예를 들어, 기억 오퍼레이팅 시스템(144), 어플리케이션 프로그램(145), 다른 프로그램 모듈(146), 프로그램 데이터(147), 및 파일 시스템(148)으로서 하드 디스크 드라이브(141)가 나타나 있다. 이들 컴포넌트들은 오퍼레이팅 시스템(134), 어플리케이션(135), 다른 프로그램 모듈(136), 프로그램 데이터(137), 및 파일 시스템(138)과 동일하거나 상이할 수 있다. 오퍼레이팅 시스템(144), 어플리케이션 프로그램(145), 다른 프로그램 모듈(146), 프로그램 데이터(147), 및 파일 시스템(148)은, 예컨대 그것들이 상이한 카피임을 나타내기 위해 도 1에서 상이한 숫자로 주어져 있다. 유저는 일반적으로 마우스, 트랙볼 또는 터치 패드로 언급되는 키보드(162) 및 포인팅 디바이스(161) 등의 입력 장치를 통해 명령 및 정보를 컴퓨터(20)에 입력할 수 있다. 그 외 입력 장치는 리모트 컨트롤(163), 마이크로폰, 조이스틱, 게임 패드, 위성 안테나(satellite dish), 스캐너 등을 포함할 수 있다(도시하지 않음). 이들 및 다른 입력 장치들은 대개 시스템 버스에 연결되는 유저 입력 인터페이스(160)를 통해 프로세싱 유닛 (120)에 접속되어 있지만, 병렬 포트, 게임 포트 또는 USB(Universal Serial Bus)와 같이, 다른 인터페이스 및 버스 구조에 의해 접속될 수도 있다. 또한, 모니터(191) 또는 다른 타입의 표시 장치(예컨대, TV)도 영상 인터페이스(190) 등의 인터페이스를 통해 시스템 버스(121)에 접속되어 있다. 모니터 외에도 컴퓨터는 출력 주변 인터페이스(190)를 통해 접속될 수 있는 프린터(196) 및 스피커(197) 등의 다른 주변 출력 장치를 포함할 수 있다.
어떤 양태에 있어서는, 수서 입력(freehand input)을 디지털로 캡처하기 위해, 펜 디지타이저(pen digitizer)(165) 및 그에 따른 펜 또는 스타일러스(166)가 제공된다. 펜 디지타이저(165)와 유저 입력 인터페이스(160) 간의 다이렉트 접속을 나타냈지만, 실제로, 펜 디지타이저(165)는 다이렉트로 프로세싱 유닛(110)에, 무선을 포함하는 임의의 기술에 의해 병렬 포트나 다른 인터페이스 및 시스템 버스(130)에 연결될 수 있다. 또한, 펜(166)은 그것과 관련된 카메라 및 카메라에 의해 캡처된 화상 정보를 버스(130)와 상호작용하는 인터페이스에 무선으로 전송하는 트랜시버를 구비할 수 있다. 또한, 상기 펜은 가속도계(accelerometer), 자력계(magnetometer), 및 자이로스코프를 포함하는 전자 잉크의 스트로크를 측정하기 위한 카메라 외에, 또는 그 카메라를 대신하여, 다른 감지 시스템을 구비할 수 있다.
컴퓨터(110)는 원격 컴퓨터(180) 등의 하나 이상의 원격 컴퓨터에 대한 논리적 접속을 이용하여 네트워크화된 환경에서 동작할 수 있다. 원격 컴퓨터(180)는 퍼스널 컴퓨터, 서버, 라우터, 네트워크 PC, 피어 디바이스(peer device) 또는 다른 공통 네트워크 노드가 될 수 있으며, 비록 도 1에는 메모리 기억 장치(181)만을 나타냈지만, 일반적으로, 컴퓨터(110)에 비해 전술한 엘리먼트들의 전부 또는 많은 것을 포함한다. 도 1에 나타낸 논리적 접속들은 LAN(Local Area Network)(171) 및 WAN(Wide Area Network)(173)을 포함하지만, 다른 네트워크를 포함할 수도 있다. 이러한 네트워킹 환경들은 오피스, 기업 범위(enterprise-wide) 컴퓨터 네트워크, 인트라넷 및 인터넷에서는 흔한 것이다. 또한, 상기 시스템은 유선 및/또는 무선 능력을 포함할 수 있다. 예를 들면, 네트워크 인터페이스(170)는 블루투스, SWLan, 및/또는 조합 능력의 IEEE 802.11 클래스를 포함할 수 있다. 그 외 무선 통신 프로토콜은 이들 프로토콜과 연계하여 또는 이들 프로토콜 대신에 이용될 수 있다.
LAN 네트워크 환경에 이용되는 경우, 컴퓨터(110)는 네트워크 인터페이스 또는 어댑터(170)를 통해 LAN(171)에 접속된다. WAN 네트워크 환경에 이용될 경우, 컴퓨터(110)는 일반적으로 모뎀(172) 또는 인터넷 등의 WAN(173)을 통해 통신을 확립하는 기타 수단을 포함한다. 내장형 또는 외장형일 수 있는 모뎀(172)은 유저 입력 인터페이스(160), 또는 다른 적절한 메카니즘을 통해 시스템 버스(121)에 접속될 수 있다. 네트워크 환경에 있어서, 컴퓨터(110), 또는 그 부분들과 비교하여 묘화된 프로그램 모듈들은 원격 메모리 기억 장치에 저장될 수 있다. 일례로서, 이에 국한되는 것은 아니지만, 도 1은 메모리 장치(181)에 존재하는 원격 어플리케이션 프로그램(185)을 나타낸다. 도면에 나타낸 네트워크 접속들은 예시적인 것이며, 상기 컴퓨터들 간의 통신 링크를 확립하는 다른 수단이 이용될 수도 있을 것이다.
도면에 나타낸 네트워크 접속들은 예시적인 것이며, 상기 컴퓨터 간의 통신 링크를 확립하는 다른 기술들이 이용될 수도 있을 것이다. TCP/IP, 이더넷, FTP, HTTP 등과 같은 각종 공지의 프로토콜들 중 임의의 프로토콜의 존재가 추정되며, 그 시스템은 유저가 웹 기반 서버로부터 웹 페이지를 검색하도록 허용하는 클라이언트-서버 구성에 의해 동작될 수 있다. 웹 페이지 상에 데이터를 표시하고 조작하기 위해, 종래의 각종 웹 브라우저들 중 임의의 브라우저가 이용될 수 있다.
본 발명의 하나 이상의 양태들은, 하나 이상의 프로그램 모듈과 같이, 컴퓨터(110) 와 같은 하나 이상의 컴퓨터 또는 다른 장치에 의해 실행되는 컴퓨터 실행가능 명령문들에 의해 구현될 수 있다. 일반적으로, 프로그램 모듈은 컴퓨터 또는 다른 장치 내의 프로세서에 의해 실행될 경우에 특정 추상 데이터형을 실행하거나 특정 태스크를 행하는 루틴, 프로그램, 오브젝트, 컴포넌트, 데이터 구조 등을 포함한다. 컴퓨터 실행가능 명령문들은 하드 디스크, 광 디스크, 분리형 기억 매체, 솔리드 스테이트 메모리, RAM 등의 컴퓨터 판독가능 매체에 저장될 수 있다. 당업자에 의해 예견가능한 것으로서, 상기 프로그램 모듈의 기능성은 다양한 실시예에서 원하는 바에 따라 조합 또는 분산될 수 있다. 또한, 상기 기능성은 집적 회로, FPGA(Field Programmable Gate Arrays) 등의 펌웨어 또는 하드웨어의 등가물의 전체 또는 일부에 의해 구현될 수 있다.
[실시예]
본 발명의 일 양태에 따르면, 여기서 기술된 파일 시스템은 아이템 수명이 파일 시스템의 조직 구조 내의 아이템 배치와 융합되지 않기 때문에, 하나 이상의 DAG(Directed Acyclic Graphs)를 형성하는 프로퍼티 베이스 쿼리(property based query) 및 리스트 등을 통해, 아이템을 여러 조직에 관련시키거나 전혀 관련되지 않게 한다. DAG는 아이템이 복수의 부모를 가질 수 있는 조직이다. DAG에 있어서, 아이템은 사이클을 형성하는 그 조상들 중 하나를 부모로 할 수 없다.
여기에 기술된 파일 시스템은, 예컨대 파일 시스템(138) 및/또는 파일 시스템(148) (도 1)으로서, 컴퓨터 판독가능 매체에 저장된 컴퓨터 실행가능 명령문들에 의해 구현될 수 있다. 또한, 도 1에서 다른 컴퓨터 판독가능 매체 또는 메모리도 현재 기술된 파일 시스템과 동일하거나 상이한 파일 시스템을 포함할 수 있다. 예를 들면, 매체 152 및 156도 파일 시스템을 포함할 수 있다. 설명을 위해, 여기서는 파일 시스템(148)을 참조하여 상기 파일 시스템을 기술한다.
도 3 및 도 4를 참조하면, 파일 시스템(148)은 일차적으로 2개의 테이블, LOC(Location table)(301) 및 ORG(Organizational table)(401)에 의존한다. LOC(301)는, 예컨대 파일 식별자(ID)(303), 파일명(305), 스토리지 볼륨(storage volume)(307), 로케이션(309), 및 파일 크기(311)를 포함하는 파일 시스템 내에 저장된 각 아이템의 물리적 및/또는 논리적 기억 장소에 관한 정보를 저장한다. 파일 ID(303)는 각 아이템을 참조하는 데 사용되는 일차적인 키 또는 레퍼런스이며, 파일 시스템(148)에 저장된 각 아이템에 대해 고유한 것이다. 각 파일 ID가 파일 시스템(148)에 저장된 단일 아이템을 고유하게 식별하는 한, 파일 ID는 숫자, 알파벳 텍스트, 기호, 또는 임의의 조합을 포함한다.
파일명(305)은 파일 시스템(148)의 유저에 의해 제공된 아이템의 짧은 서술 적 파일명을 포함할 수 있다. 파일명(305)은 각 파일에 대한 유저의 일차적인 개념적 레퍼런스로 하는 것이 바람직하며, 그 파일명에 기초하여 유저가 그 파일을 쉽게 인식하도록 서술적인 형식으로 유저에 의해 지정될 수 있다. 파일명(305)은 예컨대, 8.3 포맷, 최대 길이 256 문자, 또는 다른 어떤 최대 길이 등의 제한된 길이가 될 수 있다. 바람직한 것은, 파일명들이 서로 중복될 수 있는지 여부, 또는 파일명이 요구되거나 할당되었는지 여부에 대해서 조차 제한이 없는 것이다. 즉, 각 파일이 고유한 파일 ID(303)를 갖는 한, 동일한 디렉토리, 폴더, 또는 리스트 내일지라도 다중의 파일들이 각각 "README.TXT" 또는 "Read this first" 로 명명될 수 있다. 이는 파일이 그 부모의 컨텍스트 내에서 고유명을 갖도록 요구하는 기존의 파일 시스템과는 다른 것이다.
볼륨(307), 로케이션(309), 및 사이즈(311)는 물리 또는 논리 스토리지 로케이션으로부터 아이템을 검색하는 데 사용될 수 있다. 볼륨(307)은, 예컨대 물리 또는 논리 하드 디스크 드라이브, 광 기억장치, 기억장치 매체 카드, 솔리드 스테이트 기억 장치 등의 물리 또는 논리 기억 장치를 참조할 수 있다. 로케이션(309)은 식별된 물리 또는 논리 볼륨상의 아이템의 실제 스타팅 로케이션을 참조할 수 있으며, 사이즈(311)는 식별된 로케이션에서 개시되는 식별 볼륨에 아이템이 저장되어 있는 공간의 측정량을 참조할 수 있다. 포함된 정보가 각 식별 기억 장소로부터 각 저장된 아이템을 검색하는 데 이용가능한 한, LOC 테이블(301)에는 부가적 또는 대안적 정보가 포함될 수 있다.
ORG 테이블(401)은 파일 시스템(148)에 저장된 아이템들 간의 계층 관계를 저장한다. 간략히 전술한 바와 같이, ORG 테이블(401)은, 파일 시스템(148) 내의 아이템들을 개념적으로 정렬하기 위해, 하나 이상의 트리를 포함할 수 있는 하나 이상의 DAG(Directed acyclic graph)를 정의할 수 있다. ORG 테이블(401)은 각 관계에 있어서, 부모(403) 및 자식(405)을 포함할 수 있다. 도 5는 LOC 테이블(301)의 부분들 및 ORG 테이블(401)에 의해 정의된 DAG(501)의 일례를 나타낸다. 아이템 I2는 "To Do List" 및 "Items For My Trip" 양측에 의해("내(in)" 에 존재하는 것으로 되기도 한다) 부모가 되고, 아이템 I4는 "Items For My Trip" 및 "Key Slide Decks" 양측에 의해 부모가 되기 때문에, DAG(501)는 트리가 아니다. 조직 구조가 DAG로 남는 한, 파일 시스템(148)에 저장된 각 아이템은 부모를 갖지 않거나, 하나의 부모, 또는 2 이상의 부모를 가질 수 있다.
도 6은 파일 시스템(148)에 사용될 수 있는 소프트웨어 모듈들의 블록도를 나타낸다. 파일 시스템(148)은 파일 시스템(148)의 총괄적인 오퍼레이션을 관리하는 파일 시스템 매니저 소프트웨어 모듈(601)을 가질 수 있다. 매니저(601)는 DAG에 존재하는 임의의 제한(예컨대, 사이클이 허용되지 않음)에 관한 규칙들을 강요하지만, 여기에 기술된 바와 같은 LOC 테이블(301) 및 ORG 테이블(401)을 이용하여, 데이터 저장소(611)에 저장된 아이템들을 추가, 갱신, 삭제, 및 판독/조회할 수 있다. 매니저(601)는, 오퍼레이팅 시스템 등의 하이 레벨 프로그램들이 파일 시스템(148)과 상호작용할 수 있는 하나 이상의 API(Application Programming Interface)를 드러낼(expose) 수 있다. API는 추가_아이템 API(603), 갱신_아이템 API(605), 삭제_아이템 API(607), 및 조회_아이템 API(609)을 포함할 수 있다.
추가_아이템 API(603)은 새로운 아이템이 파일 시스템(148)에 저장될 경우에 오퍼레이팅 시스템 또는 다른 하이 레벨 프로그램이나 어플리케이션에 의해 호출될 수 있다. 추가_아이템 API(603)는 파일명에 따라, 선택적으로는 의도된 스토리지 볼륨 및/또는 부모 ID에 따라, 새로운 아이템의 현재 일시적인 저장 위치에 대한 포인터를 입력으로서 수용할 수 있다. 추가_아이템 API는 새롭게 추가된 아이템에 대한 파일 ID를 선택적으로 반환할 수 있다.
갱신_아이템 API(605)는 파일 시스템(148)에 이미 저장된 현존하는 아이템을 갱신하기 위해 호출될 수 있으며, 파일 ID 및 아이템의 새 버젼에 대한 포인터로부터 선택된 하나 이상의 선택적으로 포함된 정보, ORG 테이블(401) 내의 포함에 대한 갱신 관계, 및/또는 갱신 파일명을 입력으로서 수용할 수 있다.
삭제_아이템 API(607)은 삭제될 삭제_아이템 API 파일 ID로 넘김으로써, 파일 시스템(148)으로부터 아이템을 제거하기 위해 호출될 수 있다. 삭제_아이템 API(607)가 명백하게 호출되는 경우에만 파일 시스템(148)으로부터 아이템이 삭제된다.
조회_아이템 API(609)는 OS 또는 어플리케이션에 의한 이용을 위해 파일 시스템으로부터 아이템이 검색될 필요가 있는 경우에 호출될 수 있다. 조회_아이템은 파일 ID를 입력으로서 수용하며, 요청된 아이템을 반환한다. 상기 열거된 API는 본 발명의 예시적 실시예에 바람직하게 포함되어 있는 API 타입의 대표적인 것이다. 파일 시스템(148)은 시스템 수요와 디자인에 기초하여 추가적인 또는 대안적인 API를 포함할 수 있다.
파일 시스템(148)은 각 아이템이 0 이상의 부모를 갖도록 허용하기 때문에, 단일 볼륨 또는 파일 시스템 내에 멀티플 독립 데이터 구조(즉, 멀티플 DAG)가 존재할 수 있다. 이것은, 일반적으로 볼륨 당 단일 트리 내에 아이템들을 저장하도록 클라이언트(유저 또는 어플리케이션)를 제한하는 공지의 파일 시스템과는 상이하다. 따라서, 여기에 기술된 바와 같이 파일 시스템에 아이템들이 저장되어 있는 개념적 공간은 FR(File Region:파일 영역)로서 언급된다. 파일 영역은 아이템의 수명을 제어하는 데 사용되는 조직 에어리어(area)의 하이 레벨 유저 개념을 가리킨다. 아이템이 파일 영역 내에 남아 있는 동안은, 아이템이 ORG 테이블(401)에서 정의된 임의의 부모-자식 관계에 종속되어 있는지 여부와 무관하게, 상기 아이템은 삭제되지 않을 것이다.
아이템들이 개념적으로 관련되어 있는지와는 무관하게, 파일 영역은 개념적으로 아이템들이 놓여질 수 있는 박스로서 간주될 수 있다. 아이템이 파일 영역 내에 놓여지면, 그 아이템은 유저가 그 아이템을 삭제할 때까지 그 파일 영역에 남게 된다. 아이템이 파일 영역 내에 있는 동안, 그 아이템은 아이템이 파일 영역 내에 있는지 여부에 대한 영향(impact)을 받지 않고, 또한 아이템의 수명에 대한 영향을 받지 않고, 그 파일 영역 내에 임의의 하나 이상의 DAG로 조직화될 수 있다. 즉, 유저가 파일 시스템에 대해 그 파일을 삭제하도록 확정적으로 지시할 때까지는 상기 파일은 삭제되지 않는다. 아이템 수명을 보장하기 위해 단일 파일 영역으로서 데이터 저장소가 관리되는 동안은, 포함된 모든 데이터가 동일한 컴퓨터, 네트워크 등 내에서 서로 물리적으로 인접하고 있는지 여부와는 무관하게, 상기 파 일 영역은 임의로 정의된 어떠한 기억 에어리어라도 포위할 수 있다. 예를 들면, 파일 영역은 컴퓨터상의 모든 내장형 하드 드라이브, 컴퓨터상의 싱글 하드 드라이브의 일부, 단체(單體) 또는 로컬 스토리지와 결합된 네트워크 스토리지, 또는 그 외 정의된 임의의 저장 공간을 포위할 수 있다.
도 7 및 도 8은 3개의 독립적인 DAG 501, 703, 및 705를 갖는 파일 영역(701)을 나타낸다. DAG 501, 703, 및 705 간의 유일한 위임(mandate) 관계는 이들이 동일한 파일 영역 내에 위치하고 있다는 것이며, 이들 간에 요청되는 어떠한 개념적인 관계도 존재하지 않는다. 도 8은 도 7에 나타낸 DAG를 설명하는 ORG 테이블(801)을 나타낸다. 도 7은 파일 영역(701)의 개념도를 나타내는 반면, 도 8은 파일 영역(701)에 이용된 홀딩 링크들을 나타낸다. 파일 시스템(148)이 모든 "탑-레벨(top-level)", 또는 "플로팅(floating)"을 갖는 유저에게 상기 파일 시스템에 의해 정의된 파일 영역 내의 아이템들을 제공할 수 있는 지점에서, 유저는 파일 영역(701)을 오픈할 수 있다. 여기서 사용된 바와 같이, 파일 영역에 대응하는 ORG 테이블 내의 다른 아이템들로부터 임의의 홀딩 링크에 의해 타겟이 되지 않는다면, 아이템은 "탑-레벨" 또는 "플로팅"으로서 정의된다. 따라서, 도 7에 있어서, 아이템들 i1, i7, To Do List, 및 Items For My Trip은 탑 레벨 아이템들, 또는 플로팅 아이템들로 간주된다. 최종 유저에 대해, 리스트 i7은 조직 데이터 구조의 형태이다. 다중 부모의 개념에 기초하여, 아이템은 멀티플 리스트 내의, 예컨대, 아이템 i3이 될 수 있다. 리스트는 정렬 또는 비정렬된 다른 아이템들을 홀딩하는 아이템이며, 리스트들은 유저들이 공동작업하는 데 익숙한 폴더/디렉토리를 이전 파일 시 스템 내로 재배치시킨다. 리스트들은 다른 리스트들 내에 있을 수도 있으며, 다른 리스트들을 홀딩할 수도 있다.
시스템(148)은, 유저 또는 어플리케이션(통합하여 클라이언트로 지칭)이 그 하부 조직 구조로부터 아이템을 삭제하기를 원하는 경우와, 클라이언트가 파일 시스템으로부터 상기 아이템을 완전히 삭제하기를 원하는 경우를 구분한다. 도 9 및 10은 유저 또는 어플리케이션이 Key Slide Decks 리스트로부터 아이템 i5를 제거한 후의 파일 영역(801)을 나타낸다. 즉, 매니저(601)는 갱신_아이템 API(605)을 통한 요청에 기초하여, Key Slide Decks(파일 ID 000007)를 아이템 i5(파일 ID 000006)의 부모로 식별하는 ORG 테이블(1001) 내의 홀딩 링크를 제거한다. 아이템 i5에 관련된 모든 홀딩 링크들이 ORG 테이블(401)로부터 제거되었기 때문에, 아이템 i5는 더 이상 멀티-아이템 조직 구조의 일부가 아니다. 그러나, 아이템i5는 파일 영역(801)에 남아 있기 때문에, 아이템 i5는 파일 시스템(148) 또는 LOC 테이블(301)로부터 삭제되지 않는다. 환언하면, 클라이언트가 아이템 i5의 삭제를 요청하지 않고, 아이템 i5의 제거를 요청했기 때문에, 아이템 i5는 데이터 저장소(611) 및 LOC 테이블(301)로부터 삭제되지 않는다. 아이템 i5의 선택과 삭제_아이템 API(607)를 통한 삭제 오퍼레이션의 요청을 확정적으로 행한 클라이언트에 대해서만, 매니저(601)는 아이템 i5(파일 ID 000006)를 데이터 저장소(611) 및 LOC 테이블(301)로부터 제거할 것이다.
도 11 및 12를 참조하면, 공지의 파일 시스템, 예컨대 디렉토리 트리에 이용된 조직 구조에 기초하여, 유저에게 친숙한 조직 구조를 모방(mimic)하는 데 파일 시스템(148)이 이용될 수 있다. LOC 테이블(301)(도 3)을 다시 참조하면, 파일 ID 000301-000312 를 갖는 아이템들은 파일 시스템(148)에 저장된 리스트들에 대한 홀딩 링크들을 나타낸다. 각 비정렬 리스트는 파일 영역(1201)(도 12) 및 ORG 테이블(1101)(도 11)에 개념적으로 나타낸 디렉토리 트리(1203) 내의 디렉토리를 나타낸다. 디렉토리 트리(1203)와 공지의 디렉토리 트리 간의 주된 차이점은 2개의 "User Data" 비정렬 리스트들 중 어느 하나를 통해 서브 디렉토리 "Shared" 는 억세스가능하여, 파일 시스템(148)의 다중 부모 능력을 이용할 수 있다는 것이다. 이러한 방식으로, 유저들에게 친숙한 조직 구조를 제공하면서도 유저들 사이에서 디렉토리들이 쉽게 공유될 수 있다.
본 발명의 일 실시예에 따르면, 파일 시스템(148)은, 파일 시스템(148)이 실행되는 네트워크 또는 컴퓨터 시스템의 각 개인 유저에 대해 개인 작업공간(private workspace)을 제공하며, 또한 그 컴퓨터 시스템 또는 네트워크의 모든 유저가 이용할 수 있는 공유 작업공간(shared workspace)도 제공한다. User Data 아래에는 Private 및 Shared 파일 영역 양측에 대한 네임스페이스(namespace)가 형성된다. 이는, 상기 시스템에 대한 유저의 조회가 User Data에 의해 형성된 아이템 도메인에서 루트(root)되는 것을 허용하고, 이에 따라 모든 전형적인 조회에 있어서 개인 및 공유 아이템들을 복귀시킬 것이다. 도 12의 네임스페이스를 이용하면, 파일 시스템 내의 아이템들과 상호작용(새로운 사진이나 음악의 획득, 문서의 생성 등) 하는 경우, 유저는 "이것이 개인(private)인가 아니면 공유(shared)인가?" 라는 질문을 개념적으로 고려하거나 상기 아이템을 적절한 작업공간에 위치시키는 것 만이 요구된다. 다음, 공유 작업공간의 모든 유저는 공유 작업공간으로의 공통된 시각을 갖는다. 또한, 어느 유저가 여전히 필요로 하는 아이템을 다른 유저가 삭제하면 그 유저가 그것을 복구할 수 있도록 작업공간마다 공유 리사이클 휴지통(bin)이 존재할 수 있다.
일반적인 공유 작업공간에 대한 시나리오는 홈 유저에 국한되는 것은 아니다. 공동 도메인에 대해, 지식있는 작업자라면 동료들이 프로젝트를 공동수행할 수 있는 공유 작업공간을 설정할 수 있다. 작업공간의 이러한 유연성은 아이템들을 조직화하고, 작업공간 내의 아이템들에 대해 조회하는 능력을 작업공간의 각 유저에게 제공할 것이며, 이들 아이템들의 일반적인 총체적 시각을 제공한다.
도 13은 하부 조직 구조로부터 아이템을 제거하는 방법 및/또는 파일 시스템(148)으로부터 아이템을 제거하는 방법을 나타낸다. 우선, 단계 1301에서, 클라이언트는 특정 파일 ID를 갖는 아이템을 선택한다. 다음, 단계 1303에서, 클라이언트는 파일 시스템(148)으로부터 아이템을 완전히 삭제하기를 원하는지, 또는 그 하부 조직 구조로부터 그 아이템을 단순히 제거하기를 원하는지를 지정한다. 만약 클라이언트가 단계 1303에서 "제거"를 선택한다면, 단계 1305에서 파일 시스템 매니저는 아이템의 파일 ID가 자식 열(child column)에 존재하는 ORG 테이블로부터 모든 엔트리를 삭제한 후, 종료된다.
만약, 단계 1303에서 클라이언트가 "삭제"를 선택한다면, 단계 1307에서 파일 시스템 매니저(601)는, 아이템의 파일 ID가 부모 열(parent column)에 존재하는 각 ORG 테이블 엔트리에 대해, 이미 ORG 내에 존재하지 않는다면, 자식이 자식이며 ITEM의 부모(들)가 부모인 ORG 테이블 내의 엔트리를 추가한다. 이용될 수 있는 의사코드(pseudocode)는 다음과 같다:
X부모 = 파일_ID(ITEM)인 각 ORG 테이블 엔트리 X에 대해
Y자식 = 파일_ID(ITEM)인 각 ORG 테이블 엔트리 Y에 대해
만약 ORG 테이블이 엔트리(Y부모,X자식)를 갖지 않는다면
ORG 테이블 엔트리(Y부모,X자식)을 추가한다
이에 따라 ORG 테이블을 갱신한 후, 단계 1309에서 파일 시스템 매니저는, 상기 아이템의 파일 ID를 부모 또는 자식으로서 참조하는 ORG 테이블로부터 모든 엔트리를 삭제한다. 마지막으로, 단계 1311에서, 파일 시스템 매니저(601)는 그 아이템이 저장되어 있는 곳을 지정하는 LOC 테이블로부터 그 엔트리를 삭제한다. 또한, 파일 시스템 매니저(601)는 안전한 소거(erase) 오퍼레이션을 행하고, 취소(undelete) 오퍼레이션이 행해질 수 없도록 아이템의 로케이션에 저장된 데이터를 가비지(garbage) 데이터로 오버라이트할 수 있다.
대안적으로, 상기 파일 시스템 매니저는 단계 1307를 스킵하고, 아이템이 부모나 자식 중 어느 하나인 단계 1309에서, ORG 테이블로부터 모든 엔트리를 단순히 삭제할 수도 있다. 상기 대안의 부작용은, 파일 시스템(148)의 조직 구조 내에 남아 있는 제2 아이템에 의해 자식이 부모가 되지 않는다면, 삭제된 아이템의 각 자식이 파일 시스템(148)의 조직 구조로부터 제거된다는 것이다.
상기 방법에는 선택된 아이템 및 그 아이템에 의해 지정된 임의의 아이템이 그 하부 조직 구조로부터 제거되도록 나타나 있다. 그러나, 아이템이 조직 구조로부터 제거될 때, 그 아이템의 자식들이 그 조직 구조로부터 제거되지 않는 경우에 대해서는 대안적 방법들이 이용될 수 있다는 것을 당업자라면 알 수 있을 것이다. 어떻게 제거가 행해지는가는 제거 및 삭제가 두 개의 구별되는 프로세스라는 사실에 대해서는 부차적인 것인데, 즉 삭제 프로세스는 기억 장치로부터 아이템을 함께 삭제하는 반면, 제거 프로세스는 아이템의 수명에 영향을 주지 않고서(즉, 기억 장치 또는 파일 시스템으로부터 그 아이템을 삭제하지 않고서), 하부 조직 구조로부터 아이템을 제거한다.
종래의 파일 시스템 네비게이션 툴, 예컨대 워싱턴주 레드먼드의 마이크로소프트사가 개발한 윈도우즈 익스플로러 브랜드 시스템 네비게이션 툴은, 전형적으로 파일 시스템의 조직 구조 내의 파일들을 보여주기만 한다. 따라서, 클라이언트가 파일 시스템(148)의 조직 구조로부터 아이템을 제거한다면, 즉 아이템이 ORG 테이블 내에 존재한다면, 그 아이템은 파일 시스템 네비게이션 표시에 나타나지 않을 것이다. 그러나, 본 발명의 양태들을 이용하면, 조직 구조 내에 현재 없는 임의의 아이템을 찾기 위해, 클라이언트는 모든 플로팅 또는 탑 레벨 아이템들(즉, 부모가 없는 아이템들)에 대해 파일 시스템 매니저(601)를 조회할 수 있다.
ORG 테이블(401)에 의해 정의된 조직 구조에 기초하여, 파일 시스템(148)은 조회 도메인 및 보안 등의 추가적인 형태를 제공할 수 있다. 즉, 조직 구조들을 정의하는 것 외에, ORG 테이블에 있어서의 홀딩 링크들은 조회가능한 아이템 도메인을 형성하는 데 이용될 수도 있고, 또는 네임스페이스로서 참조될 수도 있다. 클라이언트는 그 아이템이 부모인 적어도 하나의 홀딩 링크에 포함된 임의의 아이템을 조회할 수 있다. 예를 들어, 도 7을 참조하면, "Items For My Trip" 에 대한 조회는 i3, i4, i5 및 i8 뿐만 아니라 Key Slide Decks를 리턴시킨다. 중복된 아이템들은 한 번만 반환되는 것이 바람직하다. 예를 들어, Key Slide Decks에 의해서도 부모를 갖는 i4는 한 번만 리턴되는 것이 바람직하다.
파일 시스템(148)의 조직 구조는 레거시 어플리케이션(legacy application)에 의해 이용을 위한 네임스페이스를 전파시키고, 파일 시스템(148)과 상호작용하는 개념적으로 인식가능한 유저 인터페이스를 제공하는 데 이용될 수도 있다. 예를 들어, 도 12를 참조하면, "U1" 아래의 아이템 "User Data"는 클라이언트에 의해 ＼User＼U1＼User Data 로서 참조될 수 있어, 개념적으로 친숙한 인터페이스를 최종 유저 및 레거시 어플리케이션에 제공한다.
ORG(401)에 의해 정의된 조직 구조는 파일 시스템(148) 내의 보안 정보를 전파시키는 데 이용될 수도 있다. 즉, 보안 테이블(도시하지 않음)은 아이템에 대한 보안 정보를 제공할 수 있다. 기본적으로, 유저가 주어진 아이템에 억세스하는 경우, 직/간접을 불문하고, 기본적으로 유저는 주어진 아이템에 의해 지정된 다른 모든 아이템에 대해 억세스한다.
예를 들면, 아이템 U1(도 12)에 대한 보안은 유저네임=Ross를 갖는 유저만이 U1 내의 파일들에 억세스할 수 있음을 나타낼 수 있다. U1의 자식인 App Data 및 User Data 아이템들에 대해 서로 다른 보안 정보가 제공되지 않는다면, Ross만이 이들 아이템들을 볼 수 있다. Private(U1의 자식인 User Data의 자식에 해당), 및 Shared에 대해서도 동일하게 유효하다. 아이템 U2에 대한 보안은 유저네임=Jordan을 갖는 유저만이 U2 내의 파일들에 대해 억세스할 수 있음을 나타낼 수 있다. U2의 자식인 App Data 및 User Data 아이템들에 대해 서로 다른 보안 정보가 제공되지 않는다면, Jordan만이 이들 아이템들을 볼 수 있다. Private(U2의 자식인 User Data의 자식에 해당), 및 Shared에 대해서도 동일하게 유효하다. 아이템 Shared가 충돌하는(conflicting) 보안 정보를 갖는 것으로 보이지만, 보안 정보는 바람직하게 더해진다. 따라서, 아이템 Shared는 "Ross 및 Jordan 만"을 허가하도록 U1 및U2 양측으로부터 보안 정보를 수신할 것이다. 또는, 아이템 U1이 "Tom은 불허, Ross만" 허가된다고 가정하자. 그러면, 아이템 Shared는 "Tom은 불허, Ross와 Jordan만" 허용되는 보안 허가를 수신할 것이다.
아이템이 ORG로부터 제거되면, 보안은 제거된 아이템으로 전파되는 것을 중지한다. 예를 들어, 도 9에 나타낸 바와 같이 "Key Slide Decks" 로부터 아이템 i5 이 제거될 경우, 유저가 i5로의 억세스가 허용되지 않는다면, 유저는 더 이상 i5로 억세스하지 않을 것이다. 그러나, 파일 시스템(148)은, 클라이언트가 아이템에 억세스하는 것이 구체적으로 금지되지 않는다면, 디폴트에 의해 클라이언트가 모든 아이템에 억세스할 수 있음을 지정할 수 있다.
상기한 바와 같이 리스트들은 네임스페이스도 형성하기 때문에, 윈도우 XP나 다른 레거시 기기(여기에 기술된 바와 같이, 작업에 있어 파일 영역, DAG 또는 리스트이 구비되지 않을 수 있는)로부터 유저가 파일 시스템(148)에 접속하는 경우, 유저는 보이는 리스트들이 네비게이트될 수 있는 폴더들로 간주할 수 있다. 마찬 가지로, 리스트(레거시 오퍼레이팅 시스템이나 파일 시스템(148)에 의해 작동가능한 시스템 상의)의 컨텍스트 내에 있는 주어진 아이템을 유저가 더블 클릭하는 경우, 파일 시스템은 현재 리스트에 의해 형성된 네임스페이스를 리퀘스팅 어플리케이션에 제공한다. 이는 상기 어플리케이션에 필요한 컨텍스트를 제공한다. 예를 들어, 리스트 "To do List"를 통해 유저가 아이템 i2의 오픈을 시도한다면, 파일 시스템은 "To do List", 즉 ＼To Do List＼i2를 통해 형성되어 있는 경로를 상기 어플리케이션에 리턴한다. 따라서, 상기 어플리케이션(예를 들어, 아이템의 새로운 카피를 생성하기 위한) 내의 "파일│ …로 저장" 명령을 선택하면, 상기 어플리케이션은 유저에게 제공할 올바른 컨텍스트를 갖게 될 것이다.
본 발명에서는, 본 발명을 실현하는 현재의 바람직한 모드들을 포함하는 구체적 예들을 기술했지만, 당업자라면 전술한 시스템 및 기술의 다양한 변경과 치환이 가능함을 알 수 있을 것이다. 따라서, 본 발명의 사상 및 영역은 첨부하는 클레임이 나타내는 바와 같이 폭넓게 이해되어야 할 것이다.
본 발명에 따르면, 주어진 아이템이 삭제될 것에 대한 염려없이, 유저는 다양한 조직 데이터 구조내에서 아이템들을 조직화하거나 해체할 수 있다. 또한, 아이템을 조직화 또는 해체하는 작용이 그것의 수명에 영향을 주지 않는, 아이템 수명과 조직 구조가 융합되지 않는 파일 시스템이 제공된다. 이에 따라, 오퍼레이팅 시스템 및/또는 유저가 파일들을 조직화할 수 있는 데이터 구조들의 타입을 제한하지 않고, 또한 파일 시스템 내의 모든 조직 구조들로부터 제거되거나 그 파일을 지 정하는 홀딩 링크를 갖지 않는다는 이유만으로 파일을 삭제하지 않는 파일 시스템이 제공된다.

Claims (22)

  1. 컴퓨터 판독가능 매체에 저장된 컴퓨터 실행가능 명령문들 및 데이터 아이템들로서 구현되는 파일 시스템으로서,
    상기 파일 시스템 내에 저장된 적어도 제1, 제2 및 제3 데이터 아이템들에 대한 아이템 로케이션 정보를 저장하는 제1 데이터 테이블; 및
    상기 제1 및 제2 데이터 아이템들에 대한 조직 정보를 저장하고, 상기 제3 데이터 아이템에 대한 조직 정보는 포함하지 않는 제2 데이터 테이블
    을 포함하는 파일 시스템.
  2. 제1항에 있어서,
    상기 제1 테이블 및 상기 제2 테이블은 분리된 테이블들을 포함하는 파일 시스템.
  3. 제1항에 있어서,
    상기 제1 테이블은 각 데이터 아이템에 대해, 고유 아이템 ID, 아이템 네임, 및 데이터 아이템의 저장 위치를 저장하는 파일 시스템.
  4. 제1항에 있어서,
    상기 제2 테이블의 각 엔트리는 저장된 2개의 데이터 아이템들 간의 관계를 정의하는 파일 시스템.
  5. 제4항에 있어서,
    상기 관계는 부모-자식(parent-child) 관계를 구성하는 파일 시스템.
  6. 제5항에 있어서,
    제2 데이터 테이블의 모든 엔트리는 DAG(directed acyclic graph)로서 집합적으로 표현될 수 있는 파일 시스템.
  7. 제4항에 있어서,
    상기 제2 테이블은 제1 데이터 아이템을 제2 데이터 아이템의 부모로서 식별하는 제1 엔트리를 저장하는 파일 시스템.
  8. 제7항에 있어서,
    상기 제2 아이템은 제1 및 제2 데이터 아이템들 간의 관계에 기초하여, 제1 아이템으로부터 보안 허가를 계승하는 파일 시스템.
  9. 컴퓨터 판독가능 매체에 저장된 컴퓨터 실행가능 명령문들로서 구현되는 파일 시스템 매니저 소프트웨어 모듈로서, 상기 파일 시스템 매니저는 아이템 로케이션 데이터 및 아이템 조직 데이터를 이용하여 파일 시스템에 저장된 아이템들을 관 리하고, 상기 파일 시스템 매니저는:
    상기 파일 시스템으로부터 제1 특정 아이템을 삭제(delete)하기 위한 제1 서브루틴; 및
    상기 파일 시스템으로부터 제2 특정 아이템을 삭제하지 않고서, 상기 파일 시스템의 조직 구조로부터 제2 특정 아이템을 제거(remove)하기 위한 제2 서브루틴
    을 포함하는 파일 시스템 매니저 소프트웨어 모듈.
  10. 제9항에 있어서,
    제1 테이블 내에 아이템 로케이션 데이터가 저장되어 있고, 제2 테이블 내에 아이템 조직 데이터가 저장되어 있는 파일 시스템 매니저 소프트웨어 모듈.
  11. 제10항에 있어서,
    상기 제1 테이블은 상기 제2 테이블로부터 분리되어 있는 파일 시스템 매니저 소프트웨어 모듈.
  12. 제10항에 있어서,
    상기 제1 서브루틴은 상기 제1 테이블 및 상기 제2 테이블로부터 제1 특정 아이템에 대한 임의의 레퍼런스를 삭제하는 것을 포함하는 파일 시스템 매니저 소프트웨어 모듈.
  13. 제12항에 있어서,
    상기 제1 서브루틴은 삭제 이전의 제1 특정 아이템에 관련된 제2 테이블 내의 엔트리들에 기초하여, 제2 테이블에 새로운 엔트리를 추가하는 것을 더 포함하는 파일 시스템 매니저 소프트웨어 모듈.
  14. 제10항에 있어서,
    상기 제2 서브루틴은 상기 제1 테이블로부터 상기 제2 특정 아이템에 대한 임의의 레퍼런스를 삭제하지 않고서, 상기 제2 테이블로부터 상기 제2 특정 아이템에 대한 임의의 레퍼런스를 삭제하는 것을 포함하는 파일 시스템 매니저 소프트웨어 모듈.
  15. 제9항에 있어서,
    상기 제1 서브루틴은 제1 API(application programming interface)를 통해 호출가능한 파일 시스템 매니저 소프트웨어 모듈.
  16. 제15항에 있어서,
    상기 제2 서브루틴은 상기 제1 API와는 상이한 제2 API를 통해 호출가능한 파일 시스템 매니저 소프트웨어 모듈.
  17. 제9항에 있어서,
    상기 조직 데이터에 기초한 보안 데이터를 더 포함하는 파일 시스템 매니저 소프트웨어 모듈.
  18. 제9항에 있어서,
    상기 파일 시스템 매니저는 상기 조직 데이터에 기초하여 각 아이템에 대한 네임스페이스를 구성하는 파일 시스템 매니저 소프트웨어 모듈.
  19. 파일 시스템 내에 저장된 아이템들을 관리하는 방법으로서,
    상기 파일 시스템으로부터 제1 아이템을 삭제하라는 제1 요청을 수신하는 단계;
    상기 제1 요청에 응답하여, 상기 파일 시스템에 관련된 로케이션 정보 및 상기 파일 시스템에 관련된 조직 정보로부터 제1 아이템에 대한 레퍼런스를 삭제하는 단계;
    상기 파일 시스템으로부터 제2 아이템을 제거하라는 제2 요청을 수신하는 단계; 및
    상기 제2 요청에 응답하여, 상기 파일 시스템에 관련된 조직 정보로부터 제2 아이템에 대한 레퍼런스를 삭제하고, 상기 파일 시스템에 관련된 로케이션 정보로부터 제2 아이템에 대한 레퍼런스를 변화시키지 않고 그대로 두는 단계
    를 포함하는 관리 방법.
  20. 데이터 아이템들을 저장하기 위한 파일 시스템으로서, 상기 파일 시스템은 컴퓨터 판독가능 매체에 저장된 컴퓨터 실행가능 명령문들로서 구현되며, 각 데이터 아이템의 수명은 상기 파일 시스템에 저장된 다른 데이터 아이템에 대한 각 데이터 아이템의 조직에 독립적인 파일 시스템.
  21. 데이터 아이템들을 저장하기 위한 파일 시스템으로서, 상기 파일 시스템은 컴퓨터 판독가능 매체에 저장된 컴퓨터 실행가능 명령문들로서 구현되며, 각 데이터 아이템의 수명은 상기 파일 시스템에 저장된 다른 데이터 아이템에 대한 그 데이터 아이템의 관계에 독립적으로 결정되는 파일 시스템.
  22. 데이터 아이템들을 저장하기 위한 파일 시스템으로서, 상기 파일 시스템은 컴퓨터 판독가능 매체에 저장된 컴퓨터 실행가능 명령문들로서 구현되며, 제1 데이터 아이템은 상기 파일 시스템 내에 저장된 다른 데이터 아이템들에 대해 부모-자식 관계를 갖지 않고 저장되는 파일 시스템.
KR1020050103108A 2004-11-12 2005-10-31 컴퓨터 파일 시스템 KR20060052365A (ko)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US10/985,907 2004-11-12
US10/985,907 US7730114B2 (en) 2004-11-12 2004-11-12 Computer file system

Publications (1)

Publication Number Publication Date
KR20060052365A true KR20060052365A (ko) 2006-05-19

Family

ID=35998539

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020050103108A KR20060052365A (ko) 2004-11-12 2005-10-31 컴퓨터 파일 시스템

Country Status (10)

Country Link
US (1) US7730114B2 (ko)
EP (1) EP1657654A3 (ko)
JP (1) JP2006139780A (ko)
KR (1) KR20060052365A (ko)
CN (1) CN1773509B (ko)
AU (1) AU2005229638A1 (ko)
BR (1) BRPI0504844A (ko)
CA (1) CA2523176A1 (ko)
MX (1) MXPA05011315A (ko)
RU (1) RU2005135118A (ko)

Families Citing this family (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7716189B1 (en) * 2005-09-23 2010-05-11 Symantec Operating Corporation Method for preserving relationships/dependencies between data in a file system
US7636737B2 (en) * 2005-12-20 2009-12-22 Microsoft Corporation Web site multi-stage recycling
JP4912026B2 (ja) * 2006-04-27 2012-04-04 キヤノン株式会社 情報処理装置、情報処理方法
US20090097825A1 (en) * 2006-05-05 2009-04-16 Harris Scott C Peer to Peer Distribution of Media Files
US9003396B2 (en) * 2006-06-19 2015-04-07 Lenovo Enterprise Solutions (Singapore) Pte. Ltd. File manager integration of uninstallation feature
CN100405373C (zh) * 2006-11-29 2008-07-23 北京中星微电子有限公司 一种文件系统的目录项整理方法
JP4843532B2 (ja) * 2007-03-14 2011-12-21 株式会社リコー 表示処理装置、表示処理方法、および表示処理プログラム
US9298480B2 (en) 2009-02-26 2016-03-29 Red Hat, Inc. Programmatic editing of text files
US8341652B2 (en) * 2009-02-26 2012-12-25 Red Hat, Inc. Method for programmatic editing of configuration files
CA2766231C (en) * 2009-06-26 2017-01-17 Simplivity Corporation Namespace file system accessing an object store
US8458765B2 (en) * 2009-12-07 2013-06-04 Samsung Electronics Co., Ltd. Browser security standards via access control
US9009686B2 (en) * 2011-11-07 2015-04-14 Nvidia Corporation Algorithm for 64-bit address mode optimization
US9317511B2 (en) * 2012-06-19 2016-04-19 Infinidat Ltd. System and method for managing filesystem objects
US20160070620A1 (en) 2013-04-08 2016-03-10 Dttp Technologies Inc. System and method for maintaining a file system at a computing device
WO2015121982A1 (ja) * 2014-02-14 2015-08-20 富士通株式会社 ドキュメント管理プログラム、装置、および方法
US9495478B2 (en) * 2014-03-31 2016-11-15 Amazon Technologies, Inc. Namespace management in distributed storage systems
US10769113B2 (en) 2016-03-25 2020-09-08 Microsoft Technology Licensing, Llc Attribute-based dependency identification for operation ordering
JP6700337B2 (ja) * 2018-05-30 2020-05-27 日本電信電話株式会社 保護装置及び保護方法

Family Cites Families (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5247658A (en) * 1989-10-31 1993-09-21 Microsoft Corporation Method and system for traversing linked list record based upon write-once predetermined bit value of secondary pointers
US5265159A (en) * 1992-06-23 1993-11-23 Hughes Aircraft Company Secure file erasure
JPH08506911A (ja) 1992-11-23 1996-07-23 パラゴン、コンセプツ、インコーポレーテッド ファイル・アクセスを行うためにユーザーがカテゴリを選択するコンピュータ・ファイリング・システム
JP2912840B2 (ja) 1994-12-07 1999-06-28 富士通株式会社 ファイル管理システム
US6647393B1 (en) * 1996-11-22 2003-11-11 Mangosoft Corporation Dynamic directory service
AU5365998A (en) * 1996-11-27 1998-06-22 1 Vision Software, L.L.C. File directory and file navigation system
US6615224B1 (en) 1999-02-23 2003-09-02 Lewis B. Davis High-performance UNIX file undelete
JP2000305829A (ja) * 1999-04-26 2000-11-02 Canon Inc フォルダ管理装置及びそのフォルダ管理方法並びに記録媒体
US8352331B2 (en) * 2000-05-03 2013-01-08 Yahoo! Inc. Relationship discovery engine
CN1381800A (zh) * 2001-01-12 2002-11-27 有限会社筑城软件研究所 联系信息管理系统、联系信息管理用程序和记录媒体
AU2002334721B2 (en) * 2001-09-28 2008-10-23 Oracle International Corporation An index structure to access hierarchical data in a relational database system
US20030229612A1 (en) * 2002-06-10 2003-12-11 Keller S. Brandon Circuit design duplication system
WO2004008348A1 (en) 2002-07-16 2004-01-22 Horn Bruce L Computer system for automatic organization, indexing and viewing of information from multiple sources
AU2003261924A1 (en) * 2002-09-05 2004-03-29 Hiroyuki Yasoshima Method for managing file using network structure, operation object display limiting program, and recording medium
JP2004126909A (ja) * 2002-10-02 2004-04-22 Panasonic Communications Co Ltd ファイル管理装置及びファイル削除方法、並びに文書処理装置、記録装置
CN100504854C (zh) * 2003-01-14 2009-06-24 联想(北京)有限公司 文件管理方法
US20040230652A1 (en) * 2003-02-14 2004-11-18 Julio Estrada System and method for message sequencing in a collaborative work environment
US7627552B2 (en) * 2003-03-27 2009-12-01 Microsoft Corporation System and method for filtering and organizing items based on common elements
US7188308B2 (en) * 2003-04-08 2007-03-06 Thomas Weise Interface and method for exploring a collection of data
US7512790B2 (en) * 2003-04-17 2009-03-31 International Business Machines Corporation Method, system and article of manufacture for management of co-requisite files in a data processing system using extended file attributes
JP3712071B2 (ja) * 2003-10-02 2005-11-02 ソニー株式会社 ファイル管理装置、ファイル管理方法、ファイル管理方法のプログラム及びファイル管理方法のプログラムを記録した記録媒体
JP4396242B2 (ja) * 2003-11-28 2010-01-13 富士ゼロックス株式会社 文書リンク構造情報作成装置及び方法
US7499921B2 (en) * 2004-01-07 2009-03-03 International Business Machines Corporation Streaming mechanism for efficient searching of a tree relative to a location in the tree
US7614007B2 (en) * 2004-01-16 2009-11-03 International Business Machines Corporation Executing multiple file management operations
US20060075071A1 (en) * 2004-09-21 2006-04-06 Gillette Joseph G Centralized management of digital files in a permissions based environment

Also Published As

Publication number Publication date
RU2005135118A (ru) 2007-05-27
JP2006139780A (ja) 2006-06-01
AU2005229638A1 (en) 2006-06-01
CN1773509A (zh) 2006-05-17
US20060106841A1 (en) 2006-05-18
BRPI0504844A (pt) 2006-06-27
MXPA05011315A (es) 2006-05-16
CA2523176A1 (en) 2006-05-12
US7730114B2 (en) 2010-06-01
EP1657654A2 (en) 2006-05-17
CN1773509B (zh) 2010-12-22
EP1657654A3 (en) 2006-09-20

Similar Documents

Publication Publication Date Title
KR20060052365A (ko) 컴퓨터 파일 시스템
JP4876734B2 (ja) 文書利用管理システム及び方法、文書管理サーバ及びそのプログラム
KR101120755B1 (ko) 정적 및 동적 리스트의 사용을 포함하는 가상 폴더 및 항목 공유 시스템 및 방법
JP4816281B2 (ja) 文書利用管理システム、文書管理サーバ及びそのプログラム
KR101343165B1 (ko) 지능적인 컨테이너 인덱싱 및 검색
CA2734675C (en) Shared namespace for storage clusters
US8694497B2 (en) Method, system, and computer program product for enabling file system tagging by applications
US8180812B2 (en) Templates for configuring file shares
JP5589205B2 (ja) 計算機システム及びデータ管理方法
US20070233647A1 (en) Sharing Items In An Operating System
JP2011065546A (ja) ファイル検索システム及びプログラム
CN104778192B9 (zh) 表示可内容寻址存储系统的目录结构
TWI334091B (en) Data file management and search method and system based on file attributes
KR20060063653A (ko) 모호한 네임을 허용하는 컴퓨터 파일 시스템
JP2007293619A (ja) サーバ装置および情報共有システムおよびプログラムおよび記録媒体
JP2007148739A (ja) ファイル管理システム及びそのプログラム
JP5082455B2 (ja) 文書管理サーバ及びプログラム
KR20060054099A (ko) 전자 파일 시스템에서 리스트와 다른 항목의 관리
JP2004133505A (ja) ファイル管理システム
JP2006268700A (ja) 文書管理方法および文書管理装置
Fogelberg An object-oriented database for advanced searches of file systems based on metadata

Legal Events

Date Code Title Description
WITN Application deemed withdrawn, e.g. because no request for examination was filed or no examination fee was paid