mkisofs and UDF.
Hello,
A lot of files/directories I want to burn have a very long names, which makes
both Rock Ridge and Joilet an unsuitable file system for them. It seems that
UDF, though, allows longer file/directory names, but mkisofs's manpage says that
UDF support is only in alpha status, and there are many pitfalls with the
current implementation. What does that actually means from user's perspective -
does that means that one day CDs/DVDs which were burnt from images made by
mkisofs with '-udf' option on may become unreadable, that data can become
corrupted more easily or something equally bad?
Also, I use mkisofs both on Windows (available from here:
http://smithii.com/?q=node/view/9) and on Debian, but it seems that there is
a lot of difference between them, though this is the same version: for example,
under Windows, if some files are too long even for UDF, I get a warning:
"mkisofs: File name too long. Non-existent or inaccessible...", but under Linux
everything is done without warnings, and the violating files are quietly
excluded from the resulting image (at least they are not visible when image is
mounted as UDF filesystem). Also, under Windows, an empty image takes up ~1Mb,
while under Linux it is ~38Mb. Why there is such a difference, and what can be
done to eliminate it?
And the last question - what are exactly UDF's file/directory name length
restrictions? It seems that the restriction is on the length of a whole path,
where a maximum path length is around 256 chars, and if that restriction is
exceeded, the violating element is removed. But I couldn't figure out an exact
limits of those restrictions (and couldn't find it spelled out clearly on the
Net) - for example, if there is such a path (under Windows) "C:\directory\file",
what is counted as a char? Are ':' or '\' counted as 1? what about 'C'? And how
that counting differs when Linux's path length is computed?
Daniel.
Reply to: