2007/10/19 작업 내용

1. 슈퍼 블록의 구조체와, file 구조체, inode 구조체에 대한 정보를 얻어내었다.

2. 시스템 콜 레퍼런스를 구해서 구현 가능할 만한 파일이 있는지 확인해보았다.



결론을 내렸을 때, 시스템 콜이나 라이브러리로는 i-node 번호만으로 접근이 불가능하다.

뭐 내가 잘 모르는 것일 수도 있지만, 시스템 콜이나 라이브러리 상의 파일 컨트롤 함수들은

어디까지나 해당 파일이 존재할 때 사용하는 함수들이다.

대부분의 파일 컨트롤 함수들은 filepath를 문자열로 받거나, file descriptor를 인자로 받는다.

file descriptor를 받기 위해서는 open, 또는 creat 함수를 사용하는데, 이 때 사용하는 인자가

filepath 문자열이므로. 결국 파일 컨트롤 함수들의 시작은 파일의 경로를 입력하여 해당 파일을

읽어들이는 것이다.



3. 인터넷을 서핑하던 중, 재미있는 자료를 찾았다.

http://www.pyrasis.com/main/Ext2FileSystem

Ex2 파일 시스템에 대해 해설하면서, 파티션의 구조를 분석하는 것으로

이 문서가 아무래도 이번 프로젝트에 필요한 기술을 나열하고 있는 것으로 생각된다.


물리적 하드 디스크의 내용을 쓰는 과정은 이미 한번 해본 적이 있어서

비교적 테스트 파일을 만드는 과정이 쉬웠으며,

수행 결과는 다음과 같았다.

하드 디스크 읽기 테스트

확대해서 보면 마지막 지점에 아래에서 2번째 줄의 맨 끝에 2Byte가 55aa로 되어있는 것을 확인 할 수 있다.
한 줄에 16개의 byte를 나열하고 있고, 16번째 줄이므로, 해당 지점의 주소는

0x1fd ~ 0x1fe (55aa)

여기서 55aa는 MBR의 마지막 지점에 붙는 것으로
Boot Record Signature라고 부른다.

(Boot Record Signature 관련 설명은 http://www.cpqlinux.com/mbr.html 를 참조)


결국 이렇게 해서 하드 디스크에서 MBR을 찾아내는 과정을 완료하였다.

현재까지 알아낸 정보를 종합하여 프로그램의 수행 과정에 대해 적어보면


* rm 파일 복원 프로그램 - 전체적인 프로그램의 수행 순서

(1) 사용자로부터 복원 대상 하드 디스크를 선택받는다.
(2) 해당 디스크의 i-node 테이블들을 확인하면서 Link가 0인 inode를 찾는다.
(3) 찾아낸 inode들의 정보를 보여주면서 복원할 파일을 선택받는다.
(4) 해당 파일을 복구