From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <5d375e920704050919p461da87ci123855f250c4dd4b@mail.gmail.com> Date: Thu, 5 Apr 2007 18:19:33 +0200 From: Uriel 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: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; 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: 3ddfe748-ead2-11e9-9d60-3106f5b1d025 Ok, then I guess I was wrong. Maybe a solution to quanstrom's problem would be to use file names based on the creation date (one would only need to keep one or two around). uriel On 4/5/07, Russ Cox wrote: > > 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 >