![]() | 배시 셸 시작하기 - ![]() 캐머런 뉴햄 & 빌로젠 블랫 지음, 배장렬 옮김/한빛미디어 |
'It's Books' 카테고리의 다른 글
1%의 행운 (0) | 2008.01.21 |
---|---|
리눅스(linux) 커널 (0) | 2008.01.18 |
CenterOS (0) | 2008.01.18 |
경청 (0) | 2007.08.16 |
금융회사가 당신에게 알려주지 않는 진실 (0) | 2007.08.16 |
![]() | 배시 셸 시작하기 - ![]() 캐머런 뉴햄 & 빌로젠 블랫 지음, 배장렬 옮김/한빛미디어 |
1%의 행운 (0) | 2008.01.21 |
---|---|
리눅스(linux) 커널 (0) | 2008.01.18 |
CenterOS (0) | 2008.01.18 |
경청 (0) | 2007.08.16 |
금융회사가 당신에게 알려주지 않는 진실 (0) | 2007.08.16 |
연산자 | 읽는 법 | 주의사항 |
* | a pointer to | |
(...) | a function(...) returning | 여기서 "..."는 인자 목록(parameter list)임 |
[N] | array[N] of | 여기서 N은 배열 크기를 나타냄 |
int * (@*foo@)(int, int) ; | foo - a pointer to ... |
int *@( *foo )(int, int)@; | foo - a pointer to a function(int, int) returning ... |
int @* ( *foo )(int, int)@; | foo - a pointer to a function(int, int) returning a pointer to ... |
@int * ( *foo )(int, int)@; | foo - a pointer to a function(int, int) returning a pointer to int. |
proc_t | a pointer to function(const void *) returning int. |
proc_t | a pointer to function(int type, const void *data) returning int. |
int (@*ap@)[30] ; | ap - a pointer to ... |
int @( *ap )[30]@; | ap - a pointer to array[30] of |
@int ( *ap )[30]@; | ap - a pointer to array[30] of int |
int *@ap[30]@ ; | ap - an array[30] of ... |
int @*ap[30]@ ; | ap - an array[30] of a pointer to ... |
@int *ap[30]@ ; | ap - an array[30] of a pointer to int |
void ( * (@*signal@)(int,void(*)(int)) )(int) ; | signal - a pointer to ... |
void ( *@( *signal )(int,void(*)(int))@)(int) ; | signal - a pointer to a function(int,void(*)(int)) returning ... |
void (@* ( *signal )(int,void(*)(int))@)(int) ; | signal - a pointer to a function(int,void(*)(int)) returning a pointer to ... |
void@( * ( *signal )(int,void(*)(int)) )(int)@; | signal - a pointer to a function(int,void(*)(int)) returning a pointer to a function(int) returning ... |
@void ( * ( *signal )(int,void(*)(int)) )(int)@; | signal - a pointer to a function(int,void(*)(int)) returning a pointer to a function(int) returning void. |
Love actually (0) | 2008.04.08 |
---|---|
Big endian vs Little endian (0) | 2007.12.21 |
파일객체와 파일지시자 비교 (0) | 2007.12.21 |
open, fopen의 차이점 (0) | 2007.12.18 |
hard link와 symbolic link (0) | 2007.12.18 |
컴퓨터에서 데이터를 메모리에 저장하는 방식은 '워드(보통 1바이트) 단위의 순서'로서 구분하는 두 방식이 있다. 리틀엔디안과 빅엔디안이 바로 그것이다.
빅엔디안 방식은 흔히 우리가 생각하는 방식이다. 예를 들면 4바이트 integer 값 0x01020304 가 메모리에 저장될때 낮은 메모리주소에 높은 자리수의 값을 저장하는 방식이다. 즉, 그 값이 저장된 임의의 메모리주소의 시작주소를 1000이라 할때 1000번지에 0x01, 1001번지에 0x02.. 이런식으로 저장된다.
리틀엔디안 방식은 인텔 0x86계열에서 사용된다고 알려졌으며 우리의 생각과는 반대의 순서로 저장된다. 낮은 메모리주소에 낮은 자리수의 값을 저장한다. 이는 CPU입장에선 메모리 주소가 높아질 수록 높은 자리수의 데이터가 들어있어 당연하게 보이지만 프로그래머 입장에선 다소 햇갈리게 되어있다.
Love actually (0) | 2008.04.08 |
---|---|
CLangauge Complex Declaration (0) | 2007.12.27 |
파일객체와 파일지시자 비교 (0) | 2007.12.21 |
open, fopen의 차이점 (0) | 2007.12.18 |
hard link와 symbolic link (0) | 2007.12.18 |
[yundream@coco test]$ ./zipcode_m Usage : ./zipcode [port] 예 : ./zipcode 4444 [yundream@coco test]$ ./zipcode_m 4444 |
[yundream@hum test]$ ps -aux | grep zipcode_m | grep -v grep yundream 14987 0.0 0.2 1340 376 ttyq1 S 15:02 0:00 ./zipcode_m 4444 [yundream@hum test]$ cd /proc/14987/fd ; ls -al 합계 0 dr-x------ 2 yundream 500 0 3월 18 15:15 . dr-xr-xr-x 3 yundream 500 0 3월 18 15:15 .. lrwx------ 1 yundream 500 64 3월 18 15:15 0 -> /dev/ttyq1 lrwx------ 1 yundream 500 64 3월 18 15:15 1 -> /dev/ttyq1 lrwx------ 1 yundream 500 64 3월 18 15:15 2 -> /dev/ttyq1 lr-x------ 1 yundream 500 64 3월 18 15:15 3 -> /home/mycvs/test/zipcode.txt lrwx------ 1 yundream 500 64 3월 18 15:15 4 -> socket:[587641] [yundream@hum fd]$ |
[yundream@hum fd]$ echo "111" > 0 [yundream@coco test]$ ./zipcode_m 4444 111 |
/* The opaque type of streams. This is the definition used elsewhere. */ typedef struct _IO_FILE FILE; |
#include <unistd.h> #include <stdlib.h> #include <stdio.h> int main() { FILE *fp; char buf[256]; printf("끝낼려면 ^D\n"); while(fgets(buf, 256, stdin) != NULL) { printf("%s", buf); } } |
#include <stdio.h> #include <string.h> #include <sys/types.h> #include <sys/stat.h> #include <fcntl.h> int main() { int fd; FILE* fp; char buf[256]; printf("끝내기 : ^D\n"); fd = open(0, O_RDONLY); fp = fdopen(0, "r"); while(fgets(buf, 256, fp) != NULL) { printf("%s", buf); } } |
CLangauge Complex Declaration (0) | 2007.12.27 |
---|---|
Big endian vs Little endian (0) | 2007.12.21 |
open, fopen의 차이점 (0) | 2007.12.18 |
hard link와 symbolic link (0) | 2007.12.18 |
FAT 파일 시스템(File System) (0) | 2007.12.17 |
/* The opaque type of streams. This is the definition used elsewhere. */ |
Big endian vs Little endian (0) | 2007.12.21 |
---|---|
파일객체와 파일지시자 비교 (0) | 2007.12.21 |
hard link와 symbolic link (0) | 2007.12.18 |
FAT 파일 시스템(File System) (0) | 2007.12.17 |
TCP 헤더 구조 (0) | 2007.12.15 |
# ln -s /usr/local/openoffice/bin/openoffice_swrite /usr/bin/swrite/usr/bin 은 환경변수 PATH에 등록이 되어있을 것이기 때문에, 간단하게 swrite만 입력하는 정도로 /usr/local/openoffice/bin/openoffice_swrite 를 실행할 수 있게 된다. 이제 ls를 이용해서 /usr/bin/swrite 의 정보를 확인해 보도록 하자.
$ ls -al swriteswrite가 원본 openoffice_swrite 를 링크하고 있는 것을 확인할 수 있을 것이다.
lrwxrwxrwx 1 root root 43 2007-11-26 23:44 swrite -> /usr/local/openoffice/bin/openoffice_swrite
# mkdir testdir이제 두개 파일의 inode를 확인해 보도록하자. stat함수를 이용해서 프로그램을 만들 필요는 없다. ls 의 -i옵션을 사용하면 간단하게 파일의 inode 값을 알아낼 수 있다.
# cp myfile testdir/myfile2
# ls -i myfile내용은 동일하지만 완전히 다른 파일이 생성되었음을 알 수 있다.
1131883 myfile
# ls -i testdir/myfile2
1163816 testdir/myfile2
# ln mydata.txt /home/dragona이제 한쪽에서 파일을 수정해보자. 다른 쪽도 그대로 수정된 내용이 반영되어 있음을 확인할 수 있을 것이다. ls -i 로 확인해보면 두개의 파일이 동일한 inode를 가지고 있음을 확인할 수 있을 것이다. 이것을 링크라고 하며, 위에서와 같이 inode를 공유해서 사용하는 것을 하드 링크 라고 한다. 이해하기 쉽게 그림으로 나타내보자면 다음과 같다.
# ls -al mydata.txt하드링크 카운터가 하나 증가해서 2가 되어 있는걸 확인할 수 있을 것이다. 파일을 하나 지우고 나서 ls 결과를 보면 카운터가 하나 줄어서 1이 되는걸 확인할 수 있을 것이다.
-rw-r----- 2 yundream yundream 192 2007-11-26 23:57 mydata.txt
# ln -s mydata.txt mydataln.txt이제 -i 옵션을 이용해서 두개 파일의 inode를 비교해 보면 서로 다른 별개의 inode를 유지하고 있음을 알 수 있을 것이다. ls -l 을 이용해서 심볼릭링크가 가리키는 원본파일의 이름을 얻어올 수 있다.
# ls -l mydataln.txt
lrwxrwxrwx 1 yundream yundream 10 2007-11-28 01:49 mydataln.txt -> mydata.txt
출처 : http://www.joinc.co.kr/modules/moniwiki/wiki.php/Site/system_programing/Book_LSP/ch03_Env
파일객체와 파일지시자 비교 (0) | 2007.12.21 |
---|---|
open, fopen의 차이점 (0) | 2007.12.18 |
FAT 파일 시스템(File System) (0) | 2007.12.17 |
TCP 헤더 구조 (0) | 2007.12.15 |
open (0) | 2007.12.15 |
FAT 파일 시스템은 전통적으로 DOS 시절부터 사용되어 왔다. FAT 파일 시스템이 다른 파일 시스템과 구별되는 점은 파일 내용을 클러스터 단위로 구성하고 이것을 링크드 리스트(Linked List)의 형태로 보관하는 것이다.
말로 하면 어려우므로, 일단 아래 그림을 보도록 하자.
<FAT의 간략한 구조>
위 그림과 같이 파일은 고정된 크기의 클러스터(Cluster) 단위로 나누어져 있으며, 그 클러스터들은 클러스터 풀(Cluster Pool)에 존재하는 클러스터를 연결한 클러스터 채인(Cluster Chain)으로 되어있다. 실제 FAT 파일 시스템에서 클러스터 풀은 FAT(File Allocation Table)이라는 용어를 사용한다.
클러스터(Cluster)란 별개 아니고 여러개의 섹터를 모아서 하나의 블럭 단위로 보는 것이다. 윈도우 포맷 프로그램을 이용해서 포맷을 하면 일반적으로 클러스터의 크기를 4Kbyte로 잡는데, 이 말은 한 섹터(Sector)의 크기가 512byte 이므로 8개의 섹터를 하나의 블럭으로 설정한다고 보면 된다.
그럼 왜 클러스터라는 말을 쓰는 것일까? 그것은 섹터를 블럭으로 관리하면 얻는 이득이 있기때문이다. 아까 잠시 클러스터 풀에 대한 이야기를 했는데, 고용량일수록 클러스터 풀(FAT 영역)이 커지게 된다. 이것이 커질수록 파일을 읽고 쓸때 관리해야 하는 양이 늘어나게되고, 또한 디스크의 비어있는 공간이 줄어들게 된다. 이것을 블럭으로 관리하게 되면 이런 문제가 해결되며, 또한 블럭 단위로 읽기 쓰기를 수행함으로 얻는 효율로 인해 성능이 좋아지게 되는 것이다.
특히 요즘처럼 파일의 크기가 큰 상황에서는 클러스터의 크기가 큰 것이 성능 향상에 도움이 된다. 하지만 클러스터의 크기가 무조건 크다고 좋은 것은 아니다. 아까 이야기 했듯이 클러스터의 단위로 작업을 하기 때문에, 작은 파일 같은 경우는 클러스터 하나를 할당받아서 대부분의 영역을 낭비하는 경우도 있으니 적당히 조절해야 한다.
자 그럼 FAT 파일 시스템의 큰 특징을 알아봤으니 세부적인 내용을 알아보자
FAT 파일 시스템은 총 3가지의 타입이 있다.
세가지 타입 모두 내부 포맷은 비슷하며, 차이점은 클러스터 개수라고 볼 수 있다.(물론 그것만 차이나는 것은 아니다. ㅡ,.ㅡ;;; 오해하지 말자.). 클러스터의 개수에 따라 FAT 타입을 분류한다고 했는데, 이 클러스터 개수는 어떻게 구하는 것일까? 실제 데이터 영역을 구성하는 크기를 가지고 계산하는 것일까?
실제 타입 구분에 사용되는 클러스터의 크기는 디스크 전체 크기를 범위로 한다. 즉 아래의 공식으로 클러스터의 크기를 구하고 그것으로 타입을 유추하는 것이다.
클러스터의 개수 = 파티션 또는 디스크의 크기 / 클러스터의 크기
이렇게 구한 클러스터의 개수는 실제로 사용가능한 데이터 영역의 클러스터의 개수와 비교하면 당연히 큰값을 가진다. 왜냐하면 디스크 또는 파티션 영역에 데이터만 들어가는 것이 아니고 FAT 파일 시스템을 관리하기위한 파일 시스템 메타 데이터(Meta Data)를 포함하기 때문이다.
이제 파티션과 메타 데이터에 대해서 알아보자.
파티션에 대해서 익히 알고있고 들어봤을 것이다. 디스크 전체를 하나로 사용하는 것이 아니라 그 안에 C: D:와 같이 영역을 분할하여 사용하는 것이 파티션이다. 파티션을 나누면 디스크를 효율적으로 관리할 수 있는 장점 때문에 약간의 디스크 공간을 낭비하더라도 파티션을 해서 많이 사용한다(아래와 같이 나눌 수도 있다).
그럼 어떻게해서 파티션이 나누어지는 것일까? 파티션을 나누게 되면 그 파티션에 대한 정보가 MBR(Master Boot Record)란 영역에 삽입되게 된다. MBR이란 디스크의 첫번째 섹터로 부트 코드와 여러가지를 정보를 포함하고 있다. MBR의 존재는 맨 마지막 510째부터 0x55 0xAA가 있는지 확인하여 이것이 있으면 MBR이 존재한다고 보면 된다(사실 다 있다. ㅡ_ㅡ;;; OS를 깔아 쓰면 저것 말고도 여러 정보가 MBR에 들어가 있다.)
MBR의 세부구조를 한번 알아보자.
헥사 에디터 프로그램으로 4개의 파티션으로 나누어진 USB 메모리의 MBR을 캡쳐한 화면이다. 좌측 상단에 0xEB 0x3C 0x90의 3Byte가 있는데, 이부분은 부트 코드의 시작으로 jmp 하라는 어셈블리어 명령이다. 굳이 필요한 것은 아니나 윈도우에서 MBR 인식을 위해서는 이 부분이 꼭 필요하다( 이부분이 0x00으로 비어져있는 경우에 윈도우가 MBR로 인식하지 못하는 것을 발견했다).
우측 하단에 0x55 0xAA의 매직넘버가 보이고 그위에 붉은 색 줄이 쳐져있는 16byte의 라인이 보인다. 이부분이 파티션 데이터의 시작으로 그 앞부분은 모두 Boot Code의 용도로 사용되거나 아니면 사용되지 않는다. 파티션 정보는 16Byte씩 4개로 총 64Byte로 되어있으며 각 항목은 아래와 같은 구조체로 되어있다.
여기서 중요하게 봐야할 부분은 위에서 파란색으로 표시된 부분인데, 그 외 부분들은 옛날 도스 시절에나 사용된 필드기 때문에 무시해도 된다. 각 필드는 아래와 같은 의미를 가진다.
위 정도값만 제대로 설정하면 윈도우에서 정상적으로 파티션 된 것으로 인식한다. MBR에 파티션 필드는 총 4개가 있으므로 파티션은 최대 4개까지 만들 수 있다. 그럼 도스 시절에는 파티션이 4개 이상이 가능했는데, 이것은 어떻게 한 것일까? 옛날 도스에서는 확장 파티션(Extension Partition)이라는 기능을 사용했다. 즉 MBR 파티션에는 확장 파티션 영역을 표시해 놓고, 확장 파티션 영역의 첫번째 섹터로 이동하면 그 첫번째 섹터에 다시 파티션 정보 + 확장 파티션 정보를 기입하는 식으로 체인으로 연결했던 것이다(이렇게 하면 디스크 용량이 허락하는 한 거의 무한대의 파티션을 생성할 수 있다. ㅡ,.ㅡ;;;;). 도스 이후에는 별로 사용하지 않으므로 일단 넘어가자. 궁금한 사람은 http://www.nondot.org/sabre/os/articles에 가서 Partition 쪽을 보면 된다.
FAT 파일 시스템을 구성하는 메타 데이터는 위와 같은 순서로 구성된다. 각 항목에 대한 설명은 아래와 같다.
PBR은 여러 이름으로 불리는데 다른 이름으로는 BPB라고도 한다. 옛날 도스 시절에 BIOS 콜을 통해 파티션에 대한 정보를 얻어오고 처리하고 했는데, 그 기본 정보가 되는 블럭이라서 저런 이름이 붙은 것 같다. 일단 여기서는 PBR이라고 하겠다.
PBR과 MBR의 차이는 무엇일까? MBR은 하나만 존재하며 섹터 0에만 있고, PBR은 각 파티션의 시작에 존재하며 FAT에 대한 정보를 포함하고 있다는 것이 다르다. PBR에는 어떤 정보가 포함되어있을까? FAT Type에 따라 다르므로 각각 살펴보도록 하자.
FAT16/32의 PBR에 포함된 데이터는 아래와 같다.
상당히 많은 데이터를 포함하고 있는데, 일단 FAT16/32에 공통인 부분부터 살펴보자.
공통인 부분들에 대해 살펴봤으니, 이제 FAT32에 특화된 부분을 보자
위의 필드 값을 FAT Type에 따라 PBR에 설정해 주면 반은 끝난 것이다. 약간 주의할 점은 Reserved Sector에 값을 설정했다면 파티션의 시작부터 Reserved Sector에 설정된 값만큼을 0으로 초기화해야한다(적극 권장). 위의 설명에도 나와있듯이 Reserved Sector의 값은 파티션의 시작부터 FAT1/2 이전까지의 섹터 수이므로, 절대 0이 될 수 없다. 왜? PBR이 있기 때문에 @0@)/~!!! 아무리 작아도 1 이상의 값을 가진다.
이제 다음 메타 데이터를 살펴보자.
FAT 1/2 영역은 클러스터의 개수에 따라서 영역의 크기가 달라진다고 이야기 했다. 여기에서 말하는 클러스터의 개수는 실제 사용가능한 클러스터의 개수를 이야기하는데, 이 크기 이상만 된다면 얼마든지 좀 크게 잡아도 상관없다.
FAT12의 경우 FAT를 구성하는 클러스터 링크의 비트수가 12bit가 이고, FAT16의 경우 16bit, FAT32의 경우 32bit이다. 따라서 한 섹터를 기준으로 FAT Type에 따라서 포함할 수 있는 클러스터 링크의 개수는 아래와 같이 된다.
위에서 보는 것과 같이 FAT32로 갈수록 한 섹터에 담을 수 있는 클러스터 링크의 개수가 작아진다. 이것은 동일한 클러스터의 크기를 사용한다면 대용량일수록 FAT의 크기가 커진다는 것을 의미하고 FAT가 커지면 커질수록 실제로 사용가능한 클러스터의 크기가 줄어들게된다. 클러스터의 크기를 적당히 조절하여 FAT 크기를 너무 크지않게 하는 것이 좋다.
FAT의 0번째 클러스터 링크와 1번째 클러스터 링크는 Signature의 용도 비슷하게 사용되는데, FAT Type에 따라 아래와 같이 설정해 준다.
자 그럼 이제 FAT의 실제 크기를 한번 계산해 보자. 가장 간단하게 계산할 수 있는 방법은 파티션 전체의 크기를 클러스터의 크기로 나누어 구하는 방법이다. 실제로 이렇게 구하면 PBR + Rerserved Area + FAT1/2 영역의 크기도 사용가능한 것으로 인식하여 계산하기 때문에 낭비가 좀 있지만 계산은 편리하다. 특히 Root Directory의 시작 위치를 맞추거나 할때는 이렇게 계산하여 FAT의 크기를 구하고 여기에 Reserved Area의 값을 조절하여 맞출 수 있어 편리하다.
또다른 방법은 전체 크기에서 PBR과 Reserved 영역을 제외하고 구하는 방법이다. 낭비가 좀 줄어들긴 한데, 식이 복잡해 진다. 아래는 그 계산 식이다(511은 올림을 위해 넣었다)
FAT의 크기(섹터) = [ ( 전체 파티션 크기(섹터) - PBR(1섹터) - Reserved Sector(?섹터) ) / 클러스터의 크기(섹터) * 클러스터 링크의 크기 + 511 ] / 512
이렇게 계산된 크기를 PBR에 wSectorsPerFAT나 dwSectorsPerFAT32 영역에 넣어주면 된다. 만약 wNumberOfFAT의 값을 2로 설정했으면 FAT1/2 영역을 연속해서 만들어줘야 하며 위의 FAT의 크기 * 2 만큼의 영역을 할당해 줘야 한다.
FAT16/32의 경우 위의 순서대로 PBR, FAT1/2 를 만들고 Root Directory Sector만 생성해 주면 정상적으로 윈도우에서 인식이 가능하다. 만약 Volume Label을 "NO NAME"으로 입력한 경우 Root Directory는 0으로 초기화 해주는 것으로 충분하다. 하지만 Volume Label을 사용한다면 Directory Entry Structure를 생성해서 Volume Label을 삽입해야 한다.
Directory Entry Structure는 아래와 같이 구성되어있다.
각 항목은 아래와 같은 의미를 가진다.
조금 복잡한데, 일단 Attribute 부터 보면 아래와 같이 나와있다(첨부 항목에 White Paper 참조).
일단 포맷 후에 Volume Label을 생성해야 하므로 ATTR_VOLUME_ID를 생성하면 된다. 이때 주의할 것은 Volume Label을 설정하는 Directory Entry의 경우 Name과 Attribute를 제외한 나머지는 모두 0으로 설정해야한다.
위를 보면 낯 익은 값들도 있을 것이다. 만약 윈도우가 FAT Filesystem으로 포맷되어있다면 위의 항목들이 설정된 Directory Entry 구조체가 여기저기 널려있을 것이다. Hex Editor와 같은 프로그램을 이용해서 하드디스크를 열어서 확인해 보자 @0@)/~~!!!!. 각 항목에 대한 자세한 설명은 White Paper를 참조하자.
Time과 Date 부분은 공통적인 포맷을 사용하는데, White Paper에 아래와 같이 나와있다(간단한 비트 연산으로 만들 수 있다).
파일 시스템 분석을 하는 경우라면 ClusterNumber와 Name, 그리고 Attribute를 유심히 봐두는 것이 도움이 될 것이다. 다른 파일 시스템이 그러하듯이 Root Directory로부터 Sub Directory가 생성되고 트리 형태로 관리되기 때문에 Root Directory를 찾은 다음 Entry 구조만 안다면 전체를 Travel 하는 것은 어렵지 않으니까...
FSInfo 영역은 FAT32에만 존재하는 영역이다. 역시 한 섹터 크기정도로 되어있고 별다른 정보를 포함하지 않는다. 단지 FAT32에 참고할만한 정보만 가지고 있다.
각 항목은 아래와 같은 의미를 가진다.
위에서 보는 것과 같이 FAT32의 부가적인 정보가 포함된 영역이고 특히 클러스터 관련 필드는 권장값이므로 절대 100% 믿으면 안된다.
여기까지 간단하게 FAT Filesystem에 대해서 알아보았다. 원래 훨씬 일찍 마무리 되었어야 하는데... 과제하느라 정신이 조금 없어서 찔끔 찔끔 정리하다보니 이제야 마무리를... ㅜ_ㅜ... 다소 부족한 감이 있지만 Formatter를 개발하면서 알아낸 정보를 기반으로 작성하였다.
다음에는 위 정보를 기반으로 실제 FAT Filesystem을 분석해 보도록 하자.
open, fopen의 차이점 (0) | 2007.12.18 |
---|---|
hard link와 symbolic link (0) | 2007.12.18 |
TCP 헤더 구조 (0) | 2007.12.15 |
open (0) | 2007.12.15 |
Library 만드는 법 (0) | 2007.12.14 |
#include <sys/types.h> |
open 은 시스템호출로, 파일을 열거나 생성 할때 사용한다. 성공하면 해당파일을 지시하는 int 형의 파일지시자를 되돌려준다. path_name 은 생성하고자 하는 파일이름을 나타낸다. 보통 full path 이름을 적어주며, 단지 파일이름만 적을경우에는 현재 경로에 파일이 생성된다.
flag 는 파일을 어떠한 mode 로 열것인지를 결정하기 위해서 사용한다. "읽기전용", "쓰기전용", "읽기/쓰기" 모드로 열수 있다. 이들 모드 선택을 위해서 O_RDONLY, O_WRONLY, O_RDWR 이 존재 한다.
또한 다음중 하나이상의 mode 를 bitwise 연산시킬수도 있다.
만약 pathname 파일이 존재하지 않을경우 파일을 생성한다.
O_CREAT 를 이용해서 파일을 생성하고자 할때, 이미 파일이 존재한다면, 에러를 되돌려주며 파일을 생성하는데 실패한다. 이러한 특성때문에 때때로 잠금 파일을 만들기 위해 사용되기도 한다.
파일이 추가모드로 열린다. 파일의 위치는 파일의 끝이된다.
파일이 비봉쇄 모드로 열린다.
경로명이 심볼릭 링크라면, 파일열기에 실패한다.
경로명이 디렉토리가 아니라면 파일열기에 실패한다.
입출력 동기화 모드로 열린다. 모든 write 는 데이타가 물리적인 하드웨어에 기록될때까지 호출 프로세스를 블록시킨다.
또한 mode 를 이용해서 에 파일의 권한을 지정해 줄수도 있다.
00400 으로 사용자에게 읽기 권한을 준다.
00200 으로 사용자에게 쓰기 권한을 준다.
00100 으로 사용자에게 실행 권한을 준다.
00070 으로 그룹에게 읽기, 쓰기, 실행 권한을 준다.
00040 으로 그룹에게 읽기권한을 준다.
00020 으로 그룹에게 쓰기권한을 준다.
00010 으로 그룹에게 실행권한을 준다.
00007 으로 기타 사용자 에게 읽기, 쓰기, 실행 권한을 준다.
00004 으로 기타 사용자 에게 읽기 권한을 준다.
00002 으로 기타 사용자 에게 쓰기 권한을 준다.
00001 으로 기타 사용자 에게 실행 권한을 준다.
O_CREAT 와 O_EXECL 이 같이 사용되었을경우 발생한다. 이미 경로파일이 존재할경우 발생된다.
파일 접근이 거부될경우이다. 주로 권한 문제 때문에 발생한다.
경로명의 디렉토리가 없거나, 심볼릭 링크가 깨져있을때.
경로명의 디렉토리가 없거나, 심볼릭 링크가 깨져있을때.
경로명이 장치파일을 참고하고, 일치하는 장치가 없을때.
경로명이 read-only 파일시스템을 참조하면서, 쓰기로 열려고 할때.
경로명이 read-only 파일시스템을 참조하면서, 쓰기로 열려고 할때.
경로명이 접근할수 없는 주소강간을 가르킬때
심볼릭 링크가 너무 많을때.
FAT 파일 시스템(File System) (0) | 2007.12.17 |
---|---|
TCP 헤더 구조 (0) | 2007.12.15 |
Library 만드는 법 (0) | 2007.12.14 |
구조체(Struct) (0) | 2007.12.13 |
이중 포인터 (0) | 2007.12.13 |