리눅스에서 0 바이트의 파일을 만드는 개념은 무엇입니까?

내가 다음을 수행하면 :

touch /tmp/test

그런 다음 수행

ls -la /tmp/

디렉토리에서 0 바이트 의 test파일을 볼 수 있습니다 .

그러나 운영 체제는 0 바이트 개념을 어떻게 처리합니까 ? 평신도 용어로 말하면 :

0 바이트는 메모리가 전혀 없으므로 아무 것도 생성되지 않습니다.

파일의 생성 해야 하거나 해야 적어도 권리, 특정 메모리를 필요로?

파일은 (거의) 세 가지로 구분됩니다.

• 파일, 권한 및 실제로 데이터를 포함하는 디스크의 블록 목록을 소유 한 사람을 추적하는 메타 데이터 구조 인 "inode"입니다.
• 해당 inode를 가리키는 하나 이상의 디렉토리 항목 (파일 이름)
• 실제 데이터 블록 자체

빈 파일을 만들 때는 inode와 해당 inode를 가리키는 디렉토리 항목 만 만듭니다. 스파 스 파일 ( dd if=/dev/null of=sparse_file bs=10M seek=1)과 동일합니다 .

기존 파일에 대한 하드 링크를 만들 때 동일한 inode를 가리키는 추가 디렉토리 항목 만 만들면됩니다.

나는 여기서 물건을 단순화했지만 아이디어를 얻었습니다.

touch만듭니다 아이 노드를 하고, ls -i또는 stat아이 노드에 대한 정보를 표시합니다 :

$ touch test
$ ls -i test
28971114 test
$ stat test
  File: ‘test’
  Size: 0           Blocks: 0          IO Block: 4096   regular empty file
Device: fc01h/64513d    Inode: 28971114    Links: 1
Access: (0664/-rw-rw-r--)  Uid: ( 1000/1000)   Gid: ( 1000/1000)
Access: 2017-03-28 17:38:07.221131925 +0200
Modify: 2017-03-28 17:38:07.221131925 +0200
Change: 2017-03-28 17:38:07.221131925 +0200
 Birth: -

test0 개의 블록 을 사용합니다. 표시된 데이터를 저장하기 위해 inode는 일부 바이트를 사용합니다. 해당 바이트는 inode 테이블에 저장됩니다. inode 구조 의 예 는 ext2 페이지를 참조하십시오 .

ls(또는 stat(2)시스템 호출)은 파일 내용 의 크기를 알려줍니다 . 파일 시스템이 부기 유지에 필요한 공간은 그 일부가 아니며 구현 세부 사항으로서 일반적으로 프로그램 이 관심을 갖거나 알아야 할 것이 아닙니다 . 구현 세부 사항을 표시하면 파일 시스템 추상화가 덜 유용합니다.

파일 자체는 공간을 차지하지 않지만 파일 시스템은 파일 이름, 위치, 파일에 대한 액세스 권한 등을 저장합니다.

간단한 대답 : 그렇게 정의 되었기 때문입니다.

더 긴 대답 : 일부 작업은 개념적으로 더 간단하기 때문에 그렇게 정의됩니다.

• 파일에 20 자 "A"가 포함되어 있고 모든 "A"를 제거하면 파일이 20 바이트 더 짧아집니다. "AAAAAAAAAAAAAAAAAAAA"로만 구성된 파일에 대한 동일한 작업은 사라지는 파일의 특수한 경우를 처리해야합니다.
• 보다 실질적으로 텍스트 파일의 마지막 줄을 삭제하는 것은 특별한 경우가 필요합니다.
• 정기적으로 백업을 수행하는 텍스트 편집기는 사용자가 마지막 행을 삭제하고 점심 식사를 한 다음 다시 와서 다른 행을 추가 할 수있는 상황을 처리하기 위해 특수 코드가 필요합니다. 다른 일부 사용자가 그 이름으로 해당 이름의 파일을 생성 한 경우에는 추가로 복잡한 문제가 발생합니다.

더 많은 작업을 수행 할 수 있습니다. * 오류 로그 파일은 빈 상태로 만들어져 오류가 발생한 경우에만 채워지는 경향이 있습니다. * 얼마나 많은 오류가 발생했는지 확인하기 위해 로그 파일의 줄 수를 계산합니다. 로그 파일이 비어 있으면 오류 수가 0이므로 완벽하게 이해됩니다. * 때로는 모든 관련 텍스트가 파일 이름에있는 파일을 볼 수 있습니다 (예 :) this-is-the-logging-directory. 이는 설치 후 관리자가 빈 디렉토리를 삭제하지 못하도록하며, 프로그램 또는 사용자가 실수로 프로그램이 디렉토리를 나중에보고 싶은 파일을 작성하는 버그를 방지합니다. git프로그램 (및 기타)는 빈 디렉토리를 무시하는 경향이 있고, 프로젝트 / 관리자 / 사용자 디렉토리가 더 유용한 콘텐츠를 (아직)이없는 경우에도 존재한다는 기록이 원한다면, 당신은라는 빈 파일을 볼 수 있습니다empty또는 empty.directory.

더 복잡한 작업은 없습니다.

• 파일 연결 :이 파일은 빈 파일이없는 상태입니다.
• 파일에서 문자열 검색 : "파일이 검색어보다 짧은 경우 검색어를 포함 할 수 없습니다"의 표준 경우에 적용됩니다.
• 파일에서 읽기 : 프로그램은 예상 한 결과를 얻기 전에 파일의 끝을 누르는 것을 처리해야하므로 길이가 0 인 파일의 경우 다시 프로그래머가 생각하지 않아도됩니다. 처음부터 파일.

파일의 경우, "어딘가에 기록 된 파일이 있습니다"측면 (아이 노드 및 / 또는 파일 이름)이 위의 고려 사항보다 우선하지만 파일 시스템은 빈 파일이 쓸모없는 경우에는 그렇게하지 않습니다.

일반적으로 파일 이름과 관련된 이유를 제외한 위의 모든 이유는 시퀀스에 적용됩니다. 문자열 순서는 문자 순서입니다. 길이가 0 인 문자열은 프로그램 내부에서 일반적입니다. 문자열은 이해가되지 않으면 보통 사용자 수준에서 허용되지 않습니다. 파일 이름은 문자열이며 대부분의 파일 시스템은 빈 문자열을 파일 이름으로 허용하지 않습니다. 내부적으로 프래그먼트에서 파일 이름을 만들 때 프래그먼트 중 하나로 빈 문자열이 프로그램에있을 수 있습니다.

가장 간단한 유추 사용하기 :

예를 들어 물 한 잔과 파일을 비교해 봅시다.

'touch / tmp / test'는 물이없는 빈 유리를 만드는 것과 매우 흡사합니다. 유리가 비어 있으므로 크기가 0입니다. 그러나 유리는 존재합니다.

파일 시스템 용어에서 유리는 메타 데이터이고 유리의 내용은 데이터입니다. 메타 데이터에는 이전 게시물에서 언급 한 모든 종류의 내용이 포함됩니다.

크기가 0 인 파일이 유용 할 수 있습니다. 하나의 예는 그것들을 빵 부스러기로 사용하는 것인데, 그 존재만으로 일종의 상태를 나타낼 수 있습니다 (즉, 파일이 존재하는 경우 : 무언가를하십시오; 그렇지 않으면 : 무시하십시오).

프로그램이 서버로 보낸 SQL 쿼리를 추적한다고 가정 해보십시오. 프로그램이 요청을 일반 텍스트 파일로 기록하고 있지만 아직 기록 된 요청이 없음을 표시하려고합니다. 어떻게 생겼을까 요? 에서 크기가 0 인 파일이어야한다고 주장합니다 /var/log/acme-sql-server/queries.log. 이렇게하면 로깅이 시작된 시점 (파일 생성 시간), 마지막으로 업데이트 된 시점 (예 : 생성 된 시점), 기록 된 쿼리 수 (파일의 줄 바꿈 수 = 0) 및 로깅을 수행하는 사람을 파악할 수 있습니다. (Acme SQL Server). 이와 같은 경우에는 특정 위치에 빈 파일이 있다는 개념을 갖는 것이 유용합니다.