컴퓨팅에서, tar는 배포 또는 백업 목적으로, 종종 tarball이라고 참조되며, 하나의 아카이브 파일로 많은 파일을 수집하는 컴퓨터 소프트웨어 유틸리티입니다. 그 이름은 "tape archive"에서 파생되었는데, 왜냐하면 그것은 원래 자체 파일 시스템을 갖지 않는 순차 I/O 장치에 데이터를 기록하기 위해 개발되었기 때문입니다. tar에 의해 생성된 아카이브 데이터 집합은 이름, 타임스탬프, 소유권, 파일-접근 권한 및 디렉토리 구성과 같은 다양한 파일 시스템 매개변수를 포함합니다.
Usage
타르볼을 풀 때, 특정 디렉토리에 풀 수 있습니다.
- sudo tar xvf aaa.tar.gz -C target_directory
비슷하게 unzip은 다음과 같이 사용됩니다:
- sudo unzip -x aaa.zip -d target_directory
History
그 명령-줄 유틸리티는 1979년 1월 버전 7 유닉스에서 처음 도입되었으며, tp 프로그램을 대체했습니다. 이 정보를 저장하기 위한 파일 구조는 POSIX.1-1988 및 이후 POSIX.1-2001에서 표준화되었고, 대부분의 최신 파일 보관 시스템에서 지원하는 형식이 되었습니다.
오늘날, 유닉스-계열 운영 시스템은 보통 tar 파일을 지원하는 도구와 gzip과 bzip2와 같은 파일을 압축하기 위해 공통적으로 사용되는 유틸리티를 포함합니다.
BSD-tar는 Windows 10 2018년 4월 업데이트 이후 Microsoft Windows에 포함되었고, 그렇지 않으면 윈도우에서 이들 형식을 읽고 쓸 수 있는 여러 타사 도구가 있습니다.
tar 명령은 IBM i 운영 시스템에도 이식되었습니다.
Rationale
많은 역사적 테이프 드라이브는 가변-길이 데이터 블록을 읽고 쓰기 때문에, 블록 사이의 테이프에 상당한 낭비된 공간을 남겼습니다 (테이프가 물리적으로 이동을 시작하고 중지하기 위해). 일부 테이프 드라이브 (및 원시 디스크)는 오직 고정-길이 데이터 블록을 지원합니다. 역시, 파일 시스템 또는 네트워크와 같은 임의의 매체에 기록할 때, 하나의 큰 블록을 쓰는 것이 여러 개의 작은 블록에 쓰는 것보다 시간이 덜 걸립니다. 따라서, tar 명령은 많은 512 B 블록의 레코드에 데이터를 씁니다. 사용자는 레코드당 블록의 숫자인 블럭킹 인수를 지정할 수 있습니다. 기본값은 20이며, 10 KiB 레코드를 생성합니다.
File format
타르 아카이브는 일련의 파일 개체, 따라서 인기있는 용어 tarball로 구성되며, 타르볼이 표면에 달라붙는 모든 종류의 개체를 모으는 방법을 참조합니다.
이 표면에 달라붙는 모든 종류의 개체를 수집하는 방법을 나타내는 tarball이라는 용어가 많이 사용됩니다. 각 파일 개체는 임의의 파일 데이터를 포함하고, 512바이트 헤더 레코드가 앞에 옵니다. 파일 데이터는 그것의 길이가 512 바이트의 배수로 반올림된다는 점을 제외하고 변경되지 않고 기록됩니다. 원래 타르 구현은 패딩 바이트의 내용을 신경 쓰지 않았고, 버퍼 데이터를 변경하지 않은 채로 두었지만, 대부분의 최신 타르 구현은 여분의 공간을 영으로 채웁니다. 아카이브의 끝은 적어도 두 개의 연속적인 영으로 채워진 레코드에 의해 표시됩니다. (타르의 레코드 크기의 기원은 버전 7 유닉스 파일 시스템에서 사용된 512-바이트 디스크 섹터인 것으로 보입니다.) 아카이브의 마지막 블록은 영으로 전체 길이를 채워집니다.
Header
파일 헤더 레코드는 파일에 대한 메타데이터를 포함합니다. 다른 바이트 순서를 갖는 다른 아키텍처에 걸쳐 이식성을 보장하기 위해, 헤더 레코드에서 정보는 ASCII로 인코딩됩니다. 따라서 만약 아카이브에서 모든 파일이 ASCII 텍스트 파일이고, ASCII 이름을 가지면, 아카이브는 필연적으로 ASCII 텍스트 파일 (많은 NUL 문자 포함)입니다.
원래 유닉스 타르 형식으로 정의된 필드는 아래 테이블에 나열되어 있습니다. 링크 표시기/파일 유형 테이블은 일부 현대 확장을 포함합니다. 필드가 사용되지 않을 때, 그것은 NUL 바이트로 채워집니다. 헤더는 257 바이트를 사용하고, 그런-다음 NUL 바이트로 채워져 512바이트 레코드를 채웁니다. 파일 식별을 위해 헤더에서 "매직 넘버"가 없습니다.
Pre-POSIX.1-1988 (i.e. v7) 타르 헤더:
| 필드 옵셋 | 필드 크기 | 필드 |
| 0 | 100 | File name |
| 100 | 8 | File mode (octal) |
| 108 | 8 | Owner's numeric user ID (octal) |
| 116 | 8 | Group's numeric user ID (octal) |
| 124 | 12 | File size in bytes (octal) |
| 136 | 12 | Last modification time in numeric Unix time format (octal) |
| 148 | 8 | Checksum for header record |
| 156 | 1 | Link indicator (file type) |
| 157 | 100 | Name of linked file |
Pre-POSIX.1-1988 링크 표시기 필드는 다음 값을 가질 수 있습니다:
| 링크 표시기 필드 | |
| 값 | 의미 |
| '0' or (ASCII NUL) | 보통 파일 |
| '1' | 하드 링크 |
| '2' | 심볼릭 링크 |
일부 pre-POSIX.1-1988 타르 구현은 이름에 후행하는 슬래시 (/)를 가짐으로써 디렉토리를 표시했습니다.
숫자 값은 선행하는 영들을 갖는 ASCII 자릿수를 사용하여 팔진수로 인코딩됩니다. 역사적 이유로, 최종 NUL 또는 스페이스 문자도 사용되어야 합니다. 따라서 비록 파일 크기를 저장하기 위해 예약된 12 바이트 있을지라도, 오직 11 팔진 자릿수가 저장될 수 있습니다. 이것은 아카이브된 파일에 8 GB의 최대 파일 크기를 제공합니다. 이러한 한계를 극복하기 위해, 2001년 스타에서 숫자 필드의 맨 왼쪽 바이트의 상위 비트를 설정함으로써 표시되는 base-256 코딩을 도입했습니다. GNU-tar와 BSD-tar는 이 아이디어를 따랐습니다. 추가적으로, 1988년의 첫 번째 POSIX 표준 이전의 타르 버전은 값에 영 대신 공백으로 채웁니다.
체크섬은 헤더 레코드의 부호-없는 바이트 값과 ASCII 스페이스로 여겨지는 8개의 체크섬 바이트 (십진수 값 32)의 합을 취함으로써 계산됩니다. 그것은 선행하는 0과 NUL, 공백이 차례로 뒤따르는 여섯 팔진수로 저장됩니다. 다양한 구현이 이 형식을 따르지 않습니다. 게다가, 일부 역사적인 타르 구현은 바이트를 부호화된 것으로 처리했습니다. 구현은 전형적으로 두 가지 방법으로 체크섬을 계산하고, 부호화된 합계 또는 부호 없는 합계가 포함된 체크섬과 일치하면 이것을 양호한 것으로 처리합니다.
유닉스 파일시스템은 같은 파일에 대해 여러 링크 (이름)를 지원합니다. 만약 여러 그러한 파일은 타르 아카이브에 나타나면, 오직 첫 번째 파일이 보통 파일로 아카이브됩니다; 나머지는 "링크된 파일의 이름" 필드가 첫 번째 파일의 이름으로 설정된 하드 링크로 아카이브됩니다. 추출 시, 그러한 하드 링크는 파일 시스템에서 다시 생성되어야 합니다.
UStar format
대부분의 최신 타르 프로그램은 1988년부터 POSIX IEEE P1003.1 표준에 의해 도입된, UStar (Unix Standard TAR) 형식에서 아카이브를 읽고 씁니다. 그것은 추가적인 헤더 필드를 도입했습니다. 이전 타른 프로그램은 여분의 정보 (부분적으로 이름-지어진 파일 추출 가능)를 무시할 수 있지만, 더 새로운 프로그램은 "ustar" 문자열이 있는지 테스트하여 새로운 형식이 사용 중인지 확인합니다. UStar 형식은 더 긴 파일 이름을 허용하고 각 파일에 대한 추가적인 정보를 저장합니다. 최대 파일이름 크기는 256이지만, 그것은 이전 경로 "filename prefix"와 파일이름 자체로 분할되므로. 훨씬 작을 수 있습니다.
| 필드 옵셋 | 필드 크기 | 필드 |
| 0 | 156 | (이전 형식에서와 같은 여러 필드) |
| 156 | 1 | 유형 플래그 |
| 157 | 100 | (이전 형식에서 처럼 같은 필드) |
| 257 | 6 | UStar indicator "ustar" then NUL |
| 263 | 2 | UStar version "00" |
| 265 | 32 | 소유자 사용자 이름 |
| 297 | 32 | 소유자 그룹 이름 |
| 329 | 8 | 장치 주요 숫자 |
| 337 | 8 | 장치 보조 숫자 |
| 345 | 155 | 파일이름 접두사 |
유형 플래그 필드는 다음 값을 가질 수 있습니다:
| 유형 플래그 필드 | |
| 값 | 의미 |
| '0' or (ASCII NUL) | 보통 파일 |
| '1' | 하드 링크 |
| '2' | 심볼릭 링크 |
| '3' | Character special |
| '4' | 특수 문자 |
| '5' | 디렉토리 |
| '6' | FIFO |
| '7' | 연속 파일 |
| 'g' | 메타 데이터를 갖는 전역 확장 헤더 (POSIX.1-2001) |
| 'x' | 아카이브에서 다음 파일에 대해 메타 데이터를 갖는 확장 헤더 (POSIX.1-2001) |
| 'A'–'Z' | 벤더 지정 확장 (POSIX.1-1988) |
| 모든 다른 값 | 향후 표준화를 위해 예약됨 |
링크 플래그 값 'A'..'Z'를 사용하는 POSIX.1-1988 벤더 지정 확장은 다른 공급업체와 부분적으로 다른 의미를 가지고 따라서 구식으로 표시되고 벤더 태그를 역시 포함하는 POSIX.1-2001 확장으로 대체됩니다.
유형 '7'(연속 파일)은 공식적으로 POSIX 표준에서 예약된 것으로 표시되지만, 디스크에 연속적으로 할당되어야 하는 파일을 나타내기 위한 것입니다. 이러한 파일 생성을 명시적으로 지원하는 운영 시스템은 거의 없고, 따라서 대부분의 타르 프로그램은 이를 지원하지 않고, 유형 7 파일을 유형 0 (정규)인 것처럼 처리합니다. 연속 파일을 요청하기 위해 open() 함수에 O_CTG 플래그를 지원하는 MASSCOMP RTU (실시간 유닉스) 운영 시스템에서 실행할 때, GNU tar의 이전 버전은 예외입니다; 어쨌든, 그 지원은 GNU tar 버전 1.24부터 제거되었습니다.
POSIX.1-2001/pax
1997년에, Sun은 타르 형식에 확장자를 추가하는 방법을 제안했습니다. 이 방법은 나중에 POSIX.1-2001 표준에 대해 승인되었습니다. 이 형식은 확장된 타르 형식 또는 pax 형식이라고 합니다. 새로운 타르 형식은 임의의 유형의 벤더-태그된 벤더-지정된 개선 사항을 추가하는 것을 허용합니다. 다음 태그는 POSIX 표준에 의해 정의됩니다:
- atime, mtime: 임의 해상도에서 파일의 모든 타임스탬프 (대부분의 구현은 나노초 세분성을 사용합니다)
- path: 길이에 제한이 없는 경로 이름 및 문자 집합 코딩
- linkpath: 길이 및 문자 집합 코딩에 제한이 없는 심볼릭 링크 대상 이름
- uname, gname: 무제한 길이의 사용자 및 그룹 이름 및 문자 집합 코딩
- size: 크기가 무제한인 파일 (이전 타르 형식은 8GB임)
- uid, gid: 크기 제한이 없는 userid 및 groupid (이 역사적 타르 형식은 최대 id 2097151로 제한되었습니다)
- 경로 이름 및 사용자/그룹 이름에 대해 문자 집합 정의 (UTF-8)
2001년에, Star 프로그램은 새로운 형식을 지원하는 최초의 타르가 되었습니다. 2004년에, GNU tar는 새로운 형식을 지원했지만, 아직 tar 프로그램의 기본 출력으로 쓰지는 않습니다.
그것은 UStar 형식을 읽을 수 있는 모든 구현이 POSIX.1-2001도 읽을 수 있도록 설계되었습니다. 유일한 예외는 더 긴 파일 이름과 같은 확장 기능을 사용하는 파일입니다. 호환성을 위해, 특수 x 또는 g 유형 파일로 타르 파일에 인코딩됩니다. 전형적으로 PaxHeaders.XXXX 디렉토리 아래에 있습니다.: exthdr.name Pax-지원된 구현은 정보를 사용하지만, 7-Zip과 같은 비 지원 구현은 여분의 파일로 처리합니다.
Limitations
원래 타르 형식은 유닉스 초기에 만들어졌었고, 현재 널리 사용되고 있음에도 불구하고, 많은 디자인 기능이 오래된 것으로 고려됩니다.
많은 이전 타르 구현은 확장 속성 (xattrs) 또는 접근-제어 목록 (ACL)을 기록하지도 않고 복원하지도 않습니다. 2001년에, Star는 POSIX.1-2001 pax에 대해 자체 태그를 통해 ACL 및 확장된 속성에 대해 지원을 도입했습니다. Bsdtar는 star 확장을 ACL을 지원하기 위해 사용합니다. 최신 버전의 GNU tar는 리눅스 확장 속성을 지원하여, star 확장을 다시 구현합니다. 많은 확장이 BSD tar, tar(5)에 대해 파일형식 설명서에서 검토됩니다.
다른 형식은 tar의 단점을 해결하기 위해 만들어졌습니다.
Tarbomb
해커 속어에서, tarbomb은 작업 디렉토리로 추출되는 많은 파일을 포함하는 타르 파일입니다. 그러한 타르 파일은 작업 디렉토리에 있는 같은 이름의 파일을 덮어쓰거나 한 프로젝트의 파일을 또 다른 프로젝트에 혼합함으로써 문제를 일으킬 수 있습니다. 디렉토리의 다른 내용에 산재된 많은 파일을 식별하고 삭제해야 하는 사용자에게는 기껏해야 불편합니다. 그러한 행동은 아카이브 생성자의 나쁜 에티켓으로 고려됩니다.
관련된 문제는 타르 파일을 생성할 때 절대 경로 또는 부모 디렉토리 참조의 사용입니다. 그러한 아카이브에서 추출된 파일은 종종 작업 디렉토리 외부의 비정상적인 위치에 생성될 것이고, tarbomb과 같이, 기존 파일을 덮어쓸 가능성이 있습니다. 어쨌든, 최신 버전의 FreeBSD 및 GNU tar는 플래그 -P 또는 옵션 --absolute-names으로 명시적으로 허용되지 않는 한 기본적으로 절대 경로와 부모-디렉토리 참조를 생성하거나 추출하지 않습니다. 많은 운영 시스템에서도 사용할 수 있고 Mac OS X v10.6의 기본 타르 유틸리티, bsdtar 프로그램은 역시 부모-디렉토리 참조 또는 심볼릭 링크를 따르지 않습니다.
만약 사용자가 이들 보안 조치를 제공하지 않는 아주 오래된 타르만 사용할 수 있으면, tar tf archive.tar 명령을 사용하여 타르 파일을 먼저 검사함으로써 이들 문제가 완화할 수 있으며, 이 명령은 내용을 나열하고 나중에 문제가 있는 파일을 제외할 수 있습니다.
이들 명령은 임의의 파일을 추출하지 않지만, 아카이브에 있는 모든 파일의 이름을 표시합니다. 만약 임의의 것이 문제가 되면, 사용자는 비어 있는 새 디렉토리를 만들고 이 디렉토리에 아카이브를 추출하거나 타르 파일을 완전히 피할 수 있습니다. 대부분의 그래픽 도구는 그것들을 압축 풀기 전에 아카이브의 내용을 표시할 수 있습니다. Vim은 타르 아카이브를 열고 그 내용을 표시할 수 있습니다. GNU Emacs는 역시 타르 아카이브를 열고 그 내용을 dired 버퍼에 표시할 수 있습니다.
Random access
타르 형식은 테이프 백업 장치로 스트리밍하기 위한 파일과 그들 속성에 대해 중앙 집중식 인덱스 또는 목차 없이 설계되었습니다. 아카이브는 파일을 나열하거나 추출하기 위해 순차적으로 읽혀야 합니다. 대형 타르 아카이브에 대해, 이것은 성능 저하가 발생하여, 개별 파일에 대한 임의 접근을 종종 요구하는 상황에 부적합한 타르 아카이브를 만듭니다.
Duplicates
타르 형식을 갖는 또 다른 문제는 아카이브에 있는 여러 (다른 가능성이 있는) 파일을 동일한 경로와 파일이름을 허용한다는 것입니다. 그러한 아카이브를 추출할 때, 보통 파일의 후자 버전이 전자를 덮어씁니다.
이것은 기술적으로 절대 경로 또는 참조하는 부모 디렉토리를 갖는 파일을 포함하지 않지만, 여전히 현재 디렉토리 외부의 파일을 덮어쓰는 비명시적 (명백하지 않은) tarbomb을 생성할 수 있습니다 (예를 들어, 아카이브는 같은 경로와 파일이름을 가진 두 개의 파일을 포함할 수 있으며, 그것의 첫 번째는 현재 디렉토리 외부의 어떤 위치에 대한 심볼릭 링크이고, 그것의 두 번째는 정규 파일입니다; 그런-다음 일부 타르 구현에서 그러한 아카이브를 추출하면 심볼릭 링크에 의해 가리키는 위치에 쓰기가 발생할 수 있습니다).
Key implementations
역사적으로, 많은 시스템이 타르를 구현해 왔고, 많은 일반 파일 아카이버는 타르를 적어도 부분적으로 지원합니다 (종종 아래 구현 중 하나 사용함). 타르의 역사는 "타르 전쟁"으로 알려진 비호환성 이야기입니다. 대부분의 타르 구현은 cpio 및 pax도 읽고 생성할 수 있습니다 (후자는 실제로 POSIX-2001-확장을 갖는 tar-형식입니다).
기원의 순서에 따른 주요 구현:
- Solaris tar, 원래 유닉스 V7 타르를 기반으로 하고 솔라리스 운영 시스템에서 기본값으로 제공됩니다.
- GNU tar는 대부분의 리눅스 배포판에서 기본값입니다. 그것은 1987년에 시작된 공개 도메인 구현 pdtar를 기반으로 합니다. 최신 버전은 ustar, pax, GNU 및 v7 형식을 비롯한 다양한 형식을 사용할 수 있습니다.
- FreeBSD tar (역시 BSD tar)는 Mac OS X을 포함한 대부분의 Berkeley Software Distribution-기반 운영 시스템에서 기본 타르가 되었습니다. 핵심 기능은 다른 응용 프로그램에 포함하기 위해 libarchive로 사용할 수 있습니다. 이 구현은 파일 형식을 자동으로 감지하고 tar, pax, cpio, zip, jar, ar, xar, rpm 및 ISO 9660 cdrom 이미지에서 추출할 수 있습니다. 그것은 역시 기능적으로 동등한 cpio 명령줄 인터페이스와 함께 제공됩니다.
- Schily tar (star로 더 잘 알려져 있음)는 일부 확장 기능이 꽤 유명했기 때문에 역사적으로 중요합니다. 그것은 1982년에 만들어진 가장 오래된 자유 타르입니다. 그것은 여전히 유지 관리되고 있습니다.
추가적으로, 대부분의 pax와 cpio 구현은 다양한 유형의 타르 파일을 읽고 생성할 수 있습니다.
Suffixes for compressed files
tar 아카이브 파일은 보통 파일 접미사 .tar (예를 들어, somefile.tar)를 가집니다.
타르 아카이브 파일은 그것이 포함하는 파일의 압축되지 않은 바이트 스트림을 포함하고 있습니다. 아카이브 압축을 위해, 다양한 압축 프로그램이 전체 타르 아카이브를 압축하는 gzip, bzip2, xz, lzip, lzma, zstd, 또는 compress와 같은 것을 사용할 수 있습니다. 전형적으로, 아카이브의 압축된 형식은 아카이브 파일 이름에 형식-지정 압축기 접미사를 덧붙임으로써 받습니다. 예를 들어, 타르 아카이브 archive.tar는 gzip으로 압축될 때 archive.tar.gz으로 이름-지어졌습니다.
타르의 BSD 및 GNU 버전과 같은 인기 있는 타르 프로그램은 Z (압축), z (gzip), 및 j (bzip2) 명령줄 옵션을 지원하여 생성 또는 푸는 아카이브 파일을 압축하거나 압축 해제합니다. 버전 1.20 이후의 GNU tar는 --lzma (LZMA) 옵션도 지원합니다. 1.21은 --lzop을 갖는 lzop에 대해 지원을 추가했습니다. 1.22에서는 --xz 또는 -J을 갖는 xz에 대해 지원을 추가했습니다. 1.23은 --lzip을 갖는 lzip에 대해 지원을 추가했습니다. 1.31는 --zstd을 갖는 ㅍ에 대해 지원을 추가했습니다. 만약 지원되는 파일이름 확장자가 사용되면 이들 형식의 압축 해제가 자동으로 처리되고, 만약 옵션 --auto-compress (짧은 형식 -a)이 GNU tar의 응용할 수 있는 버전에 전달되면 같은 파일이름 확장자를 사용하여 압축이 자동으로 처리됩니다.
MS-DOS의 8.3 파일이름 제한으로 인해 압축된 타르 아카이브의 이름-지정 규칙이 추가되었습니다. 어쨌든, FAT가 이제 긴 파일이름을 제공하면서 이 관행은 거부되었습니다.
| 파일 접미사 동등성 |
|
| 긴 | 짧은 |
| .tar.bz2 | .tb2, .tbz, .tbz2, .tz2 |
| .tar.gz | .taz, .tgz |
| .tar.lz | |
| .tar.lzma | .tlz |
| .tar.lzo | |
| .tar.xz | .txz |
| .tar.Z | .tZ, .taZ |
| .tar.zst | .tzst |
Troubleshootings
풀린 타르 삭제 간혹 타르볼을 시스템 영역에 잘못 풀어서 시스템에 악영향을 끼칠 수 있습니다. 아래와 같이 제거할 수 있습니다:
- sudo tar zxvf filename.tar.gz | xargs rm