Re: [Bug-xorriso] xorriso : FAILURE : Image size 2244690s exceeds free space on media -2036700157s

[Thomas Schmitt]

Hi,

> libisofs: FATAL : Cannot convert name '.catalog' to ASCII
> libisofs: FATAL : Memory allocation error

This seems to be another problem.

> It also doesn't appear to be dependent on where I'm sending the
> output.

The reason must be a failed malloc() in libisofs/util.c functions
str2ascii() or str2wchar().


> It doesn't do it on linux, only Solaris (sparc), at least for the
> same source directory.

I recently worked on this because my Solaris installation has no
character set "WCHAR_T" which is normally used as intermediate conversion
step from the local character set to ASCII and UTF-16.
  
http://bazaar.launchpad.net/~libburnia-team/libisofs/scdbackup/revision/892/libisofs/util.c

Does your Solaris have character set "WCHAR_T" ? (Probably not)
  iconv -l | grep WCHAR_T

How many files does your image have ?
Would it be plausible that the sum of their name lengths multiplied by 3
could cause a memory exhaustion if there is a memory leak in libisofs ?

The suspicous change is yet only in the development version.
Could you please make tests with the development version 1.1.5 and the
released version 1.1.4 to a target that does not trigger the filesystem
size bug ?
E.g.
  xorriso -outdev - -add ...evil.directory... | cat >/dev/null

(1.1.4 will be unable to produce a Joliet tree if "WCHAR_T" is not
 available. So do not use options -joliet "on" or -as mkisofs -J.)
If only 1.1.5 fails then my new workaround for "WCHAR_T" is to blame.

I will examine the code change in question and make tests on Solaris
with large directory trees.


Have a nice day :)

Thomas