From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: Date: Thu, 5 Apr 2007 11:13:00 -0400 From: "Russ Cox" To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu> Subject: Re: [9fans] 2 newbe questions of a general nature In-Reply-To: <5d375e920704042029o3c001e41r1f37c745f734939c@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1175569922.581801.306120@o5g2000hsb.googlegroups.com> <975d409a6767038bfd7ab37948d58dea@coraid.com> <5d375e920704042029o3c001e41r1f37c745f734939c@mail.gmail.com> Topicbox-Message-UUID: 3e16c146-ead2-11e9-9d60-3106f5b1d025 > Would be nice if the BL overlords could avoid this, maybe by moving > the previous day ISO before the new one takes its place, similar to > how replica moves foo to _foo. It already does that (maybe the overlords aren't as dumb as you think). But if the HTTP download gets interrupted after a new file has been dropped in its place, a client retrying the HTTP request will see the new file. If your download is not interrupted, then it will get a consistent file. Even if you are getting interrupted, the CD is at most 100MB compressed, which is only 5 hours at 56kbps, so you've got plenty of time to grab it in the 24-hour window. Further, I doubt very much that this is the cause of people with broken ISO images. You can't get that far if you get half of one download and half of another. They're compressed, and the checksum will fail during decompression even if the web browser doesn't notice that the file changed in the second request. So you'd end up with a broken .bz2 file, not a broken image. If you ever get to a .iso file, it will be intact. Russ