Windows 또는 Linux에서 실행되는 Java의 변경 사항을 파일에서 모니터링하려고합니다.File.lastModified 값이 항상 증가합니까?
현재 API 차이점을 부드럽게 처리하고 비동기 이벤트를 처리하지 않으려 고 OS 파일 이벤트에 연결하는 대신 파일의 마지막으로 수정 된 속성을 폴링합니다.
파일을 처리하고 lastModified 개 결과를 각각 x 초로 비교하면 결과는 new File("path").lastModified()입니다.
파울 플레이가 없으며 수동으로 타임 스탬프를 수정하는 사람이 있다고 가정해도 lastModified는 항상 증가 할 것입니까? 자바 문서는 그리니치 표준시 (GMT)에서 상쇄되었으므로 시간대 조정을하더라도 뒤로 이동하지 않을 것이라고 예상 할 수 있습니까?
당신은 시간이 NTP 같은 것을 사용하여 해결되면, 그것은 거꾸로 갈 수 http://unixhelp.ed.ac.uk/CGI/man-cgi?touch
아무것도
에 파일의 타임 스탬프를 변경할 수 있습니다.
이러한 상황은 드문 경우이며 걱정할 필요가없는 내용 일 수 있습니다.
흠, 클럭이 거꾸로 건너 뛰는 경우 (NTP 수정 드리프트와 같은 것에서) Java File.lastModified가이를 수정할 수 없습니까? – ICR
글쎄 가끔 lastModified가 증가하지 않습니다. , 옙 (NTFS에 대한
100 ns입니다
FAT의 (FAT32, FAT16, FAT12)는 2 second 시간 해상도를 가지고 : 그것은 시간 해상도에 대한 모든이며, 해상도는 각 파일 시스템에 다른 나노초)1 second. 파일이 빠르게 변경됩니다 경우그래서, lastModified은 변경되지 않습니다, 그리고 모니터은 일부 변경 내용이 손실 될 수 있습니다.
이는 당신이 (FAT32와 NTFS 같은) 다른 파일 시스템 이이 다를 자신의 lastModified 시간에 같은 파일이있는 경우로 인해 서로 다른 시간 해상도도 매우 까다 롭습니다. 지금은 그게 아니기 때문에 가짜 파일 변경에 반응하는 것일 수도 있습니다.은 NTFS 시간과 다른 1 시간을 반환하는 것일뿐입니다. 웹 서버에서도 마찬가지입니다. 서버 파일 시스템을 모르는 경우 HTTP 헤더에있는 값의 시간 분석이 무엇인지 알 수 없습니다.
해결 방법 해결 방법은 저장된 값과 FS 값의 차이가 3-4 초 미만인 경우 파일이 변경되지 않는다고 가정하는 것입니다. 서버에서 새 버전의 JAR 파일을 확인할 때 그 점이 WebStart입니다.
아마도 WebStart는 상대적으로 자주 수행하지 않기 때문에 파일을 읽고, 해시하고 비교할 수 있습니까? 너무 비싸다. – ICR
"다른 출처에서 마지막으로 수정 한 시간을 얻은 경우"라는 의미는 100 % 확실하지 않습니다. File.lastModified()를 사용하여 비교하고 마지막으로 수정 한 시간을 읽습니다. – ICR
1. Webstart는 간단한 HTTP에서 파일을 다운로드합니다. 따라서 서버 측에서 해시를 계산할 방법이 없습니다. 2. NTFS 파일 시스템에 파일이 있고 FAT32 파일 시스템에 해당 파일의 복사본이있는 경우 'lastModified'시간은 시간 해상도가 다르기 때문에 달라질 수 있습니다. 대답을 업데이트하여 명확하게 만듭니다. – npe
일반적으로 시간 이동 영역에서도 좋습니다. –
'파울이 없다'거나 '타임 스탬프를 수동으로 수정하는'사람이 없다고 생각합니다. 또한 CPU 클럭이 뒤로 설정되지 않는다고 가정 할 수 없습니다. DST가 끝나면 적어도 일 년에 한 번 발생합니다. 파일이 한 시간 내에 두 번 수정되는 경우에도 이전보다 59 분 59 초 더 오래 나타날 수 있습니다. – EJP
@EJP : 일광 절약 시간제는 단지 시간대 문제 일 뿐이므로 OP만으로도 Date의 실제 값 (이 경우 타임 스탬프)이 뒤로 이동하지 않게됩니다 (다르게 형식이 지정됨). –