Re: Calculating size of iso image
me > > You are aware that mkisofs does accept whole directories ?
> > It is not necessary to mention every single file.
Nick > Yes, but the algorithm for continuing the directory onto the next DVD
> is more complicated than simply writing one 'graft-point'ed pathspec
> entry for each file. I found that skipping writing the directories
> (but including their size) makes my program much simpler, with 166
> lines of code so far.
There was no -path-list with mkisofs when i started my project.
So i had no choice but to handle as few single file objects as
possible. About 1000 of them and the shell hit me with 'argument
list too long'.
Be sure to use -D with mkisofs or you will encounter a deep
directory relocation problem with long -graft-points paths.
Working : /deep_dir=/u/test/deep_dir
Failing : /deep_dir/1/2/3/4/5/6/7=/u/test/deep_dir/1/2/3/4/5/6/7
(at least in the range of cdrecord 1.9 to cdrtools-2.01a19, not
with very old versions ... which don't know -path-list, sigh.)
Problem is that i do not know what negative consequences might
arise from -D. At least with Linux, i did not notice any. (With
deep directories, that is. Other CD-ROM problems are obvious.)
Nick > I am using graft-points, which worked fine on most files, except for a
> few with long file names
> ...
> Is this a problem with a limitation on file name length in the
> Joliet/Rock Ridge/iso9660 file system(s)?
To quote from man mkisofs :
"The Joliet filenames are
specified in Unicode and each path component can be
up to 64 Unicode characters long"
I encountered various problems with -J and gave up using it.
It is not suitable for backup purposes when you have to expect
filenames unaware of Microsoft standards.
Oh. -joliet-long is new to me. I should read man mkisofs more often.
I already learned about -stream-media-size recently.
>From my experiences -R seems to be ok for backups.
If it gets tough, you should have a decent archive format like GNU-tar
or afio in reserve.
Have a nice day :)
Thomas
Reply to: