파일 크기는 어떻게 0이 될 수 있습니까?

내가 만났고 적절한 설명을 생각할 수 없었던 것입니다. PC에 빈 * .txt 파일을 만든 다음 크기를 보면 0으로 표시됩니다. 그러나 어떻게 가능합니까? 파일 자체가 비어 있더라도 자체 이름을 저장하기 위해 여전히 크기가 있어야합니다. 이것을 어떻게 설명 할 수 있습니까? (비 OS 별)

실제로 파일이 없기 때문에 가능합니다. 이름과 소유자가있는 디렉토리 항목 만 있습니다. 디렉토리 항목은 파일과 논리적으로 다릅니다. 예를 들어, 동일한 파일은 둘 이상의 디렉토리에 둘 이상의 이름을 가질 수 있습니다.

불행히도 "파일"이라는 용어가 항상 정확히 같은 의미로 사용되는 것은 아닙니다. 그러나 파일 크기 논리는 디렉토리 항목이 파일을 디렉토리에 "첨부"하고 파일 이름 및 관련 메타 데이터가 디렉토리에 저장되는 모델에서 비롯됩니다.

"파일 크기"의 의미 적 의미는 사용중인 것과 다릅니다.

의미있는 많은 파일 크기가 있습니다. 가장 일반적인 것 및 여기에서 보는 것은 "파일의 바이트 수"입니다. 파일이 빈 텍스트 파일 인 경우 실제로 0 바이트를 포함 할 수 있습니다. 이 숫자는 프로그래머에게 중요합니다. 파일을 열고 "모든 데이터를 읽고"닫아야하기 때문입니다. 미리 계획 할 수 있도록 파일에 몇 바이트의 데이터가 있는지 알아야합니다.

또 다른 의미는 대부분의 파일 시스템이 데이터를 저장하는 방식에서 발생합니다. 대부분의 파일 시스템은 데이터를 블록에 저장합니다. 예를 들어, 파일 시스템은 64kB 블록에 데이터를 저장할 수 있습니다. 즉, 64kB의 배수가 아닌 것은 할당하지 않습니다. 이것은 비효율적으로 들리지만, 부기를 아주 간단하게 만들 수 있으며 종종 더 간단한 수단을 더 빠르게 만들 수 있습니다.

잡아 당기는 세 번째 의미는 파일의 존재를 설명하기 위해 하드 드라이브에 필요한 실제 비트 수입니다. 여기에는 일반적으로 파일과 별도로 저장되는 정보가 포함됩니다. 예를 들어, Linux에서 "filename"의 개념은 파일을 포함하는 디렉토리에 대한 inode에 저장됩니다 (편집 : 주석에서 기술적으로 이것은 디렉토리의 데이터에 저장됩니다). -디렉토리 경우 156 바이트보다 작은 데이터는 inode에 직접 저장할 수 있습니다. 파일 시스템의 내부 작업이 깊지 않고 결정하기가 매우 어렵 기 때문에 일반적으로 사용되는 의미는 아닙니다 (파일에 대한 모든 권한을 저장하는 데 필요한 공간을 고려 했습니까?). 그러나 1,000,000 바이트 하드 드라이브가있는 경우

파일 이름이 다른 곳에 저장되어 있습니다.

디스크에는 "파일 시스템"이 있으며 실제 디스크에서 파일 이름과 파일을 표현하고 해석하는 방법을 간단히 선택할 수 있습니다.

대부분의 Windows 디스크에 당신이 "NTFS"(새로운 기술 파일 시스템 ")라는 파일 시스템, 마스터 파일 테이블이 저장 파일 이름 정보를 사용하는 것 (MFT)가. 파일의 내용에서 별도로 참조 마스터 파일 테이블에 위키 백과 문서를 .

따라서 파일 자체의 길이는 0 바이트이지만 MFT의 항목은 여전히 ​​일부 공간을 차지합니다.

이것은 매우 흥미로운 존재 론적 질문입니다 ...

파일 자체는 파일의 내용입니다. 파일에 내용이 없으면 크기가 0입니다. 파일 이름은 자신의 이름이 실제로 당신의 일부인 것처럼 (즉, 그렇지 않은) 파일의 많은 부분입니다.

실제 이름이 사람을 가리키고 가리키는 사람의 머리 (및 자신의 이름)에 이름으로 존재하는 것처럼 파일 이름은 파일 시스템의 디렉토리 트리에 존재하며 파일을 가리 키거나 가리 킵니다.

(답변에 조금 늦었다 ...)

파일 크기가 0이되는 방법은 위의 답변에서 제공하는 것보다 약간 더 복잡합니다. 이 질문에는 Win7이라는 태그가 붙어 있지만 FAT 나 NTFS 같은 다른 "더 단순한"파일 시스템 을 보면 개념이 비슷하므로 유용 할 수 있습니다.

디스크는 파일과 디렉토리가 무엇인지 "알지"않습니다. 작은 블록의 모든 데이터입니다. OS는 데이터 블록의 의미를 구별합니다. 처음 몇 개는 스페셜이지만 나머지 블록은 데이터에 대한 정보 (예 : 파일 이름, 파일 길이, 데이터를 보유한 첫 번째 데이터 블록) 또는 데이터 자체를 보유합니다.

디렉토리는 OS가 이해하는 "데이터"가 파일의 내용이 아니라 파일에 대한 정보를 포함하는 정보 블록 인 특수한 "파일"입니다. 좋은 비유는 물리적 라이브러리와 카드 카탈로그입니다. 정보 블록을 카드 카탈로그로, 선반을 데이터 블록으로 생각하십시오 (카드 카탈로그는 선반과 같은 구조에 있습니다).

파일을 "만들"면 (예 : UNIX touch명령으로) OS는 먼저 다음과 같이 정보 블록 (디렉토리)에 항목을 만듭니다.

• 이름 = My_File.txt
• 길이 = 0
• 데이터 블록 시작 = N / A
• 추가 정보 (소유자, 권한, 생성 / 업데이트 / 수정 날짜) 등

"쓰기"할 데이터가있는 경우에만 데이터를 저장할 빈 데이터 블록을 찾습니다. 그러나 데이터 블록은 고정 크기 (예 : 32K)로 디스크를 가져오고 OS를 읽기에 편리합니다. "Hello"만 쓰면 대부분의 블록이 "빈"(실제로 0이 아닐 수 있지만 이전에 있던 쓰레기) 테이블이 이제 크기를 길이 (5 자 + 끝의 끝)로 업데이트합니다. File) 따라서 나쁜 물건을 얻지 못합니다.

"파일"을 길이> 블록 크기로 업데이트하면 OS가 데이터를 새 블록에 쓰고 데이터 블록을 업데이트하여 파일이 첫 번째 이후에 다음 블록으로 계속되고 길이가 업데이트됨을 나타냅니다. 새로운 길이 (세부 사항이 다름).

결국 데이터 블록 체인 (파일 내용)에 대한 정보가있는 정보 데이터 블록 (디렉토리 또는 목록)의 모음입니다.

논리적으로 이것은 동일한 파일 시스템에서 파일 이동이 빠른 시간 동안 깜박이는 이유를 설명합니다. OS는 하나의 디렉토리 (정보 데이터 블록)에서 항목을 제거하고 다른 디렉토리에 추가하기 위해 2 개의 디렉토리 블록 만 편집하면됩니다. 파일 삭제 : 디렉토리 블록에서 항목을 제거하면 파일 데이터 블록을 재 할당 할 수 있습니다.

추신 : 카드 카탈로그에 책에 대한 항목이 있다고해서 책이 선반에 있음을 의미하지는 않습니다 (체크 아웃 또는 잃어버린 것). 파일 크기 0.

pps : 라이브러리 안에 잘못 놓인 책은 검색 라이브러리 또는 컴퓨터 용어 인 chkdsk 또는 디스크 복구를 의미합니다!

UNIX inode에 대해 읽거나 버전 제어 시스템 (ClearCase, TFS, Git 등)이 파일 및 디렉토리뿐만 아니라 파일 버전 및 디렉토리 버전을 관리하는 방법을 이해함으로써 더 큰 이해를 얻을 수 있습니다. 대부분의 경우 모든 것이 데이터베이스에 저장되고 사용자에게 클래식 디렉토리 구조 및 파일로 표시됩니다!

여기에 훌륭한 답변이 있습니다-그림 버전 (천 단어와 그 모든 것)을 추가하고 싶습니다.

이것은 디스크 조각 모음 도구를 사용하여 NTFS로 포맷 한 하드 드라이브 중 하나의 모양입니다. MFT (마스터 파일 테이블)은 보라색으로 표시됩니다 :

그 작은 보라색 사각형은 내 HD에있는 파일 목록을 나타냅니다. 대략적으로 NTFS 디스크의 경우 목차는 책의 내용입니다. 페이지 대신, 나머지 디스크 ¹ 의 실제 위치를 가리 킵니다 .

0 바이트 크기의 파일은 페이지가 전혀 없음을 나타내는 목차 항목으로 시각화 할 수 있습니다.

항목이 나열되어 있지만 페이지가 표시되지 않으므로 내용이 존재하지 않는다고 가정 할 수 있습니다.

^{1-확실히, 그것보다 조금 더 복잡합니다. 섹터 맵, 미러 MFT 등과 같은 포인트는이 질문의 범위를 벗어납니다.}

파일 시스템 은 파일 이름, 파일 크기, 생성 시간, 액세스 시간, 수정 된 시간, 생성 된 사용자, 사용자 및 그룹 권한, 조각, 파일을 저장하는 클러스터에 대한 포인터, 하드 / 소프트 링크, 속성 과 같은 파일 에 대한 많은 정보 를 저장합니다 ... 이를 파일 메타 데이터 라고 합니다 . 사용자가 관심을 갖지 않아도되고 알지 못하는 경우 왜 이러한 메타 데이터를 파일 크기로 계산합니까? 그들은 단지 파일 내용에만 관심이 있습니다.

또한 각 파일 시스템은 디스크에서 서로 다른 공간을 차지하는 서로 다른 유형의 메타 데이터 를 저장 합니다. 예를 들어 POSIX 권한은 NTFS 권한과 매우 다르며 inodePOSIX에는 Windows에는없는 숫자 도 있습니다. POSIX 파일 시스템도 32 비트 블록 주소가있는 ext3, 48 비트가있는 ext4, 64 비트가있는 Btrfs 및 128 비트 주소가있는 ZFS와 같이 많이 다릅니다. 그렇다면 메타 데이터를 파일 크기로 어떻게 계산합니까?

메타 데이터가 현재 파일 시스템에서 56 바이트를 소비하는 100 바이트 파일의 다른 예를 들어보십시오. 파일을 다른 파일 시스템으로 복사하면 이제 128 바이트의 메타 데이터가 필요합니다. 그러나 파일 내용은 정확히 동일 하며 파일 의 바이트 수도 동일합니다. 따라서 시스템에서는 파일 크기를 156 바이트로 표시하지만 다른 시스템에서는 228 바이트로 표시하는 것은 매우 혼란스럽고 직관적이지 않습니다 .

의 파일 크기는 0말하는 것과 비슷 5합니다. 단어 가 적힌 종이가 있습니다. 그리고 다른 종이에는 그 0단어가 있습니다. 그래서 0전적으로 가능하다.

파일의 메타 데이터 (생성 날짜 시간, 마지막 수정 날짜 시간, 파일 소유자, 권한)는 모두 파일 크기의 일부로 포함되지 않은 곳에 저장됩니다.

파일을 작성할 때 간단한 방법으로 이해하십시오. 제공 한 파일 이름으로 식별 된 파일의 메모리 위치에 대한 포인터 역할을하는 디렉토리 항목이 생성됩니다. 더 많은 포인터를 만들거나 파일을 말하면 디렉토리의 크기가 증가합니다. 반면에 파일 크기는 뾰족한 위치, 즉 파일 자체 내부에 약간의 데이터를 넣는 경우에만 증가합니다. 그때까지 크기는 0이 될 것입니다. :)

이것이 작동하는 방식입니다.

볼륨에 파일을 작성하자마자 NTFS mata 파일 (예 : $ MFT (Master file table))에 파일 레코드가 작성됩니다. MFT에는 FRS (파일 레코드 세그먼트)가 있으므로 레코드를 볼 수 있습니다. NTFS FileSystem의 경우 기본적으로 각 파일 레코드의 크기는 1KB입니다. 그러나 해당 공간은 파일에 일부 정보를 저장 한 경우에만 청구됩니다. 텍스트 파일 인 것을 고려하여 단일 문자 "a"를 작성하더라도 FRS의 기본 크기이므로 1KB의 공간을 차지합니다. 문자 "a"는 해당 FRS의 기본 및 명명되지 않은 데이터 스트림 인 $ Data로 이동합니다. $ Data는 ADS (Alternate Data Stream)가없는 경우 모든 데이터가 저장되는 속성입니다.

궁금한 점이 있으면 알려주세요.

• NTFS 파일 증가 에 대한 자세한 내용 .
• NTFS 메타 파일 에 대한 자세한 정보 .