まれにRC2104が発生する

Question

以下のようなシステムでクライアントPC上でVC++を利用していると、まれに(60回に1回程度)ビルド時にRC2104が出ることがあります。

---
【機器構成】
Domain Controller（DC) : Windows Server 2008
File Server(FS) : Asianux3 Server + Samba 3.2.1
Client PC : Windows Vista Bussiness SP1

DC --------L3SW----PC
FS ---------+

【Visual Studioバージョン】
Visual Studio 2008 Professional

【システム概要】
各PCはDCのドメインに加わっており、ユーザの移動プロファイルをFS上に置いています。FS上のフォルダを各ユーザがドライブにマップして、データ置き場にも使用しています。

【再現方法】
ユーザがPCにログオンし、VC++のプロジェクトをFS上の共有フォルダ上に作成します。例としてtestプロジェクトを生成したとします。ここで、ダイアログにボタンを配置→F7キーでビルド、を繰り返すと、約60回に1回程度の割合でRC2104のエラーが発生します。
このとき、resource.hとtest.rcのプロパティを見ると、resource.hの更新日時が1回前のビルド時のままになっています。つまり、最後に追加したボタンのリソース情報が、test.rcには追加されますが、resource.hには追加されないため、RC2104が発生します。

【今までの切り分け状況】

Sambaが怪しいのでは？
　・別サーバにSamba 3.5.4を入れて試したが再現。
　・DC上に共有フォルダを作成して試したが再現。
　→サーバのOSやH/Wには依存しないようです

Virus対策ソフトが怪しいのでは？
　・サーバ側はスケジュールスキャンのみ
　・PC側でVirus対策ソフトのプロセスを止めて試したが再現。
　→Virus対策ソフトも関係なさそうです

プロジェクトをローカルディスクに置くとどうなる？
　・200回試しても再現せず。

　→共有フォルダ上にプロジェクトを置いた場合のみ発生するようです

Visual StudioのSP1を当てたらどうか？
　・SP1を当てたVC++でも再現。
　→SP1の有無は関係なさそうです。

Answer 1

ビルド時のファイルアクセスは相当な頻度で発生していると思うので、
ビルド対象がネットワークドライブ上にある場合、ネットワークがらみの問題で
こう言った現象が発生する可能性はあると思います。

ネットワーク構成機器やネットワークの構成その物が原因で
アクセス時の制限等に引っかかっている可能性はないでしょうか。
ローカルディスク上にプロジェクトを置くのが一番安全でトラブルが起こりにくい
環境である事はご自身の検証でも既に出ているようです。
ネットワーク周りの環境まで含めてネットワーク越しのビルドが確実に
うまく行く環境を構築できるのであれば良いと思いますが、
事実上それはかなり難しい相談であるような気もします。

仮に他のPCの干渉が全く無く、同じHUBにサーバとクライアントPCのみが
接続された状態であったとしても上記のような現象が起こる確率が０とは言えない
のではと私は考えています。
多分、ビルド時のネットワークトラフィックは相当な物になっているのではないでしょうか。

---

解決した時は、参考になったレスポンスの所にある［回答としてマーク］ボタンをクリックしてスレッドを締めましょう。

Answer 2

確かに、現象発生時のパケットキャプチャデータを見ると、送信/受信共に約250packets/sec.でした。

端末が複数台あるとサーバ側の処理が追いつかない可能性もありそうですが、問題切り分けのために端末は1台のみ、L3SW(Layer 3 Switch)を単純なSwitching Hubに交換(PCのIPアドレスも変更)しても、やはり本現象が発生しました。

現象発生時のパケットキャプチャデータを解析したところ、ダイアログ上にボタンを1つ追加してビルドを実行すると、変更した内容を保持するためのテンポラリファイルと、元々のファイルを一時的にリネームするためのテンポラリファイルの２つを生成しています。

"~VC82B4.tmp" : 新 "resource.h" 用テンポラリファイル
"~VC82B5.tmp" : 旧 "resource.h" 用テンポラリファイル

 1. "~VC82B4.tmp" を作成
 2. "~VC82B5.tmp" を作成
 3. "~VC82B4.tmp" をclose
 4. "~VC82B4.tmp" をopen
 5. "~VC82B4.tmp" へclose時に削除する設定
 6. "~VC82B4.tmp" をclose(delete)
 7. "resource.h" の存在を確認
 8. "~VC82B4.tmp" をopen
 9. "~VC82B4.tmp" へ "resource.h" の内容を書き込み　<-- 新 "resource.h" になるはずのデータ
10. "~VC82B4.tmp" をclose
11. "~VC82B5.tmp" をclose
12. "~VC82B5.tmp" をopen
13. "~VC82B5.tmp" へclose時に削除する設定
14. "~VC82B5.tmp" をclose(delete)
15. "resource.h" の存在を確認
16. "resource.h" をclose
17. "resource.h" をopen
18. "resource.h" の属性(File Basic Info)を取得  <-- 前回ビルド時の時刻
19. "resource.h" をclose
20. "resource.h" を "~VC82B5.tmp" にリネーム
21. "resource.h" の存在を確認(存在しない)
22. "~VC82B4.tmp" をopen
23. "~VC82B4.tmp" の属性(File Basic Info)を取得  <-- 9.で書き込みを行った時刻
24. "resource.h" の存在を確認(存在しない)
25. "~VC82B4.tmp" をclose
26. "resource.h" の存在を確認(存在しない)
27. "~VC82B5.tmp" をopen
28. "~VC82B5.tmp" の属性(File Basic Info)を取得  <-- 前回ビルド時の時刻
29. "~VC82B5.tmp" をclose
30. "~VC82B5.tmp" を "resource.h" にリネーム      <-- 元の "resource.h" を選択している

ファイルの書き込み時刻の属性だけを見ると、"~VC82B4.tmp"を"resource.h"として使うべきところ、
30.で "~VC82B5.tmp"を"resource.h"として使うため、"resource.h"の中身が古いままとなり
問題が起きています。

Answer 3

ひとつ気づいた点があります。

本現象が発生する前兆らしき現象があります。ダイアログにボタンを配置→F7キーでビルドを繰り返していると、test.rcの保存ダイアログが出ることがあります。この保存ダイアログを、OKボタンまたはキャンセルボタンで閉じ、再度F7キーでビルドを行うときに、高い確率で本現象が発生します。

Answer 4

ネットワーク越しでなおかつ相手がSambaとなるとファイルの保存等がうまく動作しないケースがあるのではないでしょうか？
保存しようとして保存できなかった為に保存ダイアログがでているのではと言う気もします。

内容的にフォーラムでディスカッションするよりもMicrosoft Connectに投稿した方が良さそうな内容であるようにも思えます。

以前にトラブルが起きたのは相手がWindowsサーバーでしたが、どうしてもネットワークが間に入るとローカルのHDDほどの信頼性は
出ない様に感じています。エクスプローラーを使って大量のデータをネットワーク越しにコピーする時にデータの欠落が起こるケースも
ありますから、100%確実と言う線ではないような気もしますし。
（それでもコピーなら失敗したファイルを再度コピーすればリカバリー出来ますが）

ビルドのように読み書きが入り乱れて発生するようなケースではローカルHDD上で作業を行なうようにして
サーバーはマスターの置き場所と言うような使い方の方が安全なのではと思います。

---

解決した時は、参考になったレスポンスの所にある［回答としてマーク］ボタンをクリックしてスレッドを締めましょう。