Linux 커널에는 아직 파일 생성 날짜를 얻을 수 있는 인터페이스가 없습니까?

Question 1

편집: 좋은 소식입니다. statx()병합되었으므로 버전 4.11에서 사용할 수 있습니다.

xstat() 작업(현재 statx())은 2016년에 개정되었습니다.

이번에는 프로세스가 더욱 엄격해졌습니다(자전거 흘림이 적고 나중에 추가될 수 있으므로 논란의 여지가 있는 속성을 삭제하는 데 동의함). 불행히도 정확한 인터페이스에 대해 여전히 이의를 제기하는 사람들이 있으며 업데이트된 참고 자료를 본 적이 없습니다.

Answer

편집: 좋은 소식입니다. statx()병합되었으므로 버전 4.11에서 사용할 수 있습니다.

xstat() 작업(현재 statx())은 2016년에 개정되었습니다.

이번에는 프로세스가 더욱 엄격해졌습니다(자전거 흘림이 적고 나중에 추가될 수 있으므로 논란의 여지가 있는 속성을 삭제하는 데 동의함). 불행히도 정확한 인터페이스에 대해 여전히 이의를 제기하는 사람들이 있으며 업데이트된 참고 자료를 본 적이 없습니다.

Question 2

일반적으로 사용되는 파일 시스템 중 어느 것도 이를 지원하지 않기 때문에

내가 아는 한(죄송합니다. 링크, 메모리, 인터넷 검색이 너무 많아서 여기에 참조용으로 나열할 만큼 응집력 있는 것은 없습니다.) 밑줄 시스템이 생성 시간 속성을 지원하지 않았기 때문이 아니라 할 수 없었기 때문입니다. 유용한 기능 중 하나라는 데 동의하지도 않습니다.

바라보다http://www.pathname.com/fhs/pub/fhs-2.3.html

POSIX는 세 개의 타임스탬프를 나열합니다. 그 중 어느 것도 창조 시간이 아닙니다.

내 기억이 맞다면 논쟁은 다음과 같았다.

> Give me a use case where we can't already do that using what we already have.
< Some examples were submitted
> All of these are convoluted beyond usefulness. 
> Ok, Ok, *maybe* a couple of these don't suck. 
> Now how do you see handling file systems that don't track this?
< several ideas that were not the same. 
< Basically everyone had a special case that would work, but not 
< one that always works. Fight about fallbacks and other special handling. 
> Ok, lets table that for now. What should we call this field
< At least 6 different answers emerged.
> So, you want to break POSIX standards, 
> you can't really come up with a good reason why, 
> you can't come up with a good fall back, and 
> you can't even come up with a name. 
> Sounds like it's specific to the file system to me, and that 
> should be "extended data" accessible by tools and not as 
> a core stat in the Kernel.

이제 많은 부분이 오래된 메일링 리스트를 기억하고 읽는 것입니다. 나는 논쟁의 중심에 있지도 않았습니다. 저는 임베디드 Linux 시스템용 팻 드라이버에 대한 임시 작업으로 인해 메일링 리스트에 등록되었습니다. 내가 이것을 언급하는 이유는 나만 관심을 갖고 있는 것에 대한 나의 기억보다 더 권위 있는 출처가 있어야 하기 때문입니다.

제가 기억하는 가장 큰 사실은 어느 누구도 좋은 사용 사례를 생각해낼 수 없었고, 생성 시간을 지원하지 않는 일반 파일 시스템의 다른 40개 필드를 처리하는 방법과 필드 이름 지정에 대해서도 누구도 동의할 수 없었다는 사실입니다. 제기된 질문 열띤 논쟁.

Answer

일반적으로 사용되는 파일 시스템 중 어느 것도 이를 지원하지 않기 때문에

내가 아는 한(죄송합니다. 링크, 메모리, 인터넷 검색이 너무 많아서 여기에 참조용으로 나열할 만큼 응집력 있는 것은 없습니다.) 밑줄 시스템이 생성 시간 속성을 지원하지 않았기 때문이 아니라 할 수 없었기 때문입니다. 유용한 기능 중 하나라는 데 동의하지도 않습니다.

바라보다http://www.pathname.com/fhs/pub/fhs-2.3.html

POSIX는 세 개의 타임스탬프를 나열합니다. 그 중 어느 것도 창조 시간이 아닙니다.

내 기억이 맞다면 논쟁은 다음과 같았다.

> Give me a use case where we can't already do that using what we already have.
< Some examples were submitted
> All of these are convoluted beyond usefulness. 
> Ok, Ok, *maybe* a couple of these don't suck. 
> Now how do you see handling file systems that don't track this?
< several ideas that were not the same. 
< Basically everyone had a special case that would work, but not 
< one that always works. Fight about fallbacks and other special handling. 
> Ok, lets table that for now. What should we call this field
< At least 6 different answers emerged.
> So, you want to break POSIX standards, 
> you can't really come up with a good reason why, 
> you can't come up with a good fall back, and 
> you can't even come up with a name. 
> Sounds like it's specific to the file system to me, and that 
> should be "extended data" accessible by tools and not as 
> a core stat in the Kernel.

이제 많은 부분이 오래된 메일링 리스트를 기억하고 읽는 것입니다. 나는 논쟁의 중심에 있지도 않았습니다. 저는 임베디드 Linux 시스템용 팻 드라이버에 대한 임시 작업으로 인해 메일링 리스트에 등록되었습니다. 내가 이것을 언급하는 이유는 나만 관심을 갖고 있는 것에 대한 나의 기억보다 더 권위 있는 출처가 있어야 하기 때문입니다.

제가 기억하는 가장 큰 사실은 어느 누구도 좋은 사용 사례를 생각해낼 수 없었고, 생성 시간을 지원하지 않는 일반 파일 시스템의 다른 40개 필드를 처리하는 방법과 필드 이름 지정에 대해서도 누구도 동의할 수 없었다는 사실입니다. 제기된 질문 열띤 논쟁.

Question 3

탄생 시간은 ext4뿐만 아니라 여러 Linux 기본 파일 시스템에 있었습니다.

Linux 커널 버전 4.11부터 시작(2017년 4월) 새로운 내용이 있습니다.statx()시스템 호출그것을 검색합니다. 그러나 해당 래퍼 함수는 아직 GNU libc에 추가되지 않았습니다(2018-06-26 기준).2019년 편집이제 2.28에 추가되었으며 GNU stat, ls등 의 도구는 find이를 사용하도록 업데이트되지 않았습니다(2019-08-22 편집GNU /Linux 시스템 stat의 glibc 2.28 이상은 coreutils 8.31부터 이를 지원합니다.2021-01-04 편집GNU에는 8.32부터 coreutils ls가 있습니다 --time=birth)

다음과 같이 이를 수행할 수 있습니다 perl.

perl -MPOSIX -e '
  require "syscall.ph";
  $buf = "\0" x 0x100; # enough space for a struct statx
  for (@ARGV) {
    # hardcode: AT_FDCWD == -100
    #           AT_SYMLINK_NOFOLLOW = 0x100 (lstat()-like)
    #           STATX_BTIME = 0x800 for the mask
    #           80: offset of the btime in the struct
    syscall(&SYS_statx, -100, $_, 0x100, 0x800, $buf) == 0
      or die "$_: $!\n";
    ($t, $n) = unpack("x80QQ", $buf);
    $n = sprintf("%09d", $n);
    print strftime("%F %T.$n %z\n", localtime $t)
  }' -- "$file"

없으면 하드코딩할 수도 있습니다 syscall.ph. SYS_statxamd64 아키텍처에서는 332입니다. 아니면 다음을 시도해 보세요.

printf '#include <syscall.h>\n__NR_statx\n' | gcc -E -xc - | tail -n 1

오늘날 출생 시간은 거의 유용하지 않습니다. 이는 파일에 있는 데이터의 수명이 아닙니다(데이터가 파일에 기록되었습니다).뒤쪽에생성된 경우), 파일이 해당 이름의 디렉터리에 나타날 때도 반드시 그런 것은 아닙니다(다른 이름으로 생성되어 이름이 바뀌거나 링크되었을 수 있으며 그 사이에 내용이나 속성이 여러 번 변경되었을 수도 있습니다).

^{1 특별한 경우로 ext4의 경우 파일 시스템이 128바이트의 inode 크기로 생성되면 생성 시간 필드가 포함되지 않습니다.}

Answer