bug-xorriso
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-xorriso] xorriso : FAILURE : Image size 2244690s exceeds free s


From: Thomas Schmitt
Subject: Re: [Bug-xorriso] xorriso : FAILURE : Image size 2244690s exceeds free space on media -2036700157s
Date: Wed, 17 Aug 2011 08:18:23 +0200

Hi,

> I think the subject pretty much says it - I'm trying to write out to a very
> large disk array with ~4.5TB of free space.  I'm guessing this is a signed
> int wraparound problem,

Looks much like that.
I assume you experience this on Linux. In this case the number of bytes
is read 64 bit from statvfs(2). The number is then stored as 64 bit.
Before writing it is divided by 2048 and stuffed into a signed 32 bit
integer, which then is compared against the predicted image size.


> are there any switches to skip the free space check
> or otherwise get me past this?

You may hide the target by writing to a pipe.

  xorriso -outdev - ... | cat >target_image.iso

But this will only work for single session or with explicitely obtained
Next-Writable-Address numbers as is tradition with mkisofs+cdrecord.


I am currently exploring how to deal better with such a size.
(Will have to fake 4.5 TB of capacity as my disk is only 500 GB.)
As soon as i have a test candidate, i will upload a development tarball
of GNU xorriso and ask you to try it.

One brute-force candidate would be to curb media capacities to 2 TB - 2 kB
already when they are read from the system.
If you have the source code of your xorriso at hand, you may try this
code change:

--- xorriso-1.1.4/libburn/sg-linux.c  2011-07-07 13:50:04.000000000 +0200
+++ xorriso-1.1.5/libburn/sg-linux.c  2011-08-17 08:08:36.000000000 +0200
@@ -1929,6 +1929,8 @@ int burn_os_stdio_capacity(char *path, o
                *bytes = add_size + ((off_t) vfsbuf.f_frsize) *
                                                (off_t) vfsbuf.f_bavail;
        }
+       if (*bytes / (off_t) 2048 > (off_t) 0x7fffffff)
+               *bytes = ((off_t) 0x7fffffff) * (off_t) 2048;
        ret = 1;
 ex:;
        BURN_FREE_MEM(testpath);

It would be interesting to know whether this shows any inconsistencies
with your disk array.


Have a nice day :)

Thomas




reply via email to

[Prev in Thread] Current Thread [Next in Thread]