File.lastModified值會一直增加嗎？

我正在試圖監視文件以查找在Windows或Linux上運行的Java中的更改。File.lastModified值會一直增加嗎？

目前我正在研究輪詢文件的最後修改的屬性，而不是掛鉤到OS文件事件中，以避免處理平滑API差異和處理異步事件。

一旦我處理完文件並比較新的lastModified結果，每x秒，我就會保存new File("path").lastModified()的結果。

我可以依靠的事實是，假設沒有犯規和有人手動修改時間戳，lastModified會一直增加嗎？ Java文檔說它是GMT時代的一個偏移量，所以假設它即使在時區調整後也不會倒退？

來源

2012-06-21 ICR

通常情況下，即使在時移區域中也是如此。 –

我不明白你怎麼可以假設'沒有犯規'，也沒有人'手動修改時間戳'。您也不能假定CPU時鐘從不倒退：在DST結束時，它至少每年發生一次。如果文件在一小時內修改兩次，甚至可能比以前更長59分59秒。 – EJP

@EJP：夏令時僅僅是一個時區問題，而且OP是正確的，僅憑這一點就不會導致日期的實際值（或在這種情況下是時間戳）向後（僅以不同的格式）。 –

您可以將文件的時間戳改變任何東西

http://unixhelp.ed.ac.uk/CGI/man-cgi?touch

如果時間可以用下面的NTP糾正，它可以倒着走。

這些情況很少見，也可能不是您需要擔心的事情。

來源

2012-06-21 13:07:08

嗯，大概如果時鐘向後跳過（從類似NTP糾正漂移的東西）Java的File.lastModified是不會能夠糾正這一點？ – ICR

那麼，有時候，lastModified不會增加。它是所有關於時間分辨率和分辨率爲每個文件系統不同：

所有FAT S（FAT32，FAT16，FAT12）有2 second時間分辨率，
爲NTFS是100 ns（是的，毫微秒）
對於大多數* nixes其1 second。

所以，如果您的文件將迅速改變，lastModified不會改變，你的顯示器可能會失去一些變化。

這也是非常棘手，因爲如果你有不同的文件系統（如FAT32和NTFS）的lastModified時間將不同相同的文件，由於不同的時間分辨率。現在因爲這樣，你可能會對虛假文件變化作出反應，這並沒有發生 - 這只是FAT32返回的時間與NTFS時間不同。 Web服務器也是這種情況 - 如果您不知道服務器文件系統，那麼您不知道HTTP Header中的值的時間分辨率是多少。

解決方法是假設文件沒有變化，如果存儲值和FS值之間的差異小於3-4秒。這就是WebStart在服務器上檢查JAR文件的新版本時所要做的。

來源

2012-06-21 12:33:07 npe

據推測，WebStart能夠負擔得起讀取，散列和比較文件，因爲它相對較少？這可能太昂貴了。 – ICR

我不是100％確定你的意思是「如果你從其他來源獲得上次修改時間」。我正在閱讀上次修改時間，我正在使用File.lastModified（）進行比較並存儲它。 – ICR

1. Webstart從簡單的HTTP下載文件。所以沒有辦法在服務器端計算散列。 2.如果你在NTFS文件系統上有一個文件，並且在FAT32文件系統上有該文件的副本，則由於時間分辨率不同，「lastModified」時間可能會有所不同，我會更新答案以使其更清晰。 – npe

File.lastModified值會一直增加嗎？

回答

相關問題