제9장 파일 시스템 인터페이스
이 장은 파일들을 다루기 위한 GNU C 라이브러리 함수들을 설명하고 있다. 7장 [I/O on Streams] 63페이지 에서 설명된 입/출력 함수들과는 달리, 이 함수들은 파일안의 내용보다는 파일 그차제를 다루는것에 대한 함수들이다.
이 절에서 설명된 것들은 디렉토리들을 조사하고, 갱신하기 위한 함수들과 파일들을 삭제하거나 재 명명하기 위한 함수들과, 엑세스 허용과, 갱신시간과 같은 파일 속성들을 조사하고, 설정하기 위한 함수들이다.
9.1 작업 디렉토리.
각 프로세스는 한 디렉토리와 연관되어 있고, 그것을 현재 작업 디렉토리라 부르거나, 간단하게 작 업 디렉토리라 부른다. 디렉토리 이름은 파일이름과 같은 방법으로 사용된다. ( 6.2.2절 [File Name Resolution] 59페이지 참조 )
당신이 로그인하고 새로운 세션(session)을 시작할 때, 당신의 작업 디렉토리는 시스템 유저 데이터 베이스안에 당신의 로그인 계정과 연관된 홈 디렉토리(home directory)로 초기설정된다. 당신은 getpwuid 나 getpwnam 을 사용해서 사용자의 홈 디렉토리를 찾을 수 있다; 25.12절[User Database] 360 페이지 참조.
--- 역자주 : 세션(session) : 사용자가 컴퓨터와의 연결이 시작된 순간부터 단절되는 순간까지를 하나의 논리적인 단위로 구분해놓은 것
사용자는 cd와 같은 쉘 명령어를 사용해서 작업 디렉토리를 변경할 수 있다. 이 절에서 설명하고 있는 함수들은 이들 명령에 의해 사용되고, 또한 작업 디렉토리를 조사하고, 변경하려는 다른 프로그 램들에 의해 사용된다. 이들 함수들의 프로토타입은 헤더파일 'unistd.h'에 선언되어 있다.
함수 : char * getcwd (char *buffer, size_t size)
getcwd 함수는 현재의 작업 디렉토리를 나타내는 파일 이름을, 당신이 제공한 문자 배열 버퍼에 그것을 저장하여 리턴한다. size인수는 버퍼의 할당 크기이다.
이 함수에서 GNU 라이브러리는 당신이 buffer 인수에 널 포인터를 지정하는 것을 허용한다. 그러 면 getcwd는 malloc( 3.3절 [Unconstrained Allocation] 22페이지)을 사용해서 자동적으로 버퍼를 할 당한다. 만일 그 size가 0보다 크다면 버퍼는 그 크기로 할당되고; 그렇지 않다면 버퍼는 결과를 저 장하기에 필요한 만큼의 크기로 할당된다.
리턴값은 성공하면 버퍼이고, 실패하면 널 포인터이다. 다음의 errno는 이 함수에서 정의하고 있는 에러 상황이다.
EINVAL
size인수가 0인데 buffer가 널 포인터가 아니다.
ERANGE
size인수가 작업 디렉토리 이름의 길이보다 작다. 당신은 배열을 더 크게 할당하고 다시 시도하라.
EACCES
읽기 요청이나, 파일이름의 구성요소 찾기가 거부되었다.
이곳에 getcwd의 표준동작만을 사용한 GNU의 getcwd (NULL, 0)의 동작을 보여주는 예가있다.
char *gnu_getcwd ()
{
int size = 100;
char *buffer = (char *) xmalloc (size);
while (1)
{
char *value = getcwd (buffer, size);
if (value != 0)
return buffer;
size *= 2;
free (buffer);
buffer = (char *) xmalloc (size);
}
}
/* 다 아시겠지만... 잠시 설명을 합죠~ xmalloc을 이용해서 100바이트 만큼의 버퍼를 할당한 다 음...
while 루프를 돌리네요. while루프의 조건을 1로 해놓고 루프안의 조건에 따라서 루프를 벗어나 게 되는데... getcwd함수를 이용해서 이름을 얻었는데, 그 크기가 0이 아니면 버퍼를 리턴하고 루 프를 벗어나고 그렇지 않으면 size에 2를 곱해서 (즉.. 버퍼의 크기를 늘리기 위해 ) 원래의 버퍼 는 해제하고 다시 큰 크기의 버퍼를 할당받아서 다시 루프의 처음으로 돌아가고.. 끝..*/
xmalloc에 대한 정보는 3.3.3절 [Malloc Examples] 22 페이지를 참조하라. xmalloc은 라이브러리 함수가 아니라 대부분의 GNU 소프트웨어에서 사용되는 사용자정의 이름이다.
함수 : char * getwd (char *buffer)
이것은 getcwd와 유사하다. GNU 라이브러리는 BSD와의 호환성을 위해 getwd를 제공하고 있다. 버퍼는 적어도 PATH_MAX 바이트 길이의 배열을 가리키는 포인터가 된다.
함수 : int chdir (const char *filename)
이 함수는 filename으로 프로세스의 작업 디렉토리를 설정하기위해 사용된다. 보통 성공하면 리턴 값은 0이다. 만일 -1이 리턴되면 에러가 발생했음을 나타낸다. 이 함수에서 정의하고 있는 에러상 황 errno는 대부분 파일 이름의 문법적 에러이고( 6.2.3절 [File Name Errors] 60페이지 참조) ENOTDIR은 파일 이름이 디렉토리가 아님을 나타낸다.
9.2 다렉토리 억세스하기.
이절에서 설명하고 있는것들은 한 디렉토리 파일의 내용을 읽는데 쓰여진다. 이것은 당신의 프로 그램이 아마도 메뉴의 일부분으로써,디렉토리 안의 모든 파일들의 리스트를 원할 때 유용하다.
opendir 함수는 디렉토리 엔트리들(entries)을 그 요소로 갖고 있는 디렉토리 스트림을 개방한다. readdir은 struct dirent objects로서 표현된 그 엔트리들을 디렉토리 스트림에서 얻기위해 사용한다. 각 엔트리를 위한 파일의 이름은 이 구조체의 d_name 안에 저장되어있다. 7장 [I/O on Streams] 63 페이지에 설명된, 원래의 파일들을 위한 스트림 도구들과 이곳에 있는것들과는 유사하다.
9.2.1 디렉토리 엔트리의 형식
이절은 당신이 디렉토리 스트림으로 부터 획득한, 단일 디렉토리 엔트리에서 무엇을 발견할수 있는 지를 설명하고 있다. 모든 심볼들은 헤더파일'dirent.h'에 선언되어 있다.
데이터타입 : struct dirent
이것은 디렉토리 엔트리들에 대한 리턴 정보로서 사용되는 구조체 타입이다. 그것은 다음과 같은 필드들은 포함하고 있다.
char *d_name
이것은 널 문자로 끝나는 파일이름 요소이다. 이것은 모든 POSIX 시스템상에서 당신이 셀 수 있는 유일한 필드이다.
ino_t d_fileno
이것은 파일 시리얼 넘버이다. BSD와의 호환성을 위해서, 당신은 d-ino로서 이 멤버를 대치할 수 있다.
size_t d_namlen
이것은 널 종료 문자가 포함되지 않은, 파일 이름의 길이이다.
이 구조체는 앞으로 부가적인 멤버들을 포함할 것이다. 파일이 다중의 이름들을 가질 때, 각각의 이름들은 자신의 디렉토리 엔트리를 갖는다. 단일 파일에 속한 디렉토리 엔트리들을 가리키는 유일 한 방법은 d_fileno 필드에 동일한 값을 줌으로써 할 수 있다.
크기, 갱신 시간 과 같은 파일 속성과, 파일 그자체의 일부분과 같은 것은 어느 특별한 디렉토리 엔 트리가 아니다. 9.8절 [File Attributes] 131페이지 참조.
9.2.2 디렉토리 스트림 개방하기
이절은 디렉토리 스트림을 어떻게 개방하는지 설명하고 있다. 모든 심볼들은 헤더파일 'dirent.h'에 선언되어 있다.
데이터타입 : DIR
DIR 데이터타입은 디렉토리 스트림을 나타낸다.
당신은 struct dirent 나 DIR 데이터타입들로 objects들을 할당받을 수 없다. 대신에 당신은 다음 에 있는 함수들을 사용함으로 인해서 리턴된 포인터를 사용해서 이들 objects를 참조할 수 있다.
함수 : DIR * opendir (const char *dirname)
opendir 함수는 파일 이름이 dirname인 디렉토리를 읽기 위해서 디렉토리 스트림을 개방하고 리턴 한다. 그 스트림은 DIR * 타입을 갖는다. 만일 성공하지 못하면 opendir은 널 포인터를 리턴한다. 보통 쉽게 일어나는 파일 이름 문법 에러들에 더하여( 6.2.3 [File Nmae Errors], 60 페이지 참조), 다음의 errno는 이 함수에서 정의하고 있는 에러 상황이다.
EACCES
dirname의 이름을 가진 디렉토리를 읽기 위한 요청이 거부되었다.
EMFILE
그 프로세스가 너무 많은 파일들을 개방했다.
ENFILE
디렉토리를 포함하고 있는 전체 시스템이나, 아마도 파일 시스템이 그 순간에 더 이상 파일을 개방 하는 것은 지원하지 않는다. ( 이 문제는 GNU시스템에서는 발생할 수 없다.
DIR 타입은 파일 기술자와, 그리고 open 함수에서 사용되는 opendir 함수에서 사용되어진다. 8장 [Low-Level I/O} 103페이지 참조. 디렉토리 스트림들과 포함된 파일 기술자들은 exec에서 폐쇠된다. 9 23.5절 [Executing a File] 327 페이지 참조 )
9.2.3 디렉토리 스트림 읽고 닫기.
이절은 디렉토리 스트림으로 부터 디렉토리 엔트리들을 어떻게 읽고, 그렇게 한 후 그 스트림을 어 떻게 닫을것인지를 설명하고 있다. 모든 심볼들은 헤더파일 'dirent.h'에 선언되어 있다.
함수 : struct dirent * readdir (DIR *dirstream)
dl 함수는 디렉토리로부터 다음 엔트리를 읽는다. 보통 리턴값은 파일에 대한 정보를 갖고 있는 구조체의 포인터이다. 이 구조체는 정적으로 할당 되고 그후에 일어나는 호출에 의해서 갱신되어질 수 있다.
이식성 노트 : 어떤 시스템에서는, readdir은 `.'과 `..'가 어느 디렉토리 에서 유용한 파일이름 일지라도, 그것들을 위한 엔트리들을 리턴하지 않을 것이다. 6.22 [File Name Resolution] 59 페 이지 참조
만일 그 디렉토리 안에 더 이상 엔트리가 없거나, 에러가 검출되면, readdir은 널 포인터를 리턴한 다. 다음의 errno는 이 함수에서 정의한 에러 상황이다.
EBADF
dirstream인수가 유용하지 않다.
함수 : int closedir (DIR *dirstream)
이 함수는 디렉토리 스트림 dirstream을 폐쇠한다. 성공하면 0을 리턴하고 실패하면 -1을 리턴한 다.
다음의 errno는 이 함수에서 정의하고 있는 에러상황이다.
EBADF
dirstream인수가 유용하지 않다.
9.2.4 디렉토리의 파일을 리스트하는 간단한 프로그램.
이곳에 현재 작업 디렉토리의 파일들의 이름을 출력하는 간단한 프로그램이 있다.
#include <stddef.h>
#include <stdio.h>
#include <sys/types.h>
#include <dirent.h>
int main (void)
{
/* DIR과 struct dirent는 위에 설명이 있네요... 흐.. */
DIR *dp;
struct dirent *ep;
/* 현재의 디렉토리를 개방해서 dp에 넣어라!!! */
dp = opendir ("./");
/* 만일 개방이 됐다면 dp의 엔트리를 읽어서 ep에 넣고 그 구조체에서 d_name멤버를 출력하라.*/
if (dp != NULL)
{
while (ep = readdir (dp))
puts (ep->d_name);
(void) closedir (dp);
}
/* 개방이 안됐다면 에러 메시지 출력... */
else
puts ("Couldn't open the directory.");
return 0;
}
디렉토리안에 나타나는 파일들의 순서는 불규칙적이다. 이것보다 더 유용한 프로그램은 그들을 출 력하기 전에 엔트리들을 정렬(아마도 알파벳 순서로..)하는 것이다; 15.3절 [Array Sort Function] 217 페이지 참조.
9.2.5 디렉토리 스트림의 랜덤 억세스.
이 절은 이미 개방된 디렉토리 스트림으로 부터 읽었던 한 부분을 어떻게 다시 읽을 수 있는지를 설명하고 있다. 모든 심볼들은 헤더파일 'dirent.h'에 선언되어 있다.
함수 : void rewinddir (DIR *dirstream)
rewinddir함수는 디렉토리 스트림 dirstream을 재설정하는데 사용되어지기 때문에 만일 당신이 readdir을 호출하면 그것은 다시 디렉토리의 첫 번째 엔트리에 대한 정보를 리턴한다. 이 함수는 또 한 opendir로 개방된후 디렉토리안의 파일들이 더해지거나, 제거된적이 있는지에 대한것도 지적한다. ( 이들 파일들을 위한 엔트리들은 당신이 마지막으로 호출했던 opendir이나 rewinddir 이후에 더해 지거나 제거된것이라면 readdir을 통해 리턴될수도, 리턴되지 않을 수도 있다.
함수 : off_t telldir (DIR *dirstream)
telldir 함수는 디렉토리 스트림 dirstream의 파일 위치를 리턴한다. 당신은 그 위치에 디렉토리 스 트림을 저장하기 위한 함수 seekdir에 이 값을 사용할 수 있다.
함수 : seekdir (DIR *dirstream, off_t pos)
seekdir함수는 pos로 디렉토리 스트림 dirstream의 파일 위치를 설정한다. 그 값 pos는 이 특별한 스트림상에서 미리 telldir을 호출한것의 결과이어야 한다; 디렉토리를 폐쇠하고, 다시 열기는 telldir 에 의해 리턴된 값들을 무효로 만들 수있다.
9.3 하드 링크
POSIX 시스템에서는, 한 개의 파일이 동시에 많은 다른이름을 소유할 수 있다. 그 이름들 모두는 동등하게 실제로 존재하고, 그들중 어느것도 다른것들을 취할 수 있다.
파일에 이름을 더하기 위해서, link 함수를 사용하라. ( 새로운 이름은 파일에 하드링크라고 불리워 진다. ) 파일에 만들어진 새로운 링크는 파일의 내용들은 복사하지 않는다; 그것은 그냥 간단히 기 존에 있는 파일에 새로운 이름을 하나 더할뿐이다.
하나의 파일은 여러개의 디렉토리들에 이름을 가질수 있어서, 파일 시스템의 구조는 정적 계층도나 트리모양이 아니다.
단일한 파일 시스템안에 존재하는 특별한 파일에서, 그 파일 이름들은 모두 단일한 파일 시스템의 디렉토리안에 존재해야만 한다. link는 다른 파일 시스템으로부터 그 파일에 하드링크를 만들려고 시도하면 에러를 출력한다.
역자주 : 그러니까.. 어떤 파일에서 링크된 것들도 모두 원래의 파일과 같은 파일 시스템안에 존재 해야지, 다른곳에 있으면 안된다는 말씀. 즉, 파일 시스템들간에 파일을 링크하는 것은 불가능하 다.
link함수의 프로토타입은 헤더파일 'uinstd.h'에 선언되어 있다.
함수 : int link (const char *oldname, const char *newname)
link함수는 oldname의 이름을 가진 현존하고 있는 파일에 newname이라는 이름을 갖는 새로운 링 크를 만든다. 이 함수는 성공하면 0을 리턴하고 실패하면 -1을 리턴한다. 보통의 파일 이름 문법 에러에 더하여서( 6.2.3절[File Name Errors] 60페이지 참조), 다음 errno는 이 함수에서 정의하고 있 는 에러상황이다.
EACCES
새로운 링크가 쓰여져야할 디렉토리가 기록 불가능이다.
EEXIST
이미 newname의 이름을 가진 파일이 있다. 만일 새로운 링크로 기존의 링크를 대치하게 원한다면, 당신은 먼저 기존의 링크를 제거해야 한다.
EMLINK
그것엔 이미 oldname에 의해 이름된 너무많은 링크가 있다. ( 링크의 최대갯수는 LINK_MAX이 다; 27.6절 [Limits for Files] 374페이지 참조.)
잘 만들어진 파일 시스템들은 결코 이 에러를 발생시키지 않는다, 왜냐하면 그들은 당신의 디스크가 가질수 있는 만큼의 많은 링크를 허용하기 때문이다. 그렇지만, 당신은 다른 기계상의 파일 시스템을 네트웍으로 억세스 할수도 있으므로, 당신의 시스템이 이런 에러를 발생시키지 않는다고 하더라도, 당신은 여전히 링크의 개수에 신경을 써야한다.
ENOENT
oldname이란 이름을 가진 파일이 존재하지 않는다. 당신은 그 파일이 없으면, 파일에 링크를 만들 수 없다.
ENOSPC
새로운 링크를 포함해야할 디렉토리나 파일 시스템이 "가득찼고" 더 이상 확장되지 않는다.
EPERM
어떤곳에서는 특권이 부여된 사용자에게만 디렉토리에 링크를 만드는 것을 허용하고, 다른 사용자 들에게는 완전히 이 명령을 금지한다. 이 에러는 그 문제를 알리기 위해 사용된다.
EROFS
디렉토리가 읽기 모드 파일 시스템이기 때문에 새로운 링크를 갖고 있는 디렉토리로 갱신되어 질 수 없다.
EXDEV
새로운 이름으로 지정된 디렉토리가 링크하려는 파일과는 다른 파일 시스템상에 존재한다.
9.4 심볼릭 링크.
GNU 시스템에서는 소프트 링크 혹은 심볼릭 링크를 지원한다. 이것은 일종의 "파일"로서 본질적 으로는 다른 파일이름을 가리키는 포인터이다. 하드링크와는 달리, 심볼릭 링크는 디렉토리나 서로 다른 파일 시스템에 아무런 제한없이 만들 수 있다. 당신은 또한 아직 어느 파일의 이름으로 존재 하지 않는 이름에 심볼릭 링크를 만들 수도 있다.( 이런 링크의 개방은 그 이름의 파일이 만들어질 때까지 실패할 것이다.). 마찬가지로, 만일 심볼릭 링크가 현존하는 파일에서 만들어지고 나중에 그 파일이 지워졌다면, 심볼릭 링크는 더이상 그파일이 존재하지 않음에도 불구하고 동일한 파일이름을 가리키며 남아있다.
심볼릭 링크라고 불리워지는 이유는 당신이 링크를 개방하려 시도할 때 그들이 행하는 특별한 작 업방법 때문이다. open함수는 당신이 링크의 지정된 이름을 인수로 준다면, 그 링크에 포함된 파일 이름을 읽어서, 대신에 그 파일 이름을 개방한다. stat함수는 마찬가지로, 링크의 그 자체 대신에 심 볼릭 링크에 연결된 그 파일상에서 동작한다. link함수는 하드 링크를 만든다.
하지만, 파일을 지우거나, 재명명하거나 하는 명령들을 링크 그 자신에서 행해진다. readlink와 lstat 함수는 또한 심볼릭 링크에서 동작하는데, 왜냐하면 그들의 목적이 링크에 대한 정보를 얻는것 이기 때문이다.
이들 함수를 위한 프로토타입은 'uinstd.h'이다.
함수 : int symlink (const char *oldname, const char *newname)
symlink함수는 oldname에 newname으로 이름된 심볼릭 링크를 만든다. symlink로부터 리턴값은 보 통 0이다. 만일 에러가 발생하면 -1을 리턴한다. 보통 파일 이름 문법 에러에 더하여서( 6.2.3절 [File Name Errors] 60 페이지 참조), 다음 errno는 이 함수에서 정의된 에러 상황이다.
EEXIST
이미 newname이름을 가진 파일이 존재한다.
EROFS
newname 파일이 읽기-모드 파일 시스템상에 존재할 것이다.
ENOSPC
디렉토리나 파일 시스템이 새로운 링크를 만들도록 확장되어질 수 없다.
EIO
디스크에 데이터를 쓰거나, 읽는 동안 하드웨어 에러가 발생했다.
함수 : int readlink (const char *filename, char *buffer, size_t size)
readlink함수는 심볼릭 링크 filename의 값을 얻는다. 링크가 가리키는 파일 이름이 버퍼에 카피된 다. 이 파일 이름 문자열은 널 종료문자로 끝나지 않는다; readlink는 보통 카피된 문자들의 개수를 리턴한다. size인수는 카피할 문자들의 최대수를 저정하고, 보통 버퍼의 할당 크기가 된다.
만일 리턴값이 size와 같다면, 당신은 그 버퍼에 완전한 이름이 리턴된 것인지, 아닌지를 알 수가 없다. 그러므로 다시 버퍼를 크게하고, readlink를 다시 호출하라. 이곳에 그 예가 있다.
char *readlink_malloc (char *filename)
{
int size = 100;
while (1)
{
char *buffer = (char *) xmalloc (size);
int nchars = readlink (filename, buffer, size);
if (nchars < size)
return buffer;
free (buffer);
size *= 2;
}
}
-1의 값이 리턴되었다면 에러가 발생한 것이다. 보통 파일이름 문법에러에 대하여( 6.2.3절 [File Name Errors] 60페이지 참조) 다음의 errno는 이 함수에서 정의한 에러상황이다.
EINVAL
주어진 filename이 심볼릭 링크가 아니다.
EIO
디스크상에서 읽거나, 쓰고 있는 동안 하드웨어 에러가 발생했다.
9.5 파일 지우기
당신은 unlink 나 remove 의 함수로 파일을 지울 수 있다. ( 이들 이름들은 동의어이다.)
삭제(Deletion)는 실제로 파일이름을 지운다. 만일 그 이름이 파일의 유일한 이름이라면, 그 파일은 삭제된다. 하지만 만일 그 파일이 다른 이름으로 존재하고 있다면( 9.3절 [Hard Links], 127 페이지 참조), 그것은 다른 이름 아래서 억세스 가능한 상태로 남는다.
함수 : int unlink (const char *filename)
unlink함수는 파일이름 filename을 지운다. 만일 이 파일이름이 그 파일의 유일한 이름이라면, 그 파일 자체가 삭제된다. (실제로는, 만일 어느 프로세스가 이처럼 unlink될 때 그 파일을 개방된 파일 로 갖고 있다면, 모든 프로세스들이 그 파일을 닫을때까지 삭제는 연기된다.)unlink함수는 헤더파일 'unistd.h'에 선언되어 있다. 이 함수는 성공하면 0을 리턴하고 에러이면 -1을 리턴한다. 보통의 파 일이름 문법에러에 더하여서( 6.2.3절 [File Name errors] 60 페이지 참조) 다음의 errno는 이 함수를 위하여 정의된 에러 상황이다.
EACCESS
파일을 제거하기 위한 쓰기 요청이 디렉토리 에서 거부되었다.
EBUSY
이 에러는 그 파일이 제거되어질 수 없는, 시스템에서 사용하고 있는 파일임을 나타낸다. 당신이 어 디서건 이 에러를 보았다면 그것은 당신이 지정한 파일이름이 루트 디렉토리 이거나 파일 시스템에 서 마운트하고 있다는 것이다.
ENOENT
제거하려는 파일이름이 존재하지 않는다.
EPERM
어떤 시스템에서는, unlink는 디렉토리 제거에 사용할 수 없거나, 오직 특권이 부여된 사용자만이 이 방법을 사용할수 있거나 한다. 이와 같은 문제들을 피하기 위해서, 디렉토리를 지우려면 rmdir을 사용하라.
EROFS
지우려는 파일 이름의 디렉토리가 읽기 모드 파일 시스템상에 존재하고 있기 때문에 갱신되어 질 수 없다.
함수 : int remove (const char *filename)
remove 함수는 unlink의 다른 이름으로 ANSI C 이다. unlink는 POSIX.1 이름이다. remove는 'stdio.h'에 선언되어 있다.
함수 : int rmdir (const char *filename)
rmdir은 디렉토리를 지운다. 디렉토리를 제거하기 전에는 디렉토리는 반드시 비어있어야 한다; 즉, 그 디렉토리는 `.' 와 `..' 의 엔트리만 갖고 있어야 한다.
rmdir 은 unlink처럼 동작한다. 다음의 두 개의 부가적 errno는 rmdir을 위해서 정의된 에러상황이 다.
EEXIST
ENOTEMPTY
지우려는 디렉토리가 비어있지 않다.
이들 두 개의 에러는 동일하다; 어떤 시스템에서는 어떤 하나를 사용하고, 다른 시스템에서는 다른 하나를 사용한다. 이 함수를 위한 프로토타입은 헤더파일 'uinstd.h'에 선언되어 있다.
9.6 파일 재명명하기.
rename함수는 파일의 이름을 변경하는데 사용한다.
함수 : int rename (const char *oldname, const char *newname)
rename함수는 파일 이름 oldname을 newname으로 재명명한다. oldname 이름하에서의 파일 검색 형식은 나중에 newname으로 재명명되더라도, 역시 변함이 없다. (만일 그 파일이 oldname외에 다른 이름들은 갖었다면, 그것들의 이름에도 변함이 없다. ) newname 이름의 파일을 갖고 있는 디렉토리 는 그 파일( oldname 이름의 파일 )과 같은 파일 시스템안에 있어야만 한다.
재명명의 특별한 경우는 동일한 파일에 oldname과 newname 두 개의 이름이 존재할 때 이다. 이 경우에 대응하기 위한 일관된 방법은 oldname을 제거하는 것이다. 그렇지만, POSIX는 이 경우에 rename은 아무일도 하지않고, 일치하는 파일이 없었을 때, 성공하게 된다. 우리는 당신의 운영체제 가 무엇을 할것인지 알지 못한다. GNU시스템은 당신이 POSIX 시스템과 호환성을 가지도록, 명백 하게 요청하지 않더라도, 옳은일( oldname의 제거 )을 할 것이다.
만일 oldname이 디렉토리가 아니라면, 이미 존재하고 있던 newname의 이름을 가진 파일은 재명명 의 동작이 수행될 때 지워진다. 그렇지만, 만일 newname이 디렉토리라면, rename은 이 경우 실패 로 끝난다. 만일 oldname이 디렉토리일 때, newname의 이름을 가진 어떤것도 존재해서는 안되고, 또는 그것이 비어있는 디렉토리 이름이거나 해야한다. 후자의 경우에, newname의 이름을 가진 디렉 토리를 우선 지우고 재명명을 하는 것이다. newname은 재명명을 시도할 디렉토리로 oldname의
서브디렉토리를 지정하지 않아야만 한다.
rename은 기존에 oldname이란 이름을 갖고 있는 파일을 newname이라는 새로운 이름으로 자동적 으로 변경할 때 쓰여진다. old를 new로 변경할 동안 "그 사이에" newname의 이름을 가진 것이 존 재하지 않는다면 더 이상 신경쓸것이 아무것도 없다.
만일 rename이 실패하면, -1을 리턴한다. 파일 이름 문법 에러에 ( 6.2.3절 [File Name Errors], 60 페이지 참조) 더하여, 다음 errno는 이 함수에서 정의된 에러 상황이다.
EACCES
newname이나 oldname을 갖고 있는 디렉토리들 중의 하나가 쓰기 요청을 거부했다; 또는
newname과 oldname은 디렉토리인데 쓰기 요청이 그들중에 하나에서 거부되어졌다.
EBUSY
oldname이나 newname이름을 가진 디렉토리가 시스템이 작업하는 동안 재명명을 거부하는 방법
으로 현재 그 디렉토리를 시스템에서 사용하고 있다. 디렉토리가 파일 시스템으로 마운트(mount)
된 것이고, 디렉토리가 프로세스들의 현재 작업 디렉토리이다.
EEXIST
newname 디렉토리가 비어있지 않다.
ENOTEMPTY
newname 디렉토리가 비어있지 않다.
EINVAL
oldname 디렉토리가 newname을 포함하는 디렉토리이다.
역자주 : newname이 oldname의 서브디렉토리.
EISDIR
newname은 디렉토리 이름인데, oldname은 디렉토리 이름이 아니다.
EMLINK
newname의 부모 디렉토리가 너무 많은 링크들을 가지고 있다. 잘 만들어진 파일 시스템들은 결 코 이 에러를 발생시키지 않는다, 왜냐하면 그들은 당신의 디스크가 허용하는 한 많은 링크를 허용 하기 때문이다. 하지만 당신은 다른 기계상의 파일 시스템을 네트웍으로 억세스 할수 있으므로, 이 에러에 대한 가능성에 대해서 항상 대비해야만 한다.
ENOENT
oldname 이란 이름을 가진 파일이 존재하지 않는다.
ENOSPC
newname을 포함할 디렉토리가 더 이상의 엔트리를 받아들일 수 없고, 그곳에는 파일 시스템안에 확장할 공감이 남아있지 않다.
EROFS
오직 읽기 모드인 파일 시스템상의 디렉토리에 쓰기를 시도하고 있다.
EXDEV
oldname과 newname이라는 두 개의 파일 이름이 서로 다른 파일 시스템에 존재하고 있다.
9.7 디렉토리 만들기
디렉토리는 mkdir 함수로 만들어진다. ( 같은 일을 하는 mkdir 이라는 쉘 명령어도 있다. )
함수 : int mkdir (const char *filename, mode_t mode)
mkdir 함수는 filename의 이름을 가진 새로운, 빈 디렉토리를 만든다. mode 인수는 새로운 디렉토 리에 대한 접근 권한을 정한다. 9.8.5절 [Permission Bits] 136 페이지를 참조로 해서 접근 권한에 대 한 자세한 정보를 얻어라.
수행이 성공적으로 끝나면 0의 값을 리턴하고, 그렇지 않을 경우에는 -1을 리턴한다. 보통의 파일 이름 문법 에러들에 더하여( 6.2.3 [File Name Errors], 60페이지 참조 ), 다음의 errno는 이 함수를 위해 정의된 에러 상황들이다.
EACCES
새로운 디렉토리를 더하게될 부모 디렉토리에서 파일 쓰기 허용이 거부되었다.
EEXIST
filename의 이름을 가진 파일이 이미 존재한다.
EMLINK
부모 디렉토리가 너무 많은 링크들은 가지고 있다. 잘 만들어진 파일 시스템에서는 이러한 에러를 결코 발생시키지 않는다, 왜냐하면, 그들은 당신의 디스크가 저장할 수 있는 만큼의 링크를 허용하기 때문이다. 하지만 당신은 다른 기계상에 존재하는 파일 시스템을 네트웍을 통해서 억세스할 수 있 으므로 이러한 에러가 발생될 가능성에 대해서 항상 대비해야 한다.
ENOSPC
파일 시스템이 새로운 디렉토리를 만들만한 충분한 공간을 가지고 있지 않다.
EROFS
디렉토리의 부모 디렉토리가 오직 읽기 모드 파일 시스템상에 존재하고 있고, 그래서 갱신할 수 없 다.
이 함수를 사용하려면, 당신의 프로그램에 헤더파일 'sys/stat.h'를 포함 해야 한다.
9.8 파일 속성들.
한 파일에 쉘 명령어 'ls -l'을 사용하면, 당신은 파일의 크기, 파일의 소유자, 마지막 갱신된 때, 등 등에 대한 정보를 얻을 수 있다. 이러한 정보들의 종류를 파일 속성이라고 부른다; 이것은 파일 그 자체와 연관되어 있고, 그 이름들의 하나가 특별한 것은 아니다.
이절에서는 당신이 어떻게 파일들의 속성들에 대한 정보를 얻고, 그들을 갱신할 수 있는지를 설명 하고 있다.
9.8.1 파일 속성들의 값이 무엇을 의미하는가.
당신이 파일 속성을 읽을 때, 그들은 struct stat라고 불리는 구조체로 보내져온다. 이 절은 그 속 성들의 이름과, 그들의 데이터 타입들과, 그들이 무엇을 의미하고 있는지에 대해 설명하고 이다. 파 일의 속성을 읽기 위한 함수는, 9.8.2절 [Reading Attributes] 133페이지를 참조하라.
이절에서 정의된 모든 심볼들은 헤더파일 'sys/stat.h'에 있다.
데이터타입 : struct stat
stat 구조체형은 파일의 속성들에 대한 정보를 리턴하기 위해 사용되어진다. 그들은 적어도 다음과 같은 멤버들을 포함하고 있다.
mode_t st_mode
파일의 모드를 정한다. 이것은 파일 타입 정보와( 9.8.3 [Testing File Type], 134 페이지 참조) 파 일 접근 권한 비트를(file permission) 포함하고 있다.( 9.8.5절 [Permission Bits] 136 페이지 참조)
ino_t st_ino
파일 일련 번호( file serial number),로서 같은 디바이스 상에서 모든 다른 파일들과 이 파일을 구 분한다.
dev_t st_dev
파일을 포함하고 있는 디바이스를 기술한다. st_ino와 st_dev, 이둘을 가지고, 파일을 유일하게 식별 한다.
nlink_t st_nlink
파일에 관련된 하드 링크의 개수이다. 이 파일을 엔트리로 가지고 있는 얼마나 많은 디렉토리들이 있는지 추적해서 그 값을 유지한다. 만일 개수가 0 으로 감소하면, 그 파일 자체가 없어진 것이다. 심볼릭 링크들은 총 개수에 포함되지 않는다.
uid_t st_uid
파일 소유자의 유저 ID 이다. 9.8.4 절 [File Owner] 135 페이지 참조.
gid_t st_gid
파일의 그룹 ID이다. 9.8.4절 [File Owner] 135 페이지 참조.
off_t st_size
이것은 바이트의 수로 일반적 파일의 크기를 지정한다. 만일 파일들이 디바이스거나, 그와 같은 파 일로 존재한다면, 이 필드는 보통 아무런 의미가 없다.
time_t st_atime
이것은 파일의 최종 억세스 시간이다. 9.8.9절 [File Times] 140 페이지 참조.
unsigned long int st_atime_usec
이것은 파일의 최종 억세스 시간의 부수적인 부분이다. 9.8.9절 [File Times] 140 페이지참조.
time_t st_mtime
이것은 파일의 내용이 마지막으로 갱신된 시간 을 만한다. 9.8.9절 [File Times] 140페이지 참조.
unsigned long int st_mtime_usec
이것은 파일이 마지막으로 갱신된 시간의 부수적인 부분이다. 9.8.9절 [File Times] 140페이지 참 조.
time_t st_ctime
이것은 파일의 속성 자체가 마지막으로 갱신된 시간을 말한다. 9.8.9절 [File Times] 140 페이지 참조.
unsigned long int st_ctime_usec
이것은 파일 속성이 마지막으로 갱신된 시간의 부수적인 부분이다. 9.8.9절 [File Times] 140페이 지 참조.
unsigned int st_nblocks
이것은 512-바이트 블록의 단위로 계산된, 파일의 점유하고 있는 디스크 공간의 양을 말한다. 디스 크 블록들의 개수는 파일이 크기와 완전히 비례하지 않는다. 두가지 이유로...; 파일 시스템이 내부 적 레코드를 가지고 있기 위해서 어떤 블록들을 사용할 것이고; 그리고 파일들은 0(zeros)과 같은 " 구멍들"을 가지고 있을 것이기 때문이다.
한 파일에서 st_size와 이 값을 비교하면 (대략) 한 파일의 내용이 드문드문한지 아닌지 알 수 있 다. 이처럼:
(st.st_blocks * 512 < st.st_size)
이결과는 모든 여기저기 흩어져 있는 것들이 검출이 되지 않을수 도 있기 때문에, 완전한 결과는 아 니다. 실용적인 어플리케이션에서, 이것은 문제가 아니다.
unsigned int st_blksize
쓰여진 파일을 읽기 위한 최적의 블록 크기를 말한다. 당신은 쓰여진 파일을 읽기 위한 버퍼 공 간을 할당하기 위해서 이 크기를 사용할 것이다.
어떤 파일 속성들은 그들을 위해 특별히 존재하는 특별한 데이터 타입의 이름들을 가지고 있다. ( 그들은 당신이 익히 알고 있는 것들을 정수형으로 이름을 붙여놓은 것이다. ) 이들 typedef 시킨 이름들은 'sys/types.h'와 'sys/stat.h'에 정의되어 있다. 여기에 그들에 대한 설명이 있다.
데이터타입 : mode__t
데이터타입 : mode__t
이것은 현재의 파일 모드들을 나타내기 위해 사용되는 정수형 데이터 타입니다. GNU 시스템에 서, 이것은 unsigned int 와 동일하다.
데이터타입 : ino__t
이것은 파일의 일련 번호들을 나타내기 위해 사용하는 산술적 데이터 타입이다. (jargon 유닉스에 서는, 이들을 때때로 inode 번호라고 불리워 진다. ) GNU 시스템에서는, 이 타입은 unsigned long int와 동일하다.
데이터타입 : dev__t
이것은 파일 디바이스 번호를 나타내기 위해 사용하는 산술적 데이터 타입니다. GNU 시스템에서 는, 이것은 int 와 동일하다.
데이터타입 : nlink__t
이것은 파일 링크의 개수를 나타내기 위해 사용되는 산술적 데이터 타입입니다. GNU 시스템에서, 이것은 unsigned short int 와 동일하다.
9.8.2 파일 속성들 읽기.
파일의 속성들을 조사하기 위해서는, stat, fstat 와 lstat 함수를 사용하라. 그들은 struct stat object에 속성정보를 리턴한다. 세 개 함수 모두는 헤더파일 'sys/stat.h'에 선언되어 있다.
함수 : int stat (const char *filename, struct stat *buf)
stat 함수는 buf가 가리키는 구조체안에 filename의 이름을 가진 파일의 속성에 대한 정보를 리턴한 다. 만일 filename이 심볼릭 링크의 이름이라면, 당신이 얻게될 속성 정보는 링크가 가리키고 있는 파일에 대한 정보이다. 만일 링크가 가리키고 있는 파일이 존재하지 않는 파일이라면, stat는 실패하 게 되고, 존재하지 않는 파일이라고 보고한다.
만일 오퍼레이션이 성공하면 0을 리턴하고, 실패하면 -1을 리턴한다. 파일 문법 에러들에 더하여 (6.2.3절 [File Name Errors] 60 페이지 참조), 다음의 errno는 이 함수를 위해 정의된 에러 상황이 다.
ENOENT
filename의 이름을 가진 파일이 존재하지 않음.
함수 : int fstat (int filedes, struct stat *buf )
fstat 함수는 파일 이름을 인수로 받아들이는 것 대신에 개방된 파일 기술자를 인수로 받아들이는 점을 제외하고는 stat와 같다. 8장 [Low_Level I/O], 103 페이지 참조.
stat처럼, fstat도 성공하면 0을 리턴하고, 실패하면 -1을 리턴한다. 다음의 errno는 함수 fstat를 위 해 정의된 에러상황이다.
EBADF
filedes 인수가 유용한 파일 기술자가 아니다.
함수 : int lstat (const char *filename, struct stat *buf )
lstat 함수는 심볼릭 링크를 따르지 않는다는 점을 제외하고는 stat와 같다. 만일 filename이 심볼 릭 링크의 이름이라면, lstat는 링크 그 자체에 대한 정보를 리턴한다; 그렇지 않다면 lstat는 stat처 럼 동작한다. 9.4절 [Symbolic Links] 127 페이지 참조.
9.8.3 파일의 형식 알아보기
파일 속성의 st_mode 필드안에 저장된 파일 모드는 두가지 정보를 담고 있다: 하나는 파일 타입 코드이고, 다른 하나는 접근 허가 비트들이다. 이 절은 그 파일이 디렉토리인지, 아니면 소켓인지, 등 등을 알수 있는 파일 타입 코드에 대한 것을 설명할 것이다. 파일 접근 권한에 대한 정보는, 9.8.5 절 [Permission Bits] 136 페이지 참조.
파일 모드에서 파일 타입 부분을 검색할 수 있는 미리 정의된 두가지 방법이 있다. 그중 한가지는, 파일 모드 값을 시험하는 매크로를 사용해서 파일이 그 타입인지, 아닌지를 참과 거짓으로 리턴하는 방법이 있다. 둘째로, 파일 모드에서 다른 값들을 제외하고( mask out을 시켜서 ) 오직 파일 타입 코드만을 얻어내는 방법이다. 당신은 이 값을 여러 가지 다양한 상수들과 비교할 수 있다.
이 절에서 설명된 모든 심볼들은 헤더파일 'sys/stat.h'에 정의되어 있다.
다음은 파일 타입을 테스트 하기위한 매크로로써, 주어진 m은 stat 함수에 의해 리턴된 st_mode 필드이다.
int S__ISDIR (mode_t m) Macro
이 매크로는 만일 그 파일이 디렉토리라면 0이 아닌값을 리턴한다.
int S__ISCHR (mode_t m) Macro
이 매크로는 만일 그 파일이 문자 특수화일( 터미널과 같은 디바이스 )이면 0이 아닌값을 리턴한 다.
int S__ISBLK (mode_t m) Macro
이 매크로는 만일 그 파일이 블록 특수 파일 ( 디스크와 같은 디바이스 )이면 0이 아닌값을 리턴한 다.
int S__ISREG (mode_t m) Macro
이 매크로는 만일 그 파일이 보통의 파일이라면 0이 아닌값을 리턴한다.
int S__ISFIFO (mode_t m) Macro
이 매크로는 만일 그 파일이 FIFO 특수 파일이나, pipe라면 0이 아닌 값을 리턴한다. 10장 [Pipes and FIFOs] , 145 페이지 참조.
int S__ISLNK (mode_t m) Macro
이 매크로는 만일 파일이 심볼릭 링크라면 0이 아닌값을 리턴한다. 9.4절 [Symbolic Links] 127 페 이지 참조.
int S__ISSOCK (mode_t m) Macro
이 매크로는 만일 그 파일이 소켓이라면 0이 아닌값을 리턴한다. 11장 [Sockets] 149 페이지 참조.
파일 타입을 테스트하는 비-POSIX의 방법은 BSD와의 호환성을 위해서 지원된다. 그 모드는 파일 타입 코드를 추출하기 위해 S_IFMT와 비트단위 AND연산을 시키고, 적당한 타입 코드 상수와 비교 한다.
예를 들어,
S_ISCHR (mode) 는 다음과 동등하다:
((mode & S_IFMT) == S-IFCHR)
int S__IFMT Macro
이것은 mode 값에서 파일 타입 코드의 부분을 추출하기 위해서 사용되는 비트 마스크이다. 이들 은 다른 파일 타입 코드들을 위해서 심볼화된 이름을 가지고 있다.
S_IFDIR
이 매크로는 디렉토리 파일을 위한 파일 타입 코드의 값을 나타낸다.
S_IFCHR
이 매크로는 문자-지향(character-oriented) 디바이스 파일을 위한 파일 타입 코드의 값을 나타낸다.
S_IFBLK
이 매크로는 블록-지향(block-oriented) 디바이스 파일을 위한 파일 타입 코드의 값을 나타낸다.
S_IFREG
이 매크로는 보통의 파일을 위한 파일 타입 코드의 값을 나타낸다.
S_IFLNK
이 매크로는 심볼릭 링크를 위한 파일 타입 코드의 값을 나타낸다.
S_IFSOCK
이 매크로는 소켓을 위한 파일 타입 코드의 값을 나타낸다.
S_IFIFO
이 매크로는 FIFO 나 pipe를 위한 파일 타입 코드의 값을 나타낸다.
9.8.4 파일 소유자.
모든 파일은 시스템상에 등록된 사용자 이름들중 하나인 소유자를 갖고 있다. 각 파일은 또한 정 의된 그룹들중 하나인 그룹을 갖고 있다. 파일 소유자는 누가 그 파일을 편집했는지( 특별히 당신이 GNU Emacs로 편집을 할 때 ) 알기위해서도 필요하지만, 그것의 주된 목적은 접근 권한을 제어하기 위함이다.
파일 소유자와 그룹은, 그 파일이, 파일 소유자인 사용자를 위한 접근 권한 설정, 그리고 파일의 그 룹에 속한 사용자들에 적용시키기 위한 다른 설정, 그리고 모든 다른 사람들에게 적용하기 위한 세 번째 비트 설정을 가지고 있기 때문에, 접근을 결정하는 규칙에 따른다. 9.8.6절 [Access Permission] 137 페이지를 참조하면, 이 데이터를 기초로 해서 어떻게 접근을 결정하는지에 대한 상세한 정보를 얻을 수 있다.
파일이 만들어질 때, 그 파일의 소유자는 그 파일을 만든 프로세스의 사용자 ID를 통해 설정된다( 25.2절 [Process personal], 353 페이지 참조). 파일의 그룹 ID는 그 프로세스의 그룹 ID로 설정되거 나, 아니면 그 파일이 포함된 디렉토리의 그룹 ID로 설정되거나 하는데, 그것은 그 파일이 저장된 시스템에 따라 다르다. 당신이 원격 파일 시스템을 억세스할 때, 당신의 프로그램이 구동되고 있는 시스템에 따르는 것이 아니라 그파일 자신이 속한 시스템의 규칙에 따라 행동한다. 그래서 당신의 프로그램은, 당신이 어떤 시스템에서 그 프로그램을 구동시키는지에 상관없이, 당신이 부딪칠지도 모 르는 모든 동작에 종류에 대해 미리 대비해야만 한다.
당신은 chown 함수를 사용해서 현존하는 파일의 사용자 와/또는 그룹 사용자를 변경할 수 있다. 이것은 chown과 chgrp 쉘 명령어에 기본적으로 포함되어 있다.
이 함수를 위한 프로토타입은 'unistd.h'에 선언되어 있다.
함수 : int chown (const char *filename, uid_t owner, gid_t group)
chown함수는 owner로 filename의 이름을 가진 파일의 소유자를 변경하고, group으로 그룹 소유자 를 변경한다. 어떤 시스템상에서 파일 소유자의 변경은 파일 접근 권한 비트들에서 set-user-ID 와 set-group-ID 비트를 클리어한다(이것은 이 비트들이 새로운 소유자에게 적당하지 않을지도 모르기 때문이다. ). 다른 파일 접근 권한 비트들은 변경되지 않는다.
성공하면 리턴값은 0이고, 실패하면 -1이다. 보통의 파일 문법 에러에 더하여( 6.2.3절 [File Name Errors] 60 페이지 참조), 다음의 errno는 이 함수를 위해 정의된 에러 상황이다.
EPERM
이 프로세스는 요청된 변경을 수행하기에는 접근권한이 부족하다.
오직 특권이 부여된 사용자나, 파일의 소유자만이 그 파일의 그룹을 변경할 수 있다. 대부분의 파 일 시스템들은, 오직 특권이 부여된 사용자만이 그 파일의 소유자를 변경할 수 있다; 어떤 파일 시 스템들은 만일 당신이 현재 그파일의 소유자라면, 그 소유자를 변경할수 있도록 허용한다. 당신이 원격 파일 시스템을 억세스 할 때, 당신의 프로그램이 구동되고 있는 시스템에 의해서가 아니라, 그 파일을 실제로 갖고 있는 시스템에 의해서 동작이 결정되어 진다.
27.7절 [Options for Files] 375 페이지를 참조로-POSIX_CHOWN_RESTRICTED 매크로에대한 정보 를 얻어라.
EROFS
파일이 오직 읽기 모드 파일 시스템에 존재한다.
함수 : int fchown (int filedes, int owner, int group)
이것은 개방된 파일 기술자 filedes의 파일 소유자를 변경한다는 점을 제외하고는 chown 함수와 같 다. 성공하면 0을 리턴하고 실패하면 -1을 리턴한다. 다음의 errno는 이 함수를 위해 정의된 에러 코드들이다.
EBADF
filedes 인수가 유용한 파일 기술자가 아니다.
EINVAL
filedes 인수가 보통의 파일이 아닌, pipe 나 소켓에 해당한다.
EPERM
이 프로세스는 요청된 변경을 수행하기 위한 파일 접근 허가가 부족하다. 좀더 상세한 것은 위의 chmod를 참조하라.
EROFS
파일이 오직 읽기 모드 파일 시스템상에 존재하고 있다.
9.8.5 파일 접근 허가 비트들.
파일 속성의 st_mode 필드에 저장되어 있는 파일 모드는 두가지의 정보를 포함하고 있다: 파일 타입 코드와 파일 접근 허가 비트들. 이절에서는 오직, 파일을 누가 읽거나 쓸 수 있는가를 제어하 는, 파일 접근 허가 비트에 대해서 다룰것이다.
이절에서 설명하고 있는 심볼들은 헤더파일 'sys/stat.h'에 정의되어 있다.
이들 심볼들은 파일 접근 하가를 제어하는 파일 모드 비트들을 위해 정의되어졌다.
S_IRUSR
S_IREAD
파일의 소유자를 위한 읽기 허가 비트. 많은 시스템들에서, 이 비트는 0400이다. S_IREAD는 BSD 와의 호환성을 위해 제공되고 있는 잘 안쓰이는 동의어이다.
S_IWUSR
S_IWRITE
파일의 소유자를 위한 쓰기 허가 비트. 보통 0200.
S_IWRITE는 BSD와의 호환성을 위해 제공되고 있는 잘 안쓰이는 동의어이다.
S_IXUSR
S_IEXEC
파일의 소유자를 위한 실행( 보통의 파일 ) 이나 검색( 디렉토리을 위한 ) 허가 비트이다. 보통 0100.
S_IEXEC는 BSD와의 호환성을 위해 제공되고 있는 잘 안쓰이는 동의어이다.
S_IRWXU
이것은 '(S_IRUSR | S_IWUSR | S_IXUSR)'과 같다.
S_IRGRP
파일의 그룹 소유자를 위한 읽기 허가 비트. 보통 040
S_IWGRP
파일의 그룹 소유자를 위한 쓰기 허가 비트. 보통 020.
S_IXGRP
파일의 그룹 소유자를 위한 실행이나 검색 허가 비트. 보통 010.
S_IRWXG
이것은 '(S_IRGRP | S_IWGRP | S_IXGRP)'와 같다.
S_IROTH
다른 사용자를 위한 읽기 허가 비트. 보통 04.
S_IWOTH
다른 사용자를 위한 쓰기 허가 비트. 보통 02.
S_IXOTH
다른 사용자를 위한 실행이나 검색 허가 비트. 보통 01.
S_IRWXO
이것은 '(S_IROTH | S_IWOTH | S_IXOTH)'와 같다.
S_ISUID
이것은 실행 비트에서 set-user-ID로, 보통 04000. 25.4절 [How Change Persona], 354 페이지 참 조. 역자주: set-user-ID ; 수행중의 사용자 식별번호를 지정.
S_ISGID
이것은 실행비트에서 set-group-ID로, 보통 02000이다. 25.4절 [How Change Persona], 354 페이지 참조. 역자주: set-user-ID ; 수행중의 그룹식별번호를 지정.
S_ISVTX
이것은 스티키 비트로 보통 01000이다.
역자주: sticky bit ; 수행중의 텍스트 이미지를 저장.
수행중인 파일에서, 시스템의 스와핑 방법들을 변경한다. 보통은 프로그램이 종료될 때, 기억장치안 의 그 페이지들은 즉시 해제되어 재사용가능해진다. 그러나 만일 수행가능한 파일에서 스티키비트가 설정되면, 그 시스템은 마치 그 프로그램이 여전히 실행되고 있는것처럼 기억장소에 페이지들을 계 속 유지하고 있다. 이것은 완전한 수행에 많은 시간이 소요될 것 같은 프로그램에 유용하다. 디렉토 리에서, 스티키비트는 만일 당신이 어느 파일에 쓰기허가를 가지고 있다면 디렉토리안의 그 파일을 제거 하도록 허용한다. 보통 사용자는 디렉토리안의 모든 파일들을 지울수 있거나, 혹은 그들중 어느 것도 지울 수 없거나한다 ( 그 사용자가 디렉토리에 쓰기 허가를 갖고 있는지, 없는지에 기초한다. ). 스티키비트는 개개의 파일들의 제거 권한을 제어하는 것을 가능하게 만든다.
역자주: 여기서 페이지는 기억장치에 저장된 하나의 단위라고 볼 수 있겠네요.
심볼들의 실행 비트 값들은 위의 테이블에 있다. 당신은 당신의 프로그램을 디버깅할 때 파일 모 드 값들은 해석할 수 있다. 이들 비트값들은 대부분의 시스템에 정확하게 동작하지만, 그것을 완전 히 보장할 수는없다.
주의: 파일 접근 권한을 숫자로 명시하는 것은 좋지않은 습관이다.
이것은 이식성이 없고, 또한 누군가 당신의 프로그램을 읽을 때, 그 비트가 무엇을 의미하는지 알수 없기 때문이다. 프로그램을 기호(symbolic)이름들을 사용하여, 깨끗하게 만들어라.
9.8.6 어떻게 파일에 당신의 접근을 결정하는가.
운영체제는 보통 유효 사용자와 프로세스의 그룹 ID들과, 그것을 보충하여 그룹 ID들과 파일의 소 유자, 그룹 그리고 허가비트들을 기초로 하여파일에 대한 접근 하가를 결정한다. 이 원칙들은 25.2 절 [Process Persona] 353 페이지에 자세히 나와있다.
역자주: 유효사용자ID: 실제 생성된 파일에 대한 소유권을 갖는 사용자 실제사용자ID: 프로세스를 수행시킨 사용자의 식별번호
만일 프로세스의 유효 사용자 ID가 파일의 소유 사용자 ID와 대응됐을 때, 읽기, 쓰기와 실행/검색 허가는 해당되는 "사용자" (또는 "소유자") 비트에 의해 제어된다. 그와같이, 만일 유효 그룹 ID 나 프로세스의 그룹 ID가 파일의 그룹 소유자 ID와 대응됐을때, 파일 접근 허가는 "그룹" 비트들에 의 해 제어된다. 그렇지 않다면, 파일 접근 허가는 "다른사용자" 비트들에 의해 제어된다.
'루트'처럼 특권이 부여된 사용자는 파일 접근 허가에 관계없이 어느 파일이라도 억세스 할 수 있 다. 특별한 경우로, 특권이 부여된 사용자를 위한 실행가능 파일을 위해서, 적어도 하나의 실행 비 트들을 설정해야만 한다.
9.8.7 파일 접근 허가 정하기.
파일을 만드는 원래의 함수들( 예를 들어, open이나 mkdir)은 새로이 만들어질 파일의 접근 허가를 정하기 위해서 mode인수를 취한다. 그러나 정해진 모드는 그것이 사용되기 전에, 프로세스의 파일생 성마스크나 umask에 의해 갱신되어진다.
파일 생성 마스크에 설정되어진 비트들은 새로이 개방된 파일에 대한 ,그 설정에 해당하는 권한이 없다는 것을 의미한다. 예를 들어, 만일 당신이 "다른 사용자" 접근 권한 비트들을 모두 마스크에 설정하면, 새로이 생성된 파일에, "다른 사용자" 범주에 들어가는 모든 프로세스들의 접근이 불가된 다, 심지어 개방된 파일에 주어진 mode 인수가 접근가능이었다고 하더라도. 즉, 파일 생성 마스크는 당신이 원하는 만큼 파일 접근 허가를 부여하기가 용이하다.
프로그램들은 특별한 파일에 적정한 모든 허가를 포함하고 있는 mode 인수를 지정해서 파일을 개 방한다. 보통의 파일은, 모든 부류의 사용자들에게 읽기와 쓰기허가가 있다. 이들 허가들을 개별적 으로 사용자 자신의 파일 생성 마스크를 통해서 제한하는 것이다.
이름이 있는 현존하는 파일의 허가를 변경하기 위해서는, chmod를 호출하라. 이 함수는 파일 생성 마스크를 무시한다; 그것은 정확히 정해진 허가 비트들을 사용한다. 보통, 파일 생성 마스크는 사 용자의 로그인 쉘에서 초기화되있고 (umask 쉘 명령어를 사용해서 ) , 그리고 모든 부프로세스들이 물려받는다. 응용 프로그램들은 보통 파일 생성 마스크에 대해서 걱정할 필요가 없다. 그것은 미리 가정된 것을 할 것이다. 당신이 파일을 개방하고, 파일 접근 허가를 위해서 umask를 사용할 때, umask를 사용하는 것 보다는, 파일을 개방한 후에 fchmod를 사용하여 그 일을 하는 것이 가장 쉬 운 방법이다.
실제로, umask를 통한 변경은 오직 쉘에 의해서 행해진다. 그들은 umask함수를 사용한다.
이절의 함수들은 헤더파일 "sys/stat.h'에 선언되어 있다.
함수 : mode_t umask (mode_t mask)
umask 함수는 mask로 현재 프로세스의 파일 생성 마스크를 설정하고, 파일 생성 마스크의 전의 값을 리턴한다. 이곳에서는 그 값들을 변경하지 않고, umask를 사용해서 마스크를 어떻게 읽는지를 보여주고 있다.
mode_t
read_umask (void)
{
mask = umask (0);
umask (mask);
}
그렇지만, 만일 당신이 마스크값을 단지 읽기를 원한다면 getumask를 사용하는 편이 낫다, 왜냐하 면 재진입 때문이다. (적어도 만일 당신이 GNU 운영체제를 사용하고 있다면 )
함수 : mode_t getumask (void)
현재의 프로세스를 위한 파일 생성 마스크의 현재의 값을 리턴한다. 이 함수는 GNU확장이다.
함수 : int chmod (const char *filename, mode_t mode)
chmod 함수는 mode로 filename의 이름을 가진 파일을 위한 접근 허가비트를 설정한다. 만일 그 filename의 파일이 심볼릭 링크라면, chmod는 링크 그 자체가 아니라, 링크가 가리키고 있는 파일의 접근 허가를 변경한다. 링크의 모드를 설정할 수 있는 방법은 아무것도 없다. 성공하면 0을, 실패하 면 -1을 리턴한다. 보통의 파일 이름 문법 에러에 더하여 ( 6.2.3절 [File Name Errors] 60 페이지 참조), 다음의 errno는 이 함수에서 정의된 에러 상황이다.
ENOENT
그 이름을 가진 파일이 존재하지 않는다.
EPERM
이 프로세스가 이 파일의 접근 허가를 변경할 만큼의 권한을 가지고 있지 않다. 오직 파일의 소 유자( 프로세스의 유효 사용자 ID로 판단된)나 특권이 부여된 사용자만 그들을 변경할 수 있다.
EROFS
파일이 오직 읽기 모드의 파일 시스템에 존재한다.
함수 : int fchmod (int filedes, int mode)
이것은 기술자 filedes를 거쳐서 현재 개방된 파일의 접근 허가를 변경한다는점을 제외하고는 chmod와 같다. fchmod로부터의 리턴값은 성공하면 0이고, 실패하면 -1이다. 다음의 errno는 이 함 수를 위해 정의한상황이다.
EBADF
filedes 인수가 유용한 파일 기술자가 아니다.
EINVAL
filedes 인수가 파이프나 소켓이거나, 아니면 그것이 실제로 접근 허가를 가지지 않는 어떤것에 해 당한다.
EPERM
이 프로세스가 파일의 접근 허가를 변경하기위한 허가를 가지고 있지 않다. 오직 파일의 소유자( 프로세스의 유효 사용자 ID로 판단된)나, 특권이 부여된 사용자만이 그들을 변경할 수있다.
EROFS
파일이 오직 읽기 모드 파일 시스템안에 존재한다. 9.8.8 파일을 억세스하기 위하여 파일 접근 허 가를 알아보기. 특권이 부여된 사용자로써 프로그램을 실행하고 있을 때, 그 사용자에게 제한없이 파일들을 억세스 하도록 허용한다_예를 들어, '/etc/passwd/'파일을 수정하기와 같은것도. 유효 사 용자 ID로 항상 루트에서 실행되도록 setuid 비트를 사용하는 그런 파일들이 아니라면, 프로그램들 은 보통의 사용자에의해 실행되도록 만들어졌다. 정해진 사용자에 의하여 파일을 억세스하는 프로 그램에서, 파일들이 명백한 사용자에 의해 억세스되어진다. 루트로 실행되는 프로그램에서는 정해진 사용자가 무슨 파일이든지 억세스가 허가되지만, 보통은 보통의 사용자가 검색할 수 있는 그런 파일 들만 허가된다. 프로그램은 그 파일을 읽거나 쓰기전에, 사용자가 파일을 억세스할 필요가 있는지를 명백하게 체크해야만 한다.
이것을 하기 위해서, 유효 사용자 ID 보다는 프로세스의 실 사용자 ID에 의한 접근 허가를 체크하 는 access함수를 사용하라. ( setuid는 그 프로그램을 실제로 실행시킨 사용자를 반영한, 실 사용자 ID를 변경하지 않는다.) 설명하기는 쉽지만, 사용하기는 어려운 엑세스를 체크할 수 있는 다른방법이 있다. 이것은 파일 모드 비트들을 시험하고 시스템의 엑세스조작을 흉내내는 것이다. 이 방법은 많 은 시스템들이 부가적인 억세스 제어를 가지고 있기 때문에 바람직한 방법은 아니다; 당신의 프로 그램이 이식성있게 그들을 흉내낼수도 없고, 다른 시스템들이 가진 다른 종류의엑세스 제어를 알아 내려 시도할 수도 없다. access를 사용하는 것은 간단하고, 당신이 사용하는 시스템이 무엇이든지간 에 그 시스템에 적당한 동작을 자동적으로 한다.
이 절에서 설명된 심볼들은 'uinstd.h'에 선언되어 있다.
함수 : int access (const char *filename, int how )
access 함수는 how인수로 정해진 방법으로 filename의 이름을 가진 파일을 억세스 할수 있는지를 알아보는 함수이다. how 인수는 R_OK, W_OK, X_OK,플래그를 비트단위 OR연산된것이거나 존재 테스트 F_OK 플래그이다. 이 함수는 접근 허가를 체크하기 위해서 유효사용자 ID를 사용하기 보 다는 호출하는 프로세스의 실 사용자와 그룹 ID들을 사용한다. 그 결과로, 만일 당신이 setuid나 setgid 프로그램( 25.4절 [How Change Persona] 354 페이지 참조)으로부터 함수를 사용한다면, 그것 은 그 프로그램을 실제로구동하는 사용자에 대한 정보를 알려준다.
억세스가 허가되면 0을 리턴하고, 그렇지 않으면 -1을 리턴한다.
(즉, 하나의 함수로 취급하여, access는 요청된 접근이 거부되면 참을 리턴한다. ) 보통의 파일 이름 문법 에러에 더하여 ( 6.2.3절 [File Name Errors] 60 페이지 참조), 다음의 errno는 이 함수를 위해 정의된 에러 상황이다.
EACCES
how인수로 정해진 접근이 거부되었다.
ENOENT
파일이 존재하지 않는다.
EROFS
쓰기 허가가 오직 읽기 모드 파일 시스템상에 존재하는 파일에 요청되었다.
이들 매크로들은 access 함수에 how인수로서 사용하기 위한 것으로 헤더파일 'unistd.h'에 정의되 어 있다.
매크로 : int R__OK
읽기 허가를 위한 테스트를 의미하는 인수.
매크로 : int W__OK
쓰기 허가를 위한 테스트를 의미하는 인수
매크로 : int X__OK
실행/검색 허가를 위한 테스트를 의미하는 인수.
매크로 : int F__OK
파일의 존재를 위한 테스트를 의미하는 함수.
9.8.9 파일에 관련된 시간들.
각 파일은 검색 시간, 갱신 시간, 속성 갱신 시간에 해당하는 세가지 타임 스템프들을 가지고 있다. 이것은 stat의 st_atime, st_mtime, st_ctime 멤버에 해당한다; 9.8절 [File Attributes], 131 페이지 참조. 이 시간들 모두는 time_t objects 안에 표현된다. 이 데이터 타입은 'time.h'에 정의되어 있다. 시간 값들의 표현과 다루는 방벙에 대한 자세한 설명은 17.2절 [Calendar Time] 235 페이지에 있다. 현존하는 파일이 개방되있을 때, 그 속성변경시간과 갱신 시간필드들은 갱신된 다. 파일읽기는 검색 시간 속성을 갱신시키고, 파일쓰기도 또한, 갱신시간 속성을 갱신시킨다.
파일이 만들어질 때, 파일을 위한 세가지 타임 스템프는 현재의 시간으로 설정된다. 디렉토리의 속 성 변경 시간과 갱신 시간의 필드들은 새로운 엔트리가 들어오면 갱신된다. link함수로 원래의 파일 에 새로운 이름이 더해지면, 링크되어진 파일의 속성 변경 시간(attribute change time)이 갱신되고, link를 통해 만들어진 새로운 이름을 포함하는 디렉토리의 속성 변경 시간과 갱신 시간 (modifi-cation) 필드들이 갱신된다. 이와 같은 필드들은 unlink, remove, rmdir로 파일 이름이 제거 될 때 영향을 받는다. rename로 파일을 재명명할 때, 파일이 포함된 부모 디렉토리들의 속성 변경 시간과 갱신시간 필드들 이 영향을 받지만, 파일에 관련된 시간속성들은 변경되지 않는다.
파일의 속성들의 변경은( 예를 들어, chmod를 통해서) 그 속성 변경시간 필드를 갱신한다.
당신은 속성 변경 시간을 제외하고, utime 함수를 사용해서 명시적으로 파일의 타임스템프를 변경 할 수 있다. 이것은 헤더파일 'utime.h'에 정의 되어 있다.
데이터 타입 : struct utimbuf
utimbuf 구조체는 어떤 파일에 새로운 검색 시간과 갱신시간을 정해주기 위해서 utime 함수에서 사용된다. 이것은 다음과 같은 멤버들을 포함한다.
time_t actime 이것은 파일의 검색시간이다.
time_t modtime 이것은 파일의 갱신시간이다.
함수 : int utime (const char *filename, const struct utimbuf *times)
이 함수는 filename이름을 가진 파일과 연관된 시간을 변경하기 위해 사용된다. 만일 times가 널 포인터라면, 파일의 검색시간과 갱신시간들은 현재의 시간으로 설정된다. 그렇지않다면, 그들은 times가 가리키는 구조체 utimbuf의 actime와 modtime 멤버들로부터 얻은 값으로 시간을 설정한다.
파일의 속성변경시간은 두가지 경우 모두 현재의 시간으로 설정된다. ( 타임 스템프들이 변경은, 파 일 속성의 변경을 수반한다.)utime 함수는 성공하면 0을 리턴하고, 실패하면 -1을 리턴한다. 보통의
파일 이름 문법 에러에 더하여( 6.2.3절 [File Name Errors] 60 페이지 ]참조), 다음의 errno는 이 함 수를 위해서 정의된 에러 상황들이다.
EACCES
times 인수로 널 포인터를 주었을 때 허가문제가 있다. 파일의 타임 스템프를 갱신하기 위해서는 파일의 소유자이고 파일에 쓰기 허가를 가지고 있거나, 특권이 부여된 사용자이어야 한다.
ENOENT
파일이 존재하지 않는다.
EPERM
만일 times인수가 널 포인터라면, 당신은 파일의 소유자이거나 특권이 부여된 사용자이어야만 한다. 이 에러는 그 문제를 보고하는데 사용된다.
EROFS
파일이 오직 읽기 모드 파일 시스템에 존재한다.
세가지 타임 스템프들은 연관된 마이크로초(microsecond) 부분을 가지고 있다. 이들 필드들은 st_atime_usec, st_mtime_usec, st_ctime_usec라고 불린다; 각각은 마이크로초 단위로 표현된 0에서 999,999사이의 값을 가지고 있다. 그들은 timeval 구조체의 tv_usec에 해당한 다; 17.2.2절[High-Resolution Calendar] 235 페이지 참조. utimes 함수는 utime와 같지만, 파일에 관 련된 시간들을 아주 세밀하게 정하는 것을 허용한다. 이 함수를 위한 프로토타입은 헤더파일 'sys/time.h이다.
함수 : int utimes (const char *filename, struct timeval tvp[2])
이 함수는 filename의 이름을 가진 파일의 검색 시간과 갱신시간을 설정하는 함수이다. 새로운 파 일 검색 시간은 tvp[0]에 의해 정해지고, 새로운 갱신시간은 tvp[1]에 의해 설정된다. 이 함수는 BSD에서 왔다. 리턴값과 error 에러 상황은 utime함수와 같다.
9.9 특수 파일 만들기.
mknod 함수는 디바이스와 같은, 특수한 파일을 만들기 위한 함수다. GNU 라이브러리는 BSD와의 호환성을 위해서 이 함수를 갖고 있다. mknod의 프로토타입은 'sys/stat.h'에 선언되어 있다.
함수 : int mknod (const char *filename, int mode, int dev)
mknod 함수는 filename의 이름을 가진 특수한 파일을 만든다. mode인수는 S_IFCHR(문자 특수 파일을 위해)나, S_IFBLK(블럭 특수 파일을 위해)와 같은 다양한 특수 파일 비트들을 가지고 파일 의 모드를 지정한다.9.8.3절 [Testing Fiel Type] 134 페이지 참조. dev 인수는 디바이스를 정한다. 그것의 정확한 해석은 만들어진 특수 파일의 종류에 의존한다. 리턴값은 성공하면 0이고, 실패하면 -1이다. 보통의 파일 이름 문법 에러에 더하여 ( 6.2.3절 [File Name Errors] 60 페이지 참조), 다음 의 errno는 이 함수를 위해 정의된 에러 상황이다.
EPERM
호출한 프로세스가 특권이 없다. 특수 파일을 만들 수 있는 것은 슈퍼유저뿐이다.
ENOSPC
새로운 파일을 갖고 있는 디렉토리나 파일 시스템이 가득찼고, 더 이상 확장할 수 없다.
EROFS
새로운 파일을 갖고 있는 디렉토리가 오직 읽기 모드 파일 시스템상에 있기 때문에 갱신될 수 없 다.
EEXIST
filename의 이름을 가진 파일이 이미 존재한다. 만일 당신이 이 파일을 대체하기 원한다면, 당신은 먼저 그 원래의 파일을 제거해야만 한다.
9.10 임시 파일들.
만일 당신의 프로그램에서 임시파일의 사용이 필요하다면, 당신은 그것을 개방하기 위해 tmpfile함 수를 사용할 수 있다. 또는 임시파일의 이름을 만들기 위해 tmpnam 함수를 사용하고 fopen을 사 용해서 보통의 방법으로그 임시파일을 개방할 수 있다.
tempnam함수는 tmpnam함수와 같지만, 당신이 그 임시파일이 들어갈 디렉토리가 무엇인지, 그리고 그들의 파일이름이 무엇인지에 대한 것을 정하도록 허용한다.
함수 : FILE * tmpfiel (void)
이 함수는 "wb+" 모드로 fopen을 호출함으로써, 갱신한 모드로 임시 바이너리 파일을 만든다. 그 파일은 그 프로그램이 종료할때나 닫힐 때, 자동적으로 제거된다. ( 어떤 다른 ANSI C 시스템에서 그 프로그램이 비정상적으로 종료되면 파일의 제거도 실패할 것이다.)
함수 : char * tmpnam (char *result)
이 함수는 현재 존재하고 있는 파일 이름이 아닌 유용한 파일이름을 만들어서 리턴한다. 만일 result인수가 널 포인터라면, 리턴값은 다음 호출로 갱신된 내부 정적 스트림의 포인터이다. 그렇지 않다면, result인수는 적어도 L_tmpnam의 배열을 가리키는 포인터이고 result는 그 배열안에 저장된 다. tmpnam의 호출에 너무 많은 시간이 소요되면 실패의 가능성이 있다. 이것은 임시파일을 정해 진 개수의 파일이 있어야 하는곳에서 이미 다른 파일들로 그 개수가 체워진곳에 만들려했기 때문이 다. tmpnam이 실패하면 널 포인터를 리턴한다.
매크로 : int L__tmpnam
이 매크로 값은 tmpnam함수로 만들어진 파일이름을 저장하기에 충분한 문자열의 최소 할당 크기 를 나타내기 위한 정수 상수 표현이다.
매크로 : int TMP__MAX
매크로 TMP_MAX는 당신이 tmpnam으로 만들 수 있는 임시 파일 이름의 최소 경계이다. 당신이 너무 많은 임시 파일 이름을 만들어 실패를 경험하기 전에, 이 매크로 값에 의존할 수 있다.
GNU 라이브러리에서는, 당신은 당신의 디스크의 공간이 허락하는 만큼의 많은 개수의 임시파일을 만들 수 있다. 어떤 다른 시스템에서는 임시파일의 개수를 작게 제한하고 있다. 그 제한은 25보다 는 결코 작지않다.
함수 : char * tempnam (const char *dir, const char *prefix)
이 함수는 단일한 임시 파일이름을 생성한다. 만일 prefix가 널 포인터가 아니고 이 문자열이 5개 문자 이상이면 그 prefix가 파일이름으로 사용된다. 임시파일 이름을 위한 디렉토리는 밑의것들을 시 험함으로 인해 결정한다.
디렉토리는 반드시 존재하고 기록가능해야 한다.
o 환경 변수 TMPDIR이 정의되었는지...
o dir 인수가 널 포인터인지...
o P_tmpdir 매크로의 값.
o '/tmp' 디렉토리.
이 함수는 SVID와의 호환성을 위해 정의되었다.
SVID 매크로 : char * P__tmpdir
이 매크로는 임시파일을 위한 디폴트(default) 디렉토리의 이름이다. 오래된 유닉스 시스템들은 설 명된 함수들을 가지고 있지 않다. 대신에 그들은 mktemp 와 mkstemp 를 사용한다. 이들 함수들 은 당신이 준파일 이름 템플리트 문자열을 갱신하는 작업을 한다. 문자열의 마지막 6섯개 문자들은 만드시 'XXXXXX'이 되어야만한다. 이들 6개 'X' 문자들은 단일한 파일 이름 문자열을 만든 6개 의 문자들로 대체된다. 문자열은 보통 '/tmp/prefixXXXXXX'처럼 사용하고 각각의 프로그래은 단 일한 prefix를 사용한다.
노트 : mktemp 와 mkstemp가 템플리트 문자열을 갱신하기 때문에, 당신은 그들에게 문자열 상수를 주지않아야 한다. 문자열 상수들은 보통 오직 읽기만 가능한 기억장소에 존재하고, 그래서 당신의 프로그램은 mktemp 나 mkstemp가 문자열을 갱신하려 시도할 때 파괴되고 만다.
함수 : char * mktemp (char *template)
mktemp함수는 위에 설명된 것처럼 임시 문자열을 고쳐서 단일한 파일이름을 생성한다. 만일 성공 하면, 갱신된 템플리트를 리턴한다. 만일 mktemp가 단일한 파일 이름을 발견할 수 없다면, mktemp는 빈 문자열을 만들고 그것을 리턴한다. 만일 그 템플리트에 'XXXXXX'로 끝나지 않는다 면, mktemp는 널 포인터를 리턴한다.
함수 : int mkstemp (char *template)
mkstemp함수는 mktemp가 하는것처럼 단일한 파일 이름을 생성하지만, mkstemp는 또한 open의 과정을 통해서 당신을 위해 그 파일을 개방한다 ( 8.1절 [Opening and Closing Files] 103 페이지 참 조). 만일 성공하면 적당한 템플리트를 갱신하고 그 파일을 읽기와 쓰기를 위해 개방해서 리턴한다. 만일 mkstemp가 단일한 이름을 가진 파일을 만들 수 없다면 그것은 빈 문자열의 템플리트를 만들 고 -1을 리턴한다. 만일 템플리트가 'XXXXXX'로 끝나지 않는다면, mkstemp는 -1을 리턴하고 템 플리트를 갱신하지 않는다.
mktemp와 달리, mkstemp는 임시 파일을 만들려 시도하고 있는 다른 프로그램과 충돌의 가능성이 없이 단일한 파일을 만드는 것을 보증한다. 그 이유는 open함수에 O_EXEL 플래그 비트를 사용함으 로 인해서, 당신이 항상 새로운 파일을 만들기를 원함을 알리고, 그 파일이 이미 존재한다면 에러를 나타내도록 작업하기 때문이다.