リモートサーバーから特定の数のファイルをダウンロードするように設計されたスクリプトがあります。私のサーバー上のデータベースのJSONソースであるため、24時間ごとに一度だけこれを実行できます。ファイルはGMTの真夜中にリモートサーバーで更新され、私のスクリプトはそれから1時間後に実行され、ファイルが正しく更新されたことを確認します。
問題は、132個のファイルのうち少なくとも20個以上のファイルのダウンロードに失敗することに気づくのに失敗しないと思うことです（200 OKと思われます）。 JSONなので、サイズは最大8KBです。 wget ログ・ファイルに以下が表示されます。
--2013-09-21 12:01:10-- http://services.runescape.com/m=itemdb_rs/api/graph/19227.json
Reusing existing connection to services.runescape.com:80.
HTTP request sent, awaiting response... 200 OK
Length: 0 [text/html]
Saving to: `./jsons/19227.json'
0K 0.00 =0s
2013-09-21 12:01:10 (0.00 B/s) - `./jsons/19227.json' saved [0/0]
これは言葉ではありません。失敗には韻や理由はありません。私は何度も再試行し、毎回同じファイルに失敗するのではなく、ランダムに0バイトのファイルに書きました。残念ながら、どこにもエラーがないため、エラーログに何も記録されません...
この場合、非破壊は重要ではありません。これらのファイルは24時間ごとに古いファイルになるため上書きされ、前日の「良いデータ」でも今日は「悪いデータ」になります。
ダウンロードする前にファイルサイズなどを確認するためにスクリプトを改善できる場所はありますか？私は自宅のMacで試してみましたが、最初に「スパイダーモード」を使用してMacにいることを確認しましたが、同じ結果が得られました。最も残念なことは、URLをブラウザに貼り付けるとJSON全体がロードされることです。とにかくwgetではHTTPエラーが発生しないため、「再試行」が役に立たないようです。
答え1
wgetデバッグスイッチをオンにして-d何が起こっているかを確認することもできます。
はい
$ wget -d http://services.runescape.com/m=itemdb_rs/api/graph/19227.json
DEBUG output created by Wget 1.12 on linux-gnu.
--2013-09-21 13:22:46-- http://services.runescape.com/m=itemdb_rs/api/graph/19227.json
Resolving services.runescape.com... 216.115.77.143, 8.26.16.145, 62.67.0.145, ...
Caching services.runescape.com => 216.115.77.143 8.26.16.145 62.67.0.145 64.94.237.145
Connecting to services.runescape.com|216.115.77.143|:80... connected.
Created socket 3.
Releasing 0x0000000000f251e0 (new refcount 1).
---request begin---
GET /m=itemdb_rs/api/graph/19227.json HTTP/1.0
Referer: http://www.google.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Host: services.runescape.com
Connection: Keep-Alive
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
---request end---
HTTP request sent, awaiting response...
---response begin---
HTTP/1.1 200 OK
Date: Sat, 21-Sep-2013 17:22:47 GMT
Server: JAGeX/3.1
Content-type: text/html; charset=ISO-8859-1
Content-Encoding: gzip
Cache-control: no-cache
Pragma: no-cache
Expires: Thu, 01-Jan-1970 00:00:00 GMT
Set-Cookie: settings=wwGlrZHF5gKN6D3mDdihco3oPeYN2KFybL9hUUFqOvk; version=1; path=/; domain=.runescape.com; Expires=Tue, 20-Sep-2016 17:22:47 GMT; Max-Age=94608000
Connection: Keep-alive
Content-length: 1668
---response end---
200 OK
cdm: 1 2 3 4 5 6 7 8
Stored cookie runescape.com -1 (ANY) / <permanent> <insecure> [expiry 2016-09-20 13:22:47] settings wwGlrZHF5gKN6D3mDdihco3oPeYN2KFybL9hUUFqOvk
Registered socket 3 for persistent reuse.
Length: 1668 (1.6K) [text/html]
Saving to: “19227.json”
100%[==============================================================================================================================>] 1,668 --.-K/s in 0.08s
2013-09-21 13:22:47 (21.4 KB/s) - “19227.json” saved [1668/1668]
答え2
ダウンロードする前にファイルサイズなどを確認するためにスクリプトを改善できる場所はありますか？
今後明らかに、サーバーはダウンロード要求に正しく応答できないため、ダウンロードする必要はありません。正しいファイルを返すか、HTTPエラーコードを返す必要がありますが、明らかにどちらも返しません。 HTTPリクエストを使用してリモートファイルサイズを確認できますが、HEADリモートファイルは正常ですが、転送がまだ失敗した場合は役に立ちません。GET
代わりに、スクリプトでループを使用してダウンロードしたいすべてのファイルを繰り返します。単一のwgetリクエストで各ファイルをダウンロードしたら、ダウンロードしたファイルのファイルサイズを確認してください。 0バイトファイルで、0バイトファイルであってはならないと確信している場合は、要求を繰り返します。もちろん、スクリプトが常に失敗し、潜在的に遅延する要求を無限に繰り返さないように、安全装置の制限を追加する必要があります（サーバーが要求の速度を制限し、意図的に失敗するようにする場合）。
答え3
ターゲットディレクトリから空のファイルを削除します。これが私がすることです。
wget -c -t 40 -O /path/to/dir/myfile1 wget
-c -t 40 -O /path/to/dir/myfile2
/path/to/dir 検索 -empty -type f -delete
...空のmyfileがすべて消えました。