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