NTFS

Microsoft Windows의 파일 시스템으로, MS-DOS와 Windows 9x에서 쓰인 FAT을 대체하기 위해 만들어졌다. FAT 시스템에 비해 몇 가지 개선사항이 있는데, 메타데이터의 지원, 고급 데이터 구조의 사용으로 인한 성능 개선, 신뢰성, 추가 확장 기능을 더한 디스크 공간 활용을 들 수 있다.

FAT 시스템에서 NTFS 시스템으로 변환하고 싶은경우 프롬포트를 관리자 권한으로 실행해서 convert d: /fs:ntfs를 실행하면 된다. 파일이 사라지지 않지만, 몇분에서 몇십분 가량 기다려야 한다.

처음 나올 당시엔 매우 획기적이었으나, 21세기 들어 오픈소스 진영이 폭발적으로 발달하면서 NTFS에 비교해도 전혀 떨어지지 않는 다양한 파일 시스템들이 선보이게 되었고, SUN의 ZFS 까지 등장하면서 현재는 그저 그런 파일 시스템이 되어버렸다. MS에서는 뒤처지지 않기 위해 NTFS를 기반으로하는 ReFS를 준비중이다.MSDN의 ReFS 설명.

처음으로 발표된 건 Windows NT 3.1이 발매된 1993년. 즉, Windows NT와 함께 탄생하였다. 현재 주로 쓰이는 NTFS인 3.1은 Windows XP부터 사용되었으며, 하위호환으로 Windows NT 4.0 서비스 팩 4부터 사용할 수 있다. (NT 4.0 서비스 팩 3 이전과는 호환 안 됨)

이 밖에도 파일 암호화라든지 수많은 기능을 가지고 있지만 역시 유저들에게 와닿는 기능은 파일용량 한계의 완화일 것이다. 특히 DVD의 보급으로 4GB가 넘는 ISO 파일을 FAT32에선 저장하질 못해[1], Windows 2000이 빠르게 소비자 시장에 퍼지게 된 원인이기도 하다.[2] 특히, Windows XP부터는 아예 하드나 이동식 디스크의 용량이 32GB가 넘으면 무조건 NTFS로 포맷하도록 해버리기 때문에, 구형 시스템에서 USB 메모리를 쓰기 위해 FAT32로 포맷하려면 서드파티 포맷 툴을 써야만 했다.

자체적으로 마운트를 지원한다. 드라이브를 포맷할 때 '비어 있는 NTFS 폴더에 탑재' 옵션을 선택하면 된다. VHD 파일을 만들어서 폴더에 탑재시키는 것도 가능하다.

NTFS를 사용해도 발생하는 제한은 있는데, 가장 큰 제한은 파일명 포함 최대 260자[3]로 제한된 경로명이다. 이것은 NTFS 자체의 제한은 아니며 원래 윈도우의 NT커널은 32,767자까지 지원할 수 있다. 다만, Win32 API 의 레거시 방식 경로 문자와 관련이 있는 MAX_PATH가 260자로 제한된 것이 문제. 아직도 Win32 API를 레거시 방식으로 사용하고 있는 프로그램들이 상당히 많고, 더 웃픈 것은, Windows 탐색기에서 기본적인 복사 명령도 레거시 Win32 API를 사용하여 저런 제한에 딱 걸린다는 것이다.
게다가 과거에 만들어진 프로그램들의 경우 경로 버퍼를 char path[MAX_PATH]; 와 같이 구현한 것들이 있다보니 제한을 막 해제할 경우 버퍼 오버플로우 문제를 야기시킬 수 있다는 문제가 있다.

덕분에 MS Explorer 네트워크상에서 저런 제한이 없는 다른 OS나 다른 파일 시스템에서 NTFS로 자료를 복사할 때 파일경로 길이 제한 때문에 복사를 못한다는 메시지가 뜨는 경우가 있고[4], 이것을 NTFS 파일 시스템의 한계로 알고 있는 사람도 적지 않다. 다른 복사 프로그램[5]을 사용하는 등 우회 방법이 있긴 한데, 많이 귀찮아서[6] 좀 불편해도 그냥 260자 안으로 파일경로를 구성하는 사람들이 많다.

Windows 10 1607부터 드디어 시스템 MAX_PATH 인식 제한을 없애는 옵션이 생겼다! 다만 기본으로는 켜져 있지 않고 로컬 그룹 정책 설정[7]에 가서 옵션을 바꿔줘야 하는 문제가 있다.

또한, NTFS는 원래 2⁶⁴이므로 거의 무한대에 가까운 파티션 제한용량을 가지고 있지만 Windows XP에선 2TB까지, Vista부터 10 1703 버전까진 2³²인 256TB까지, 10 1709 버전부터는 8PB까지 저장 가능하다. 거기다 32비트 운영 체제에서는 논리 파티션 하나마다 16TB가 한계. MBR 레코드가 위치하는 부트파티션은 한계가 2TB까지 내려간다. 이 제한은 GPT를 지원하는 64비트 운영 체제로 가야만 풀린다. 즉, 2TB보다 용량이 큰 드라이브는 32비트 운영 체제에서는 하나의 파티션으로 쓸 수 없다! 하지만 파일 용량 제한은 32비트에서도 파티션 하나 꼭 채우는 16TB이므로 큰 문제는 아니다.

그래도 주의해야 할 것이, 윈도우의 기본 탐색기에서는 여전히 260글자보다 긴 파일 경로를 입력받을 수 없는 Win32 API를 사용하고 있으므로 폴더 창을 이용한 복사나 붙여넣기는 작동하지 않는다는 점이다. 참고로, NTFS의 압축 파티션 기능이 작동하려면 클러스터 용량은 반드시 4KB 이하가 되어야만 한다. 이보다 큰 클러스터는 압축기능을 지원하지 않는다.

NTFS 시스템에는 인덱싱 기능이 있는데 이를 적극적으로 활용하는 Windows Vista 이후부터는 컴퓨터를 깔자마자 며칠 동안은 하드 데이터를 인덱싱하느라 컴퓨터가 좀 느릴 수도 있다. 하지만 일단 분석이 끝나면 Windows XP보다 쾌적하게 이용할 수 있다. 제어판에 있는 [색인 옵션] 아이콘을 클릭하면 무슨 폴더를 색인할 지, 몇 개의 항목이 색인되었는지 등을 확인할 수 있으며, 색인을 초기화한다거나 특정 파일 형식은 인덱싱하지 않는 등의 설정을 할 수 있다.

더블스페이스(드라이브 스페이스)는 지원하지 않는다. NTFS는 고유의 압축 기술이 있는데다가 Windows ME가 출시되기 전쯤부터 더블스페이스는 하드 디스크의 대용량화로 이미 사양길을 걷고 있었다. 따라서 오늘날 더블스페이스는 사실상 사장된 유틸리티이므로 개의치 않아도 된다.

macOS는 읽기만 지원한다.[8] 그래서 읽기·쓰기를 지원하는 다른 서드파티 툴을 사용해야한다. 오픈소스 프로그램인 ntfs-3g와 이의 상용버전인 Tuxera 같은 것들이 있다. 운영체제 자체의 공식 기능이 아닌만큼 그리 안정하지는 않다. 이는 NTFS가 유닉스 파일시스템이 아니라서 중간에 통역을 해주는 일종의 레이어 역할을 하는 프로그램(osxfuse 같은)을 거치기 때문이다. 파일명이 한글을 비롯한 유니코드로 되어 있을 경우 글자가 풀어지거나 정렬이 제대로 되지 않는 문제가 발생할 수 있는데, 유니코드 정규화 방식이 달라서 그렇다. 또한 윈도우에서 사용 못하는 문자[9]가 포함되어 있을 경우는 윈도우에서 읽어들였을때 문제가 생긴다.

리눅스에서도 커널은 읽기만 지원해, 상기된 NTFS-3G를 이용해야 읽기·쓰기가 가능하다. 마운트 옵션에 따라 쓰기 속도 차이가 나는 등, 조금 까다롭다. 빠른 쓰기를 위한 big_writes와 윈도우와의 호환성을 위한 windows_names을 옵션에 넣기를 추천한다. 자세한건 링크 참고.

이처럼 윈도우를 제외한 운영체제에서 NTFS 읽기만 지원하는 것은 NTFS가 마이크로소프트의 독점 포맷이기 때문인데, 포맷 자체가 공개된 정보가 적다 보니 리버스 엔지니어링 등 구조를 분석하여 구현된 경우가 대부분이라 쓰기 작업시 호환성 문제가 발생할수 있다. 대표적으로 Ubuntu 20.04에서 작성한 파일이 윈도우10에서 읽히지 않고 삭제되는 사례가 있다. Ubuntu20.04와 Windows 10 2004 (Build 19628) 에서 NTFS 호환성 확인 결과 따라서 NTFS는 윈도우 이외 환경에서는 읽기 전용으로 두는 것이 안전하다.

Windows 에서 EXT4 를 마운트하는 방법도 있기는 하다#궁여지책.