From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <99100159-30FB-4811-87FD-7F960CA7F948@gmail.com> <3505d2a562248941e6bb66dbf15c7c86@ladd.quanstro.net> Date: Fri, 28 Jun 2013 12:50:27 -0500 Message-ID: From: Terry Wendt To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [9fans] plan9 iso image Topicbox-Message-UUID: 687d1600-ead8-11e9-9d60-3106f5b1d025 If its any help, when I select 9atom.nboot.iso within K3b to burn to disc, it reports the filesize as 360.9 MB but the declared volume size as 721.7 GB. Interesting. Terry. On Fri, Jun 28, 2013 at 12:43 PM, Gorka Guardiola wrote: > > > > On Fri, Jun 28, 2013 at 7:19 PM, erik quanstrom > wrote: >> >> > Wouldn't surprise me, but it seems to work for me. If anyone has a >> > more detailed explanation of what is wrong where, I'll take a look at >> > it. >> >> we're now writing the nwa to disk. this calculation appears to be >> incorrect. >> here's the check in cdfs: >> >> /* reconcile differing nwas */ >> if (aux->mmcnwa != nwa) { >> fprint(2, "%s: nwa from drive %,ld != computed nwa >> %,ld\n", >> argv0, aux->mmcnwa, nwa); >> fprint(2, "\tbe careful! assuming computed nwa\n"); >> /* the invisible track may still start at the old nwa. */ >> // aux->mmcnwa = nwa; >> } >> > > Maybe I am not understanding. We were talking about mkisofs which generates > an iso file. > This is cdfs check for the first writable block of the track, which has to > do with burning it. > An iso is burnt inside a track and is mostly independent from the details of > what tracks exist. > Terry downloaded the iso, and tried to burn it in linux. If something is > wrong it would be > in the iso file generated, which does not have to do anything with cdfs. > G. > >