我正在尝试使用 wget 下载流媒体 mp3。这是我的基本命令：
wget http://sj128.hnux.com/sj128.mp3 -c --timeout=1 --waitretry=0 --tries=0 -O "file.mp3"
我一直在脚本中执行此操作（让它运行 1 小时），但我令人恼火地发现我的文件最终会被截断且不完整。例如，我预计文件大小约为 30MB，但实际大小仅为 13MB 左右。
我不明白发生了什么，直到我直接从 CLI 运行这个命令，并发现最终我总是遇到“读取超时”。这不应该成为一个阻碍。 -c 和无限重试应该可以很好地处理这个问题。
但相反，在“读取超时”和新的重试之后，即使下载继续，我的文件也会停止增长。
为什么下载继续但文件没有按预期继续增长？我甚至创建了一个精心设计的脚本，该脚本在完全不同的文件名下启动了一个全新的 wget 以避免“文件”类型的冲突，即使所有输出显示了一个完全不同的文件名和一个全新的进程，它仍然没有写新文件！
在这种情况下，为什么下载似乎已开始，而我的新文件甚至没有显示！？
答案1
这是实时流。 “恢复”的整个概念并不适用，因为既没有开始也没有任何固定的位置可以恢复。您只需获取当前流式传输的任何数据即可。
但wget不知道这一点。网络故障后，恢复尝试如下所示：
wget知道文件有多大。如果服务器支持断点续传，wget会要求从源文件中间断点续传；但服务器端没有这个文件，服务器不支持断点续传，这种方法失败。- 尝试恢复失败，因此
wget认为它收到了相同的数据从一开始就。它会丢弃数据，直到丢弃的数量达到旧文件大小。然后它开始将新数据附加到文件中。这是您的文件开始增长的时刻。
实际上，当连接出现问题时，您不仅会错过流的某些片段；还会错过流的某些片段。您还会错过原本可以保存的数据，只是因为wget假设它第二次收到相同的数据。
为了克服这个问题，请启动（并根据需要继续重新启动）以下操作：
wget http://sj128.hnux.com/sj128.mp3 -O - >> "file.mp3"
（如果您愿意，还可以提供其他选项）。收到的任何内容wget都将附加到文件中。如果您错过了流的某些片段，则生成的文件显然会存储“粉碎”的内容。在我的测试中，VLC 在播放此类文件时没有出现技术问题。
注意：您可以随时使用 .txt 文件将文件截断至零大小: > file.mp3。即使wget正在运行，这也会起作用，因为>>总是寻找给定文件的末尾（请参阅这）。
wget在完全不同的文件名下开始一个全新的文件以避免“文件”类型的冲突，并且[...]它仍然没有写入新文件！
无法重现。我的wget确实写了一个新文件。
答案2
由于没有更好的事情可做，我在游戏中花费了雇主的一些带宽。
您尝试下载的文件超过 230MiB。这就是我关闭它之前的情况。
另一端的下载速度被限制为 15kBps，因此，如果您使用的是“不稳定”连接（正如您所看到的那样），则该连接将是去下降。
当wget尝试恢复时，另一端的服务器似乎不支持恢复，因此wget只是返回到开头并重新启动。
这完全是预期的行为。在一定条件下从man页面获取wget。
Note that -c only works with FTP servers and with HTTP servers that support the
"Range" header.
文件不会变大，因为
您的连接每隔（我猜，30,000MiB / 15kBps）=半小时后就会断开
wget每次连接断开时都必须从文件的开头开始。您的文件管理器只会看到上次使用的最大值并报告该大小，同时wget简单地从头开始逐步覆盖原始文件，直到您的连接断开......再次......再次......并且......
运行wget10秒，停止，然后运行20秒。在第二次运行时，一旦下载的大小超过之前的大小，您将看到文件大小再次增加。
尽管没有具体记录-c（至少我找不到），但这种行为在某些条件下是预期的。阅读man wget有关的部分-nc