SSH를 통해 대학 Linux 서버(RHEL 7)에 연결하고 있습니다. 내 문제는 "ls" 및 "old" 파일과 관련이 있습니다.
메인 디렉토리:
$ touch -d '1918-11-11 11:00 GMT' wwi-armistice
$ touch now
$ sleep 1
$ touch now1
$ TZ=UTC0 ls -lt --full-time wwi-armistice now now1
-rw-r--r-- 1 tsai csugrad 0 2054-12-17 17:28:16.000000000 +0000 wwi-armistice
-rw-r--r-- 1 tsai csugrad 0 2018-05-04 22:07:10.743637000 +0000 now1
-rw-r--r-- 1 tsai csugrad 0 2018-05-04 22:06:59.992632000 +0000 now
임시 디렉터리:
$ tmp=$(mktemp -d)
$ cd $tmp
$ touch -d '1918-11-11 11:00 GMT' wwi-armistice
$ touch now
$ sleep 1
$ touch now1
$ TZ=UTC0 ls -lt --full-time wwi-armistice now now1
-rw-r--r-- 1 tsai csugrad 0 2018-05-04 23:04:27.031485854 +0000 now1
-rw-r--r-- 1 tsai csugrad 0 2018-05-04 23:04:22.907373125 +0000 now
-rw-r--r-- 1 tsai csugrad 0 1918-11-11 11:00:00.000000000 +0000 wwi-armistice
나는 2054년 세계 대전 휴전의 이유가 Unix 시간의 부호 있는 32비트에서 부호 없는 32비트로의 변환과 관련이 있음을 보여주는 첫 번째 출력을 알고 있습니다. 누군가 이것을 확인하고 그 이유(네트워크 관련?)를 설명할 수 있다면 좋을 것입니다.
두 번째 더 큰 질문은: /tmp에서 예제를 실행할 때 왜 wwi-armistice가 올바르게 나열됩니까?
답변1
실행 중인 운영 체제로는 동작 차이의 근본 원인을 식별할 수 없습니다. 파일 액세스 및 수정 시간을 저장하는 데 사용되는 파일 시스템도 마찬가지로 중요합니다.
추측할 수 있듯이 잘못된 2054-12-17 날짜는 대상 날짜가 부호 없는 32비트 정수로 기록되었지만 부호 있는 32비트 정수로 읽혀졌기 때문입니다.
1918-11-11 11:00:00=154193400032비트 최소 부호 없는 시간1901-12-13 08:45:52이후의 초 ( )2054-12-17 17:28:16=154193400032비트 최대 서명 시간 이후의 초(2038-01-19 03:14:16)
홈 디렉토리는 NFSv3 또는 이러한 날짜를 32비트로 저장하는 로컬 파일 시스템에 저장될 수 있습니다.
반면에 64비트로 날짜를 저장하는 모든 파일 시스템에서 지원되므로 /tmp이 문제의 영향을 받지 않습니다.tmpfsext4