Anyone else noticed this? It looks like mkisofs has a 2GB max file size limit - it will not write files that size. This means you can't write a DVD iso image, either! This seems like a serious limitation.
Maybe I've misunderstood, though? $ growisofs -Z /dev/dvdrw -quiet -J -T -R -V 0.1.00 -r . Executing 'mkisofs -quiet -J -T -R -V 0.1.00 -r . | builtin_dd of=/dev/dvdrw obs=32k seek=0' mkisofs: Value too large for defined data type. File ./cpio-bkp is too large - ignoring The same thing happens if I try -udf instead of -J and/or -R. $ find /usr/include/ -type f -print | xargs grep "Value too large for defined data type" /usr/include/asm/errno.h:#define EOVERFLOW 75 /* Value too large for defined data type */ Also, when it does, this, growisofs does not return an error exit code, it returns 0, as if it were successful. (So backups fail without being detected.) $ growisofs --version * growisofs by <[EMAIL PROTECTED]>, version 5.14, front-ending to mkisofs: mkisofs 2.0.3 (i686-pc-linux-gnu) The file I'm trying to write is a 4GB cpio file, for backups. This is under Linux kernel 2.4.23. The workaround I used was to copy the files for backup to a separate area, rather than storing them in a cpio archive. This does mean you can only fit about 3.9GB of files on a 4.7GB disc (guess ext3 is a more compact format than ISO9660), plus you're not guaranteed to be able to store all ownership. permission, etc. info. Changing over to use DVDs for backups was an interesting exercise. I learned about the strtoul() function, and realised that 4.7GB > 2^32, so had to limit my backup calculations to MAXINT. (I guess a better fix would be to reduce the precision of my units from bytes to 1kB blocks.) The thing that's going to push everyone to 64 bit platforms is storage media, I reckon. luke -- SLUG - Sydney Linux User's Group - http://slug.org.au/ More Info: http://lists.slug.org.au/listinfo/slug
