Webサーバーにダウンロード用に大きなファイルを置いているとき、

書き込みではなくダウンロードであれば、問題はありません。最悪、転送が中断されます。

クライアント側の実装によって、リトライするか、中断するか決まると思います。

http1.1以上のサーバ／クライアントであれば壊れたファイルをダウンロードするということはありません。

http1.1でダウンロードする場合、Content-MD5リクエスト／応答ヘッダでファイルが通信途中で改変されていないかを確認します。クライアントがContent-MD5を得て、受信したファイルを検証し、不正であった場合、そこからリトライするか、中断するかは実装によると思います。

すみません、上ではいい加減なことを言ってました。

実際に試しました。

今、試しにFirefox3.6.16と、wget1.10.2でやってみました。

Firefoxでは、リトライせず、ダウンロード途中で中断しました。

中断されたファイルは、クライアントに残っていました。

wget1.10.2(Mac OS X 10.6.7)は、ファイル前半は上書き前の内容、ファイル後半は上書き後の内容になっていました。

ですので、クライアントによっては、ファイル内容が改変されてしまうことがわかりました。

というわけで、webサーバを停止し、ファイルを上書きするのが間違いないと思われます。

上記実験の手順：

サーバ側

$ dd if=/dev/zero of=./100M bs=1024 count=1000000

$ echo a > a

$ cat a 100M a> a100a

$ echo b > b

$ cat b 100M b> b100b

クライアントでa100aのダウンロード開始

真ん中あたりまでダウンロードする。

$ cp b100b a100a

クライアント側で、以下を実行

$ tail a100a

(確認の結果、末尾の1バイトはbになっているので、改変されたことになる。）

どのような手順でダウンロードさせているのか分かりませんが、ふつうはダウンロードファイルにロックがかかっていますから、差し替えることはできません。

サーバーを止めても止めなくても、クライアント側のダウンロードのレジュームの動作とは無関係です。

＞ダウンロード失敗時の自動リトライ（？）の実装について説明のあるサイトなどがありましたら教えていただけると

＞助かります。

＞Firefoxでは、リトライせず、ダウンロード途中で中断しました。

＞wget1.10.2(Mac OS X 10.6.7)は、ファイル前半は上書き前の内容、ファイル後半は上書き後の内容になっていました。

差し替えた後、どちらの動作になってほしいのか疑問ですが

通常は、差し替えられたらレジュームは無効にして、１からダウンロードするように実装するのが妥当だと思います。

そういう意味では前者のほうがまとも、

クライアントがサーバーから A というファイルをダウンロード中、

サーバーにて A というファイルが B というファイルに差し変わった際、

サーバーでは B というファイルに対してロックがかかるため読み出せない状況になります。

そのためクライアントのダウンロードは停止します。

もし上書き後の B というファイルが ファイル A と同じサイズであれば、クライアントは

ただ単に切断されたものと判断してレジュームでダウンロード済み以降の部分のダウンロードを試みます。

ファイルサイズが変わっていれば、ちゃんとしたダウンロードソフトなどであれば、ダウンロードしてる

ファイルのタイムスタンプやサイズが変わった時点でダウンロードは停止するはずです。

もし A と B が同じサイズて、ダウンロードが継続されてしまったファイルは A と B が混ざった状態のものになるため、

正常なファイルとはなりません。

もし何らかのデータファイルの更新をお考えであれば、新しいデータファイルを別のファイル名で公開した方が良いです。