延續IIS的FTP會區分大小寫，導致FtpFindFirstFile比對檔案失敗，在解決掉檔案名稱大小寫的問題之後，
又發生了詭異的現象，那就是抓取FtpFindFirstFile的修改時間時，傳回的時間居然整整少掉一年，
例如實際的時間為2009/6/5 14:23:40 傳回的時間會是 2008/6/5 14:23:40....
而導致比對時間錯誤，當然也就不會更新了~
如果你也跟我一樣利用 FTP來達成程式自動更新的話，你應該關注一下這一篇文章~
延續IIS的FTP會區分大小寫，導致FtpFindFirstFile比對檔案失敗，在解決掉檔案名稱大小寫的問題之後，又發生了詭異的現象，
那就是抓取FtpFindFirstFile的修改時間時，傳回的時間居然整整少掉一年，而且有的電腦會發生，有的則不會...
例如實際的時間為 2009/6/5 14:23:40 傳回的時間會是 2008/6/5 14:23:40....而導致比對時間錯誤，當然也就不會更新了~
google了很多資料，討論算冷門的，且討論也沒啥結果( 跟往常一樣，大陸的討論區反而比較多資料...)
其中有人討論到是因為GMT轉換後因為日光節約，微軟的bug導致年份減1，而我也認為應該是api出了問題。
而在過8小時後，就會恢復抓取到正常的年份，也就是說隔天就會恢復正常，這或許也是沒這麼多人發現問題的一個原因，
再次搜尋微軟的網站，我找到篇KB http://support.microsoft.com/kb/284455/zh-tw，確定的確是Wininet.dll的問題，
文章中提到只要Wininet.dll更新到5.0.3301.1500就可以解決，
而Wininet.dll是伴隨著IE升級而升級，意即透過IE的更新，就可以解決這個Bug
這也說明了為什麼有的電腦更新正常，有的電腦卻不正常的問題，
但是我用戶的環境，證實更新了IE後問題還是存在，只有更新到特定的IE版本之後，才會正常。
感覺有點像是到了IE7，一開始還是漏掉，更新後問題就解決，到了IE8應該是沒漏掉了...科科
| Wininet.dll版本 | 瀏覽器版本 | 抓取時間 |
| 6.00.2900.5764 | IE6(未升級Sp1) | 錯誤 |
| 7.0.5730.13 | IE7 | 錯誤 |
| 7.0.6000.16827 | IE7 | 正常 |
| 8.00.6001.18702 | IE8 | 正常 |
而另一篇KB也有提到http://support.microsoft.com/kb/173054/zh-tw，可以透過設定Ftp Server的時區，
取消自動調整日光節約，可能也可以達成，但是這部分我就沒去測試了，因為我們電腦都是加入網域，
而就我所知電腦時間是會與AD同步的，且時間不同步好像會造成某些問題，所以我就懶的去試了，
所以我的結論是，API的Bug會逐漸被解決的(隨著IE更新)，目前的做法是傾向不修改程式了(像是判斷年份+1之類的)，
如果是重度User的話，則請他更新IE版本，不然就是等隔天更新了~雖然不是解決問題的好辦法，
但問題出在微軟，你也只能遷就了~哈
不過至少了解了整個事情的緣由，希望對後面的搜尋者，會有幫助。
