Windows 7文件問題

我正在使用VB6 SP6 此代碼已正常工作多年，但我現在在WIN7到WIN7網絡上有問題。它也可以在XP到Win7網絡上正常工作。Windows 7文件問題

Open file for random as ChannelNum LEN =90 
'the file is on the other computer on the network 

RecNum = (LOF(ChannelNum) \ 90) + 2 

Put ChannelNum, RecNum, MyAcFile 
'(MyAcFile is UDT that is less than 90 long) 

.......... other code that does not reference file or RecNum - then 

RecNum = (LOF(ChannelNum) \ 90) + 2 
Put ChannelNum, RecNum, MyAcFile 
Close ChannelNum

第二條記錄覆蓋第一條記錄。

我們在過去使用了OpportunisticLocking類似的問題，所以我們在安裝時將其關閉 - 以及一些導致Windows網絡中數據錯誤的其他鍵。

但是我們多年來一直沒有這樣的問題，所以我認爲MS有一些新的「更好」的選擇，他們認爲這將「改善」網絡。

感謝您的幫助

來源

2009-11-28 user5127767

嗯......是的文件（根據在公開聲明的代碼示例的頂部）UNC文件名或類似X：\其中x是映射驅動器？你沒有遞增RecNum？根據代碼判斷，RecNum沒有變化，因此似乎覆蓋了第一條記錄...對不起，因爲聽起來呃，沒有雙關語......基本......這將有助於在這裏展示更多的代碼......

希望這會有所幫助，最好的問候，湯姆。

來源

2009-11-28 00:41:16 t0mm13b

LOF（）應該返回文件的大小，所以RecNum *將*在該代碼段中更改。 – paxdiablo 2009-11-28 00:48:54

@paxdiablo：好吧，剛剛查了一下LOF（）做了什麼，感謝這些團長... @ rickdick69：有什麼東西是鎖定在文件的某個地方，這會阻止你的程序進一步寫入第二條記錄。跛行我知道...有一個程序，你可以使用這個稱爲解鎖在這裏@ http://ccollomb.free.fr/unlocker/。希望這會有更多的幫助。 – t0mm13b 2009-11-28 00:56:24

沒有它鎖定，因爲它寫入正確。 LOF只是沒有返回正確的長度我會欺騙代碼並關閉文件並重新打開它 - 但我真的想知道有什麼不同。 – user5127767 2009-11-28 02:36:14

它可能只是計時問題。在一些運行中，你的LOF（）函數返回比其他運行更多的更新信息。文件系統API是異步的，例如，當調用某個寫入函數時，它不會立即反映爲增加的大小。

簡而言之：你的代碼表明一箇舊的錯誤，這是隻是更容易複製在Windows 7

修復bug最便宜的方法：你可以決定加入延遲（也可以是顯著延遲比如說5秒）。

更詳細的修復方法是通過關閉並重新打開文件來強制更新大小。

來源

2009-11-28 01:00:34

正如我所說 - 我們已經處理了Windows文件的奇怪行爲與OpportunisticLocking等變化，我們已經有多年沒有問題這個代碼每天執行100,000次沒有錯誤。正如我所說，即使從XP到Win7，它也能正常工作添加延遲將比關閉和重新打開要慢，但我們沒有這樣做，因爲它減慢了代碼的速度，除Win7以外，它完美地工作到Win7 我覺得有東西新的MS爲Win7添加了這個問題 – user5127767 2009-11-28 02:34:31

我懷疑這裏除了你的方法有什麼「bug」。 LOF（）詢問的文件元數據並不意味着通過簡單寫入立即更新。延遲似乎是一個愚蠢的想法，容易偶爾發生故障，除非使用很長的延遲，並且充其量只會影響性能。即使關閉/重新打開也是如此：VB6的Close語句是異步操作。這就是爲什麼Reset statement存在。

這也是爲什麼在API級別存在類似FlushFileBuffers()和SetEndOfFile()的原因。從性能角度來看，它們也是相對昂貴的操作。

自己追蹤記錄。在第一次打開文件後，只有在必要時才依靠LOF（）。

來源

2009-11-28 16:47:59 Bob77

Windows 7文件問題

回答

相關問題