christos%astron.com@localhost (Christos Zoulas) writes: > In article <201010212331.o9LNVw8o001610%ginseng.xisop@localhost>, > Matthew Mondor <mm_lists%pulsar-zone.net@localhost> wrote: >>On Thu, 21 Oct 2010 16:02:19 -0400 >>Greg Troxel <gdt%ir.bbn.com@localhost> wrote: >> >>> Therefore I think that nbmakefs, at least running on i386, has some >>> lossage when getting over 2G. Has anyone else seen this, or know how to >>> fix? >> >>I didn't look very long, but it seems to me that using fseek(3) to seek >>instead of fseeko(3) (or lseek(2) and avoiding stdio) in >>src/usr.sbin/makefs/cd9660/cd9660_write.c might be the cause (on i386, >>the offset would then be a signed 32-bit value (long int) which would >>indeed have a limit around 2GB... > > Well, I made a few simple changes to use fseeko... Maybe it needs more > loving, but it could work. Thanks - I grabbed those changes and tried them. They helped a lot, because I got a failure on fseeko right away. In cd9660_compute_offsets, there are a bunch of variables that are ints, plus return value and 2nd arg, plus the totalSpace variable farther up. I am trying to see if that's sufficient, but I think between your commit and changing to int64_t that things are ok for a ~2.5G iso image. Also, our man page for fseeko says return value is nonzero for error, but posix http://www.opengroup.org/onlinepubs/9699919799/functions/fseek.html says it must be -1. If that's what we do we should should adjust the docs. Thanks to Richard Hansen for pointing this out to me.
Attachment:
pgpYJfimNlffI.pgp
Description: PGP signature