cdrkit vs. dvd+rw-tools and the dvd iso 4gb max filesize problem
CeDeROM
Simple and tricky question - who can burn a 4.4GB file to a DVD+/-R
disk on his FreeBSD? ;-)
I am wondering why FreeBSD still uses obsolete dvd+rw-tools package by
default instead of cdrkit. The main disadvantage of the dvd+rw-tools
is that it is based on a mkisofs and so it cannot write files larger
than 4GB to a DVD/Bluray disks (the same is for creating iso images).
Due to some licensing problems [1] cdrtools project split up and
cdrkit with genisoimage came to the light.
After over an hour of googling it turned out that this is the filesize
>4GB is a limitation of ISO9660 itself, that could be bypassed with
some 3rd level extensions of ISO but disk burned this way using
brasero did not contain any files after mount (and it was burned only
to the halt looking with at the disk). The only solution to burn disks
without max filesize limit is to use UDF filesystem, that can be
generated with genisoimage from cdrkit - and this is what I did and it
gave me working dvd disk with one file size over 4GB (#pkg_add -rf
cdrkit; %genisoimage -o- -udf -allow-limited-size * | wodim -v
dev=1,0,0 -dao tsize=2288962s - )...
Why do I ask about cdrtools? Because they seems to be still a source
of dependencies to the system:
# pkg_delete -x cdrtools
pkg_delete: package 'cdrtools-2.01_7' is required by these other
packages
and may not be deinstalled:
dvd+rw-tools-7.1
brasero-2.26.3_1
rhythmbox-0.12.5
gnome2-fifth-toe-2.26.3_1
sound-juicer-2.26.1_1
gnome2-2.26.3
tkdvd-4.0.9_2
Does anyone have experience with this kind of project forking and its
further implications? Would it be safe to switch default for cdrkit? I
could not find any clear solution to this problem on the net, while it
looks that moving from cdrtools to cdrkit is the working one..
Best regards,
Tomek
Bill Laird
A wee bit off real topic but:
One may also wonder why UDF media (produced by default under Windows Vista/
7) is rejected by photo processing shops (Australia). Even if they use
Windows XP a simple and free UDF reader is available but we still get
people in wanting media converted to standard ISO9660
Perhaps many, like FreeBSD find "obsolite" ISO adequate.
Personally have no need/ desire for massive files...
A small Linux distro I've used since 2007 still defaults to KDE 3.5 though
4.x is available, still has much the same software aboard but now takes at
least three times longer to start than does windows 7 or FreeBSD on the
same system. The 'popular' do it all distros take even longer.
FreeBSD 8 has come a long way - USB devices etc.
Well done considering the somewhat smaller development team.
Never mind I do rave on at times...
--
Bill
FreeBSD 8.0 on Intel Atom N280
'The road less travelled'
Clemens Zauner
> I am wondering why FreeBSD still uses obsolete dvd+rw-tools package by
In which way 'obsolete'?
> default instead of cdrkit. The main disadvantage of the dvd+rw-tools
> is that it is based on a mkisofs and so it cannot write files larger
You mean ISO-Images, right?
> than 4GB to a DVD/Bluray disks (the same is for creating iso images).
> Due to some licensing problems [1] cdrtools project split up and
> cdrkit with genisoimage came to the light.
I assume, that the 'licensing problem' (h�mhm, those gnu guys are
fans of Newspeak, aren't they?) are of minor concerns to FreeBSD.
Compare some parts of the FreeBSD-Kernel, as lets say ZFS.
> After over an hour of googling it turned out that this is the filesize
>>4GB is a limitation of ISO9660 itself, that could be bypassed with
correct. To be precise a limitation of ISO 9660 Level 1 and Level 2
images.
> some 3rd level extensions of ISO but disk burned this way using
> brasero did not contain any files after mount (and it was burned only
> to the halt looking with at the disk). The only solution to burn disks
> without max filesize limit is to use UDF filesystem, that can be
from 'man mkisofs':
-udf Include UDF support in the generated filesystem image. [...]
and if you use a sector size of 2k you should be able to generate iso-images
upto 8TB (using Level 3).
> Does anyone have experience with this kind of project forking and its
> further implications? Would it be safe to switch default for cdrkit? I
> could not find any clear solution to this problem on the net, while it
> looks that moving from cdrtools to cdrkit is the working one..
Nope, but a year ago I was forced t use the cdrkit-stuff under debian
and ended up copying the files to my laptop and burning there (under
FreeBSD). Maybe the cdrkit-guys have fixed some of the observed minor
issues since then.
HTH
Clemens.
--
/"\ http://czauner.onlineloop.com/
\ / ASCII RIBBON CAMPAIGN
X AGAINST HTML MAIL
/ \ AND POSTINGS
Joerg Schilling
CeDeROM <tomek...@gmail.com> wrote:
>Simple and tricky question - who can burn a 4.4GB file to a DVD+/-R
>disk on his FreeBSD? ;-)
Everybody who uses a halfway recent cdrtools can do this, see:
ftp://ftp.berlios.de/pub/cdrecord/alpha/
http://cdrecord.berlios.de/
mkisofs added support for files >= 4 GB in Summer 2006.
>I am wondering why FreeBSD still uses obsolete dvd+rw-tools package by
>default instead of cdrkit. The main disadvantage of the dvd+rw-tools
Let me first answer your original question on a technical base:
genisoimage (found in cdrkit) does not support files >= 4 gb.
While an original mkisofs from > 5 years (this is what genisoimage is
based on) warns about large files, this warning has just been removed
from the fork "genisoimage". As a result, files >= 4 GB will not appear
correctly on a medium that was created by genisoimage.
Please do not advertize for an illegal buggy and dead fork from cdrtools.
Cdrkit was created by a hostile downstream packaging maintainer. This
person soon (in December 2006) modified the source in a way that makes
cdrkit be in conflict with GPL and Copyright law. Cdrkit cannot be
legally distributed - well this is not a problem as cdrkit is completely
unmaintained since May 6th 2007 and as cdrkit misses tons of features that
are available in the original software since many years.
>is that it is based on a mkisofs and so it cannot write files larger
>than 4GB to a DVD/Bluray disks (the same is for creating iso images).
>Due to some licensing problems [1] cdrtools project split up and
>cdrkit with genisoimage came to the light.
While genisoimage cannot handle files >= 4 gb correctly and while genisoimage
does not handle an UTF-8 coded locale correctly, mkisofs correctly deals
with files up to 8 TB and correctly handles UTF-8.
There is absolutely no license problem with the original software and
this has been verified by several lawyers. I mentioned already that
cdrkit cannot be distributed legally.
>After over an hour of googling it turned out that this is the filesize
>>4GB is a limitation of ISO9660 itself, that could be bypassed with
This is wrong, there is no 4 GB limitation in ISO-9660.
Note that you need to specify "mkisofs -isolevel 3 ..." or a higher level
as ISO-9660 filesystems with a level below 3 are not allowed to carry
files >= 4 GB.
>generated with genisoimage from cdrkit - and this is what I did and it
>gave me working dvd disk with one file size over 4GB (#pkg_add -rf
>cdrkit; %genisoimage -o- -udf -allow-limited-size * | wodim -v
>dev=1,0,0 -dao tsize=2288962s - )...
This is of course wrong. As mentioned above, cdrkit does not support
files >= 4 GB and in addition is full of bugs that cause buggy ISO-9660
and UDF filesystems. You definitely don't want to have a filesystem
with the bugs that appear in the filesystem when you use genisoimage.
Also note that in three weeks, we are celebrating 12 years of DVD
support in the original cdrecord (cdrecord was one of the very first
programs to write DVDs). The DVD support in cdrecord has been added
when less than 40 DVD writers existed on earth..
Note: "wodim" did remove the mature DVD support from cdrecord and replaced
it with something half baken that is full of bugs. Wodim is unable
to deal with DVD+RW and with DVD+R/DL, there are plenty well known bugs
with DVDs in general. Wodim does e.g. still not implement the -atip
option for DVD media. Cdrecord added this code in early February 1998.
BTW: The results from the -atip request are needed to parameterize
the DVD write process...
>Does anyone have experience with this kind of project forking and its
>further implications? Would it be safe to switch default for cdrkit? I
>could not find any clear solution to this problem on the net, while it
>looks that moving from cdrtools to cdrkit is the working one..
You just mentioned how you switch from a working solution (based on original
software) with no known bugs to a (fork based) solution that is virtually
unusable.
Cdrkit is a dead fork created by a hostile Packaging maintainer.
This person did even add plenty of bugs that never have been in the
original software. This person permanently igores the demands and problems
of the people who use his fork...
The OSS community works around this person and the original project
did add a lot of interesiting new features and bug fixes.
The original software is constantly under active development.....
--
EMail:jo...@schily.isdn.cs.tu-berlin.de (home) J�rg Schilling D-13353 Berlin
j...@cs.tu-berlin.de (uni)
joerg.s...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
Joerg Schilling
Clemens Zauner <cz+u...@onlineloop.com> wrote:
>Nope, but a year ago I was forced t use the cdrkit-stuff under debian
>and ended up copying the files to my laptop and burning there (under
>FreeBSD). Maybe the cdrkit-guys have fixed some of the observed minor
>issues since then.
From what I noticed, it seems that there have been a few single char
typo fixes in the man page and in comments ;-)
CeDeROM
Now I can understand that the problem is with the cdrkit, not the
cdrtools, and the cdrkit is the obsolete and a dead end of this fork.
Please forgive me but I could not find it explictly on the net! :-)
The reason of my questioning is that genisoimage did the job while
mkisofs did not... however now I know that is was not done right,
with a trick, so I forget about cdrkit, but I still need support with
burning large files on FreeBSD...
The tricks people offer at places like ubuntuforums are really funny -
to split that file into pieces, then burn, and concatenate them after
mount. I don't really believe there is no working solution to burn DVD
disks with one-file-size over 4GB.
I have used brasero to burn my dvd disk with file over 4GB in size -
it did use iso level 3 but the disk did not work after all (it seemded
to be only half baked looking at the bottom side).
Running mkisofs by hand with switches that you have proposed does not
work:
%mkisofs -iso-level 3 -o ../dvd.iso *
mkisofs: Value too large to be stored in data type. File blah.xyz is
too large - ignoring
Total translation table size: 0
Total rockridge attributes bytes: 0
Total directory bytes: 0
Path table size(bytes): 10
Max brk space used 31b84
174 extents written (0 MB)
%mkisofs -udf -o ../dvd.iso *
mkisofs: Value too large to be stored in data type. File blah.xyz is
too large - ignoring
Total translation table size: 0
Total rockridge attributes bytes: 0
Total directory bytes: 0
Path table size(bytes): 10
Max brk space used 31b84
417 extents written (0 MB)
Clemens Zauner: The -udf does not work
Joerg Schilling: I can see only -iso-level switch (not -isolevel) but
is does not work neither.
I am using version 2.01 provided with 8.0 release binaries.
%mkisofs -version
mkisofs 2.01 (i386-unknown-freebsd8.0)
There is only one file under the star... I dont think also that the
problem could be caused by a file larger than a disk capacity, because
I do not burn at this level , only create an iso file.. so it could be
used by a double layer dvd (8GB) or bluray (even more that is too much
for me anyway).
Please advise,
Tomek
Joerg Schilling
CeDeROM <tomek...@gmail.com> wrote:
>Hello all and at first thank you for explaining patiently!
>Now I can understand that the problem is with the cdrkit, not the
>cdrtools, and the cdrkit is the obsolete and a dead end of this fork.
>Please forgive me but I could not find it explictly on the net! :-)
>The reason of my questioning is that genisoimage did the job while
>mkisofs did not... however now I know that is was not done right,
>with a trick, so I forget about cdrkit, but I still need support with
>burning large files on FreeBSD...
Well, I am not sure whether FreeBSD includes support for files > 4 GB.
I recommend you to first make a test with a recent mkisofs and a
file block device emulation. Use a recent mkisofs, the current version
is 2.01.01a72.
>Running mkisofs by hand with switches that you have proposed does not
>work:
>
>%mkisofs -iso-level 3 -o ../dvd.iso *
>mkisofs: Value too large to be stored in data type. File blah.xyz is
>too large - ignoring
This is obviously an old version...
>Clemens Zauner: The -udf does not work
>Joerg Schilling: I can see only -iso-level switch (not -isolevel) but
>is does not work neither.
>
>I am using version 2.01 provided with 8.0 release binaries.
>%mkisofs -version
>mkisofs 2.01 (i386-unknown-freebsd8.0)
I have no idea why FreeBSD ships a 5.5 year old version.
I am currently working on the 73th release of cdrtools past the version
you are using. I guess that you don't like to use a FreBSD version
from september 2004 ;-)
>There is only one file under the star... I dont think also that the
>problem could be caused by a file larger than a disk capacity, because
>I do not burn at this level , only create an iso file.. so it could be
>used by a double layer dvd (8GB) or bluray (even more that is too much
>for me anyway).
For dual layer, I recommend cdrecord and DVD+R/DL (for all other DVDs
I recommend DVD- instead of DVD+).
Warren Block
[...]
> I am using version 2.01 provided with 8.0 release binaries.
> %mkisofs -version
> mkisofs 2.01 (i386-unknown-freebsd8.0)
That would be sysutils/cdrtools from ports. The most recent version is
called cdrtools-devel, currently 2.01.01a72.
--
Warren Block * Rapid City, South Dakota * USA
CeDeROM
It is nice to talk with author/coder directly! :-)
On 15 Sty, 00:39, j...@cs.tu-berlin.de (Joerg Schilling) wrote:
> (...)
> Well, I am not sure whether FreeBSD includes support for files > 4 GB.
Sure it does! Actually, I am working from a multisystem partition
using ext2fs :-)
> I recommend you to first make a test with a recent mkisofs and a
> file block device emulation. Use a recent mkisofs, the current version
> is 2.01.01a72.
Ugh, don't get mad plz, but that is really an ugly name - so many dots
ended with a suffix and a number :\
I think its high time to finally make the 2.01.2 or even 2.02
release! ;-)
> >I am using version 2.01 provided with 8.0 release binaries.
> >%mkisofs -version
> >mkisofs 2.01 (i386-unknown-freebsd8.0)
>
> I have no idea why FreeBSD ships a 5.5 year old version.
> I am currently working on the 73th release of cdrtools past the version
> you are using. I guess that you don't like to use a FreBSD version
> from september 2004 ;-)
From what I've found in the cdrtools (freshly updated) port tree
Makefile:
PORTNAME= cdrtools
PORTVERSION?= 2.01
PORTREVISION?= 7
CATEGORIES?= sysutils audio
MASTER_SITES= ftp://ftp.berlios.de/pub/cdrecord/ \
ftp://ftp.cs.tu-berlin.de/pub/misc/cdrecord/
DISTNAME= cdrtools-2.01
It looks like, as you said, FreeBSD use really outdated package of
cdrtools. I think this is caused by the strange naming convention, and
probably because there was no 2.02 release yet, noone updated the port/
Makefile. So my statement about "obsolete dvd+rw-tools" that is a
cdrtools frontend, was somehow right :-( I will try to inform the port
maintainer about this situation.
Joerg, do you think it is possible for you to release 2.02 (or 2.2.2)
cdrtools package, or even make more frequent minor releases instead of
keeping the alpha status? I think this would dramatically improve port
maintaining and issue tracking in situations/pitfalls like I've felt
into... You know - when googling around - it would be obvious then to
know that 2.01 was a 2006 release (or even 2004) and now I have
2.32.23 release that is far more powerful :-)
> For dual layer, I recommend cdrecord and DVD+R/DL (for all other DVDs
> I recommend DVD- instead of DVD+).
Ah, so the minus gets the priority - also very useful information!
Once again great thank you for your support! :-)
Tomek
CeDeROM
On 15 Sty, 01:19, Warren Block <wbl...@wonkity.com> wrote:
> > I am using version 2.01 provided with 8.0 release binaries.
> > %mkisofs -version
> > mkisofs 2.01 (i386-unknown-freebsd8.0)
>
> That would be sysutils/cdrtools from ports. The most recent version is
> called cdrtools-devel, currently 2.01.01a72.
Ugh, I think this could become a default... but somehow you are right
- alpha means devel :\
Maybe there would be a new release of cdrtools soon :-)
Best regards,
Tomek
CeDeROM
OK I can confirm that with cdrtools-devel "-iso-level 3" switch,
creating images with one-file-size >4GB works corectly!
The "-udf" switch does not work.
%mkisofs -version
mkisofs 2.01.01a72 (i386-unknown-freebsd8.0) Copyright (C) 1993-1997
Eric Youngdale (C) 1997-2009 J�rg Schilling
%mkisofs -udf -o ../dvd.iso blah.xyz
mkisofs: Value too large to be stored in data type. File blah.xyz is
too large for current mkisofs settings - ignoring
Total translation table size: 0
Total rockridge attributes bytes: 0
Total directory bytes: 0
Path table size(bytes): 10
Max brk space used 0
417 extents written (0 MB)
%mkisofs -iso-level 3 -o ../dvd.iso blah.xyz
0.22% done, estimate finish Fri Jan 15 03:08:57 2010
0.44% done, estimate finish Fri Jan 15 03:12:45 2010
^C
Using the "-iso-level 3" switch also works with "growisofs" utility
and will probably work with brasero...
growisofs -iso-level 3 -Z /dev/cd1 -J -R -dvd-compat -r *
WARNING: /dev/cd1 already carries isofs!
About to execute 'mkisofs -iso-level 3 -J -R -r blah.xyz | builtin_dd
of=/dev/pass1 obs=32k seek=0'
0.22% done, estimate finish Fri Jan 15 02:56:26 2010
Best Regards! :-)
Tomek
Clemens Zauner
> OK I can confirm that with cdrtools-devel "-iso-level 3" switch,
> creating images with one-file-size >4GB works corectly!
> The "-udf" switch does not work.
Why?
> %mkisofs -udf -o ../dvd.iso blah.xyz
Ah yes. Surprisingly - did you also read the Part 'bout Level 3 Image
in my Post? As Joerg already gave you the option, what keeps you from
issuing:
mkisofs -iso-level 3 -udf [...]
> mkisofs: Value too large to be stored in data type. File blah.xyz is
> too large for current mkisofs settings - ignoring
'xactly.
> %mkisofs -iso-level 3 -o ../dvd.iso blah.xyz
> 0.22% done, estimate finish Fri Jan 15 03:08:57 2010
> 0.44% done, estimate finish Fri Jan 15 03:12:45 2010
This does not give you an udf - filesystem; in your post you asked about
udf. If you wand udf you need also the -udf switch.
cu
Clemens.
PS: under FreeBSD ports, mkisofs also comes with a man-page. It is as
bit lengthy (> 2k lines). But given you nick you should probably read
it. It provides a lot of information.
Joerg Schilling
In article <17e71436-57d4-4bdf...@g25g2000yqd.googlegroups.com> you write:
>On 15 Sty, 00:39, j...@cs.tu-berlin.de (Joerg Schilling) wrote:
>> (...)
>> Well, I am not sure whether FreeBSD includes support for files > 4 GB.
>
>Sure it does! Actually, I am working from a multisystem partition
>using ext2fs :-)
I am not talking about whether freebsd implements large file support
for ext2 but whether there is support for files > 4 GB in the iso-9660
kernel fs driver from FreeBSD. Did you check this?
>> I recommend you to first make a test with a recent mkisofs and a
>> file block device emulation. Use a recent mkisofs, the current version
>> is 2.01.01a72.
>
>Ugh, don't get mad plz, but that is really an ugly name - so many dots
>ended with a suffix and a number :\
>I think its high time to finally make the 2.01.2 or even 2.02
>release! ;-)
There was a one year pause in 2005 but in general, there is a new developer
version (better but not worse than the older releases) aprox. every 2-3 weeks.
Sometimes even every week (as now where we are approaching a new major release).
>From what I've found in the cdrtools (freshly updated) port tree
>Makefile:
>PORTNAME= cdrtools
>PORTVERSION?= 2.01
>PORTREVISION?= 7
>CATEGORIES?= sysutils audio
>MASTER_SITES= ftp://ftp.berlios.de/pub/cdrecord/ \
> ftp://ftp.cs.tu-berlin.de/pub/misc/cdrecord/
>DISTNAME= cdrtools-2.01
2.01 is from September 2004.
>Makefile. So my statement about "obsolete dvd+rw-tools" that is a
>cdrtools frontend, was somehow right :-( I will try to inform the port
>maintainer about this situation.
dvd+rw-tools is not a frontend to cdrtools but a frontend to mkisofs.
When dvd+rw-tools came up with DVD support, and note that it does still
not support CDs, cdrecord did already implement DVD support since three
years.
Joerg Schilling
CeDeROM <tomek...@gmail.com> wrote:
>On 15 Sty, 01:43, CeDeROM <tomek.ce...@gmail.com> wrote:
>> Hello Warren!
>>
>> On 15 Sty, 01:19, Warren Block <wbl...@wonkity.com> wrote:
>>
>> > > I am using version 2.01 provided with 8.0 release binaries.
>> > > %mkisofs -version
>> > > mkisofs 2.01 (i386-unknown-freebsd8.0)
>>
>on is
>> > called cdrtools-devel, currently 2.01.01a72.
>>
>> Ugh, I think this could become a default... but somehow you are right
>> - alpha means devel :\
>> Maybe there would be a new release of cdrtools soon :-)
>>
>> Best regards,
>> Tomek
>
>OK I can confirm that with cdrtools-devel "-iso-level 3" switch,
>creating images with one-file-size >4GB works corectly!
>The "-udf" switch does not work.
Why do you believe that -udf does not work?
>%mkisofs -version
>mkisofs 2.01.01a72 (i386-unknown-freebsd8.0) Copyright (C) 1993-1997
>Eric Youngdale (C) 1997-2009 J=EF=BF=BDrg Schilling
>
>%mkisofs -udf -o ../dvd.iso blah.xyz
>mkisofs: Value too large to be stored in data type. File blah.xyz is
>too large for current mkisofs settings - ignoring
Why do you believe this should work?
Mkisofs always creates ISO-9660 and if you like to include a specific file,
you need to make it appear on ISO-9660, even if you add a UDF hybrid.
Joerg Schilling
Clemens Zauner <cz+u...@onlineloop.com> wrote:
>> %mkisofs -iso-level 3 -o ../dvd.iso blah.xyz
>> 0.22% done, estimate finish Fri Jan 15 03:08:57 2010
>> 0.44% done, estimate finish Fri Jan 15 03:12:45 2010
>
>This does not give you an udf - filesystem; in your post you asked about
>udf. If you wand udf you need also the -udf switch.
Also, please note that "genisoimage -udf" does not create correct filesystems
if there are files > 4 GB. It just does not warn you about the problems.
Indi
>
> I am not talking about whether freebsd implements large file support
> for ext2 but whether there is support for files > 4 GB in the iso-9660
> kernel fs driver from FreeBSD. Did you check this?
>
I just mounted a 35GB iso image (created by mkisofs --iso-level 3) on md0,
so yes it works in FreeBSD 8.0 with the current cdrtools.
--
indi
CeDeROM
On 15 Sty, 09:33, Clemens Zauner <cz+use...@onlineloop.com> wrote:
> > > > some 3rd level extensions of ISO but disk burned this way using
> > > > brasero did not contain any files after mount (and it was burned only
> > > > to the halt looking with at the disk). The only solution to burn disks
> > > > without max filesize limit is to use UDF filesystem, that can be
> > >
> > > from 'man mkisofs':
> > >
> > > -udf Include UDF support in the generated filesystem image. [...]
> > >
> > > and if you use a sector size of 2k you should be able to generate iso-images
> > > upto 8TB (using Level 3).
Clemens, then it looks that UDF is not the only solution for burning
filesize >4GB, "-iso-level 3" is enough. If anyone want to create an
UDF filesystem HYBRID disk, then one should use "-udf -iso-level 3".
Please remember, and it is obvious at this point, that above works
only with cdrtools-devel, not default cdrtools package, what must be
mentioned for a person that will use these options. Any new user for
FreeBSD will propably use the default cdrtools package and wonder why
it does not work for files >4GB... and there is no information in the
Handboobk.
> PS: under FreeBSD ports, mkisofs also comes with a man-page. It is as
> bit lengthy (> 2k lines). But given you nick you should probably read
> it. It provides a lot of information.
It probably looks ubeliveable to you, but yes I've read it. There is
no information to combine "-udf" and "-iso-level 3". I have never
designed or prototyped an optical writer device, I am not a burning
software author - so what do I look in a manual (and other sources) is
a precise description, a working solution, not a half solution, or
general information. Let's take a look at cdrtools-devel's mkisofs
manual fragments:
-udf Rationalized UDF with user and group set to 0 and with
simpli-
fied permissions. See -r option for more information.
-r This is like the -R option, but file ownership and modes
are set
to more useful values. The uid and gid are set to zero,
because
they are usually only useful on the author's system,
and not
useful to the client. All the file read bits are set
true, so
that files and directories are globally readable on the
client.
If any execute bit is set for a file, set all of the
execute
bits, so that executables are globally executable on the
client.
If any search bit is set for a directory, set all of
the search
bits, so that directories are globally searchable on the
client.
All write bits are cleared, because the CD-Rom will be
mounted
read-only in any case. If any of the special mode bits
are set,
clear them, because file locks are not useful on a
read-only
file system, and set-id bits are not desirable for uid
0 or gid
0. When used on Win32, the execute bit is set on
all files.
This is a result of the lack of file permissions on
Win32 and
the Cygwin POSIX emulation layer. See also -
uid -gid,
-dir-mode, -file-mode and -new-dir-mode.
-iso-level level
Set the ISO-9660 conformance level. Valid numbers are
1..3 and
4.
With level 1, files may only consist of one section
and file-
names are restricted to 8.3 characters.
With level 2, files may only consist of one section.
With level 3, no restrictions (other than
ISO-9660:1988) do
apply. Starting with this level, mkisofs also allows
files to
be larger than 4 GB by implementing ISO-9660 multi-
extent files.
With all ISO-9660 levels from 1..3, all filenames are
restricted
to upper case letters, numbers and the underscore (_).
The maxi-
mum filename length is restricted to 31 characters,
the direc-
tory nesting level is restricted to 8 and the
maximum path
length is limited to 255 characters.
Level 4 officially does not exists but mkisofs
maps it to
ISO-9660:1999 which is ISO-9660 version 2.
With level 4, an enhanced volume descriptor with
version number
and file structure version number set to 2 is
emitted. There
may be more than 8 levels of directory nesting, there is
no need
for a file to contain a dot and the dot has no more
special
meaning, file names do not have version numbers, the
maximum
length for files and directory is raised to 207. If
Rock Ridge
is used, the maximum ISO-9660 name length is reduced to
197.
When creating Version 2 images, mkisofs emits an
enhanced volume
descriptor which looks similar to a primary volume
descriptor
but is slightly different. Be careful not to use broken
software
to make ISO-9660 images bootable by assuming a second
PVD copy
and patching this putative PVD copy into an El Torito
VD.
So there is no information that final product of the "-udf" switch is
a HYBRID ISO-9660/UDF product (is that correct?), no information that
"-udf" can be used with any of the ISO options, specificaly "-iso-
level 3". Manual is a document that pass proper information, not a
poetry to wonder what author had on mind. Please take a look at HFS
description:
-hfs Create an ISO-9660/HFS hybrid CD. This option should be
used in
conjunction with the -map, -magic and/or the various
double dash
options given below.
It clearly states that the product is and ISO-9660/HFS HYBRID, and
there are some remarks what other options SHOULD be used with tis
switch - and that looks clear to me :-)
Look, what I'm trying to do is to make things work - brasero and other
programs use oudtated cdrtools package, there is no information to use
cdrtools-devel (maybe this should be set system default in this
case?). Someone that just want to burn a disk, can think that
something is wrong with the FreeBSD system. On the other hand I did
not like such situations in Linux - that I have to know every detail
of the solution to make it work - this is sick and a waste of time,
because computer is a tool, not a goal itself. I like FreeBSD for its
high standard and usability, but searching one week for a clue just to
burn a disk is not the best way things should be - that's the Linux
way - and I want to save this time for next users that meet this
problem.
Best regards,
Tomek
CeDeROM
On 15 Sty, 16:41, j...@cs.tu-berlin.de (Joerg Schilling) wrote:
> >%mkisofs -udf -o ../dvd.iso blah.xyz
> >mkisofs: Value too large to be stored in data type. File blah.xyz is
> >too large for current mkisofs settings - ignoring
>
> Why do you believe this should work?
>
> Mkisofs always creates ISO-9660 and if you like to include a specific file,
> you need to make it appear on ISO-9660, even if you add a UDF hybrid.
Ah, for me it looked like different filesystem, an ISO alternative.
Right now I know that this is a hybrid. Do you think it is possible to
update "-udf" description to something like this:
-udf Create an ISO-9660/UDF rationalized hybrid with user and group
set to 0 and with simplified permissions. Rationalized means
that ..... . See -r option for more information on file permissions.
For large files (over 4GB per file) compatibility use also the "-iso-
level 3" switch. See -iso-level option for more information on
ISO-9660 level capabilities and limitations.
What does it mean "rationalized" in case of a filesystem?
Clemens Zauner mentioned in his post that "if you use a sector size of
2k you should be able to generate iso-images upto 8TB (using Level
3).", while looking at the mkisofs manual page this sector size can be
also specified by a "-s"/"-sectype" equal to data=2048, xa1=2056 (raw
is reserved for audio and should not be used with dvd/bluray). So what
is the default sector size? Isn't it 2048?
Because "-udf" switch creates an ISO/UDF hybrid, therefore all
limitations of ISO obey to the UDF..? This is why "-iso-level 3" must
be active? Where can I read more on how this kind of "hybrid" work? Is
it simply an UDF fileystem with file structure stored on an ISO
filesystem but some udf-specific features of the UDF are stored in a
hidden file - this way if OS does not recognise UDF it still can use
ISO data..? If so, why disks created with UDF (hybrid?) with windows
vista/7 (mkisofs -udf ???), as noted by Bill Laird, cannot be read
with OS that has no UDF support (ie. windows xp with no plugin/
software)?
Best regards,
Tomek
CeDeROM
On 15 Sty, 16:42, j...@cs.tu-berlin.de (Joerg Schilling) wrote:
> Also, please note that "genisoimage -udf" does not create correct filesystems
> if there are files > 4 GB. It just does not warn you about the problems.
There is a port named cdrkit in a FreeBSD port tree, but it is in
conflict with installed cdrecord (that is installed by default because
ports such as dvd+rw-utils, brasero, gnome2, etc needs this one), so
cdrkit is not the threat in this case until someone install it upon
him/hers will. The problem is that FreeBSD keeps the standard, and the
packages considered developer/unstable/alpha/beta are marked with
suffix "-devel". There has not been any release of the cdrtools for
over 5 years, so the stable package still uses the release from 2004.
It is possible to make all of the burning software depend on a "devel"
package, but this might break the system one day, and definitely will
break good standard of the FreeBSD and how things should be done in
there. Personally I think this standard is a great thing, and this was
the reason for me to switch from linux to bsd (although friend told me
that many many years ago).
I have passed this information to the documentation section of the
FreeBSD team and the port maintainer - the opinion is more or less as
I have stated above - it would be better to have stable port/package
using stable release sources. Do you know approximately when the
stable release can come to the light?
And finally - Joerg thank you for this wonderful piece of software and
for making it free and open! I have used cdrecord and mkisofs for the
first time around year 2000 on my Slackware box and the 12x LG CD-RW
drive that still works on my desktop - that was my first one-year-old
then PC after Amiga and the immortal Atari :-) :-) It is really nice
to be fully able to work over the internet on a free and open source
software, to share and learn from open minded people like you on this
group! Thank you all, not that many years ago it was yet
impossible! :-)
Best regars,
Tomek Cedro
Indi
Excuse me, I mean the current *cdrtools-devel*.
Also, building iso images containing files as large as 8GB has been no problem
here.
I do wonder though why cdrtools-devel hasn't become simply cdrtools yet.
I had to make a couple of coasters before trying the devel version. Normally
I expect devel will be unstable/buggy, but in this case the default
version is the buggy one. At least on my hardware.
--
indi
Google Groupers and X-posters are filtered. If you're not a troll
or a spammer then you might want to stop posting like one.
Indi
>
> Also, building iso images containing files as large as 8GB has been no problem
> here.
>
Woops --- no problem until I extract them!
It appeared I had made and burned an iso with an 8GB tar file in it,
upon closer inspection only 4GB actually went to disk but it went twice.
I got 2 duplicate (not split) 4GB archives on the disk.
So apparently writing files larger than 4GB is broken, even with cdrtools-devel.
How 1998...
CeDeROM
On 16 Sty, 17:54, Indi <i...@satcidananda.16x108.merseine.nu> wrote:
> Woops --- no problem until I extract them!
> It appeared I had made and burned an iso with an 8GB tar file in it,
> upon closer inspection only 4GB actually went to disk but it went twice.
> I got 2 duplicate (not split) 4GB archives on the disk.
I have the same problem! Have you tired "-udf" switch "-iso-level 3"
or both of them?
The problem is for "-iso-level 3" switch only, now I will try to use
both and share the results.
Best Regards,
Tomek
CeDeROM
> > Woops --- no problem until I extract them!
> both and share the results.
The original file is 4686887250 bytes long and has
5dea4dc0d18def1978235bb4c4201569 md5 sum.
The file created only with "-iso-level 3" switch is doubled and is
4294965248 bytes long and has 468f66d3d54eb06e7797106ce53a762b md5
sum.
The file created both with "-udf -iso-level 3" switches is, just as
above, also doubled and is 4294965248 bytes long and has
468f66d3d54eb06e7797106ce53a762b md5 sum.
All this was done with latest alpha version of cdrtools:
%mkisofs -version
mkisofs 2.01.01a72 (i386-unknown-freebsd8.0) Copyright (C) 1993-1997
Eric Youngdale (C) 1997-2009 J�rg Schilling
Joerg, how about that? You mentioned that genisoimage will produce
broken filesystem and hidden messages, while mkisofs also does not
produce correct data, or we still miss something :-(
Please advise,
Tomek
Indi
I used just the "--iso-level 3".
Unfortunately I'm out of DVDs right now (don't use them much), or I'd do
some experimenting.
Indi
> 5dea4dc0d18def1978235bb4c4201569 md5 sum.
>
> The file created only with "-iso-level 3" switch is doubled and is
> 4294965248 bytes long and has 468f66d3d54eb06e7797106ce53a762b md5
> sum.
>
> The file created both with "-udf -iso-level 3" switches is, just as
> above, also doubled and is 4294965248 bytes long and has
> 468f66d3d54eb06e7797106ce53a762b md5 sum.
>
> All this was done with latest alpha version of cdrtools:
> %mkisofs -version
> mkisofs 2.01.01a72 (i386-unknown-freebsd8.0) Copyright (C) 1993-1997
>
> Joerg, how about that? You mentioned that genisoimage will produce
> broken filesystem and hidden messages, while mkisofs also does not
> produce correct data, or we still miss something :-(
>
> Please advise,
> Tomek
Actually, I had read what he said about genisofs/cdrkit and found it a bit
odd, as ISTR using all that in Debian with fine results in the recent past...
BTW. cdrecord identifies my drive as "Generic mmc2 DVD-R/DVD-RW/DVD-RAM".
The machine is an intel mac mini core2duo 2GHz with "superdrive" (Pioneer
DVD-RW DVR-K06).
Media is Verbatin DVD+R DL. (rebooting into OS X I can burn without issues
on this media).
Tomek, I added a loophole to my scorefile to unblock you after seeing your
posts via someone else's replies (as I've done with five other posters here).
Cheers,
CeDeROM
On 16 Sty, 21:37, Indi <i...@satcidananda.16x108.merseine.nu> wrote:
> Tomek, I added a loophole to my scorefile to unblock you after seeing your
> posts via someone else's replies (as I've done with five other posters here).
What does that mean? I do post via google...
Well about the filesystems - I have checked the filesystem generated
with:
1. mkisofs -iso-level 3
-it contains malformed and doubled trucated files
-it does not mount as UDF (mount_udf: /dev/cd1: Invalid argument)
2. mkisofs -iso-level 3 -udf
-it contains malformed files as above when mounted as ISO9660
-it does mount as UDF (mount -t udf) and then contains one file, the
checksum is correct (5dea4dc0d18def1978235bb4c4201569, filesize
4686887250)
3. genisoimage -iso-level 3 -allow-limited-size
-without explicte giving the "-udf" parameter it can be mounted as UDF
filesystem and chekcsum of the large file seems to be correct
(5dea4dc0d18def1978235bb4c4201569, filesize 4686887250)
It looks that the only working combination of the new mkisofs is the "-
udf -iso-level 3" and then disk must be mounted as UDF, otherwise
large files will be doubled and truncated.
Can anyone confirm that?
Best regards,
Tomek
ps/2: Indi - you can use DVD+RW for experiments - this will save your
resources and the environment :-)
Indi
>
> On 16 Sty, 21:37, Indi <i...@satcidananda.16x108.merseine.nu> wrote:
>> Tomek, I added a loophole to my scorefile to unblock you after seeing your
>> posts via someone else's replies (as I've done with five other posters here).
>
> What does that mean? I do post via google...
>
Google Groups is a huge source of spam and trolling for a lot of usenet groups,
so awhile back I made the decision to block all posts coming from GG.
If someone posts with something worthwhile, someone else will reply and I'll
see that and then can make a loophole in my scorefile to allow that GG poster
through.
Lots of people do the same, you might want to look into getting a proper news
provider and use a newsreader. Some usenet providers are free (motzarella is one),
the one I use (individual.net) costs only 10 euros (about $14 U.S.) per year.
Check out http://twovoyagers.com/improve-usenet.org/ for more info if you like.
>
> Well about the filesystems - I have checked the filesystem generated
> with:
>
> 1. mkisofs -iso-level 3
> -it contains malformed and doubled trucated files
> -it does not mount as UDF (mount_udf: /dev/cd1: Invalid argument)
>
> 2. mkisofs -iso-level 3 -udf
> -it contains malformed files as above when mounted as ISO9660
> -it does mount as UDF (mount -t udf) and then contains one file, the
> checksum is correct (5dea4dc0d18def1978235bb4c4201569, filesize
> 4686887250)
>
> 3. genisoimage -iso-level 3 -allow-limited-size
> -without explicte giving the "-udf" parameter it can be mounted as UDF
> filesystem and chekcsum of the large file seems to be correct
> (5dea4dc0d18def1978235bb4c4201569, filesize 4686887250)
>
> It looks that the only working combination of the new mkisofs is the "-
> udf -iso-level 3" and then disk must be mounted as UDF, otherwise
> large files will be doubled and truncated.
>
> Can anyone confirm that?
>
So are you saying that using the -udf option with --iso-level 3 works fine,
so long as it's mounted udf? If so, that's very good to know.
> ps/2: Indi - you can use DVD+RW for experiments - this will save your
> resources and the environment :-)
>
ISTR concerns years back about DVD+-RW being less reliable.
Maybe they're better now?
Joerg Schilling
CeDeROM <tomek...@gmail.com> wrote:
>So there is no information that final product of the "-udf" switch is
>a HYBRID ISO-9660/UDF product (is that correct?), no information that
>"-udf" can be used with any of the ISO options, specificaly "-iso-
>level 3". Manual is a document that pass proper information, not a
>poetry to wonder what author had on mind. Please take a look at HFS
>description:
It seems that you did not read the beginning of the man page. It is
_very_ obvious about the fact that it creates hybrid filesystems.
Also the UDF description:
-UDF Include UDF support in the generated filesystem image.
UDF support is currently in alpha status and for this
reason, it is not possible to create UDF only images.
is very obvious..
BTW: I need to remove the remark about the alpha status ;-)
The support is mature since Spring 2007.
>Look, what I'm trying to do is to make things work - brasero and other
>programs use oudtated cdrtools package, there is no information to use
>cdrtools-devel (maybe this should be set system default in this
>case?). Someone that just want to burn a disk, can think that
>something is wrong with the FreeBSD system. On the other hand I did
>not like such situations in Linux - that I have to know every detail
The problem with programs like brasero that are developed on Linux is that
these programs are stuck to the features from 5 years ago because too
many Linux people believed that wodim is a successor of cdrecord although
wodim is just a dead end from an outdated version.
Joerg Schilling
CeDeROM <tomek...@gmail.com> wrote:
>> Mkisofs always creates ISO-9660 and if you like to include a specific file,
>> you need to make it appear on ISO-9660, even if you add a UDF hybrid.
>
>Ah, for me it looked like different filesystem, an ISO alternative.
>Right now I know that this is a hybrid. Do you think it is possible to
>update "-udf" description to something like this:
Why didn't you look at -UDF?
The first page from the man page as well as the -UDF description
should be obvious enough, isn't it?
>-udf Create an ISO-9660/UDF rationalized hybrid with user and group
>set to 0 and with simplified permissions. Rationalized means
>that ..... . See -r option for more information on file permissions.
>For large files (over 4GB per file) compatibility use also the "-iso-
>level 3" switch. See -iso-level option for more information on
>ISO-9660 level capabilities and limitations.
>
>What does it mean "rationalized" in case of a filesystem?
Did you read the -r description?
>Clemens Zauner mentioned in his post that "if you use a sector size of
>2k you should be able to generate iso-images upto 8TB (using Level
>3).", while looking at the mkisofs manual page this sector size can be
>also specified by a "-s"/"-sectype" equal to data=2048, xa1=2056 (raw
>is reserved for audio and should not be used with dvd/bluray). So what
>is the default sector size? Isn't it 2048?
xa sectors are used by e.g. Kodak Photo or Kodak Picture CDs.
>Because "-udf" switch creates an ISO/UDF hybrid, therefore all
>limitations of ISO obey to the UDF..? This is why "-iso-level 3" must
>be active? Where can I read more on how this kind of "hybrid" work? Is
Correct.
Did you read the first page of the man page?
>it simply an UDF fileystem with file structure stored on an ISO
>filesystem but some udf-specific features of the UDF are stored in a
>hidden file - this way if OS does not recognise UDF it still can use
>ISO data..? If so, why disks created with UDF (hybrid?) with windows
>vista/7 (mkisofs -udf ???), as noted by Bill Laird, cannot be read
>with OS that has no UDF support (ie. windows xp with no plugin/
>software)?
When writable DVDs have been introduced in 1997, most UNIX versions
did not support UDF and even on MS-WIN, UDF support was not really usable.
Mkisofs existed already and we did just add HFS hybrid support. It was
obvious to use the same approach for UDF.
Joerg Schilling
CeDeROM <tomek...@gmail.com> wrote:
>There is a port named cdrkit in a FreeBSD port tree, but it is in
>conflict with installed cdrecord (that is installed by default because
>ports such as dvd+rw-utils, brasero, gnome2, etc needs this one), so
>cdrkit is not the threat in this case until someone install it upon
>him/hers will. The problem is that FreeBSD keeps the standard, and the
>packages considered developer/unstable/alpha/beta are marked with
>suffix "-devel". There has not been any release of the cdrtools for
>over 5 years, so the stable package still uses the release from 2004.
A stable release is a release where at the time of publishing no known
bug exists. While there has not been a single stable "cdrkit" release as
long as it exists, there have been more than 60 stable cdrtools
releases since 2005.
The main rule for cdrtools (and all my software) is: With _very_ few
exceptions, every release is a stable release. For cdrtools, there have
been a few non-stable released in late 2006 when I replaced the buggy
GNU getopt_long() by my mature getargs(). This forced me to remove
more than 2000 lines of old code (specific to GNU getopt_long()) and
to write 1000 lines of new code. As this was done in a central area
of the code, there have been a few problems with the transition but
this was announced. Other - even bigger changes - could be omplemented
localy and thus did not affect older features.
Unless it has been explicitly announced, every newer release is better
than any older one....
>It is possible to make all of the burning software depend on a "devel"
>package, but this might break the system one day, and definitely will
>break good standard of the FreeBSD and how things should be done in
>there. Personally I think this standard is a great thing, and this was
>the reason for me to switch from linux to bsd (although friend told me
>that many many years ago).
What "standard" are you talking about? Are you talking about otehr
software that published bad beta releases?
>I have passed this information to the documentation section of the
>FreeBSD team and the port maintainer - the opinion is more or less as
>I have stated above - it would be better to have stable port/package
>using stable release sources. Do you know approximately when the
>stable release can come to the light?
As any of the current releases is better than all previous releases,
I don't see any reason to put pressure on a stable (== dead) release
to come out soon.
I was planning to publish cdrtools-3.0 in september 2009 but rewriting
the man pages took more time than I expected and I still have some open
points (e.g. some more experiments with BluRay and making BluRay support
better as well as adding support to copy or create audio CDs with a hidden
track before track 1). Note that audio Cds with hidden track may currently
only be copied with readcd -clone + cdrecord -clone and this does not result
in optimal audio quality.
Joerg Schilling
>On 2010-01-16, Indi <in...@satcidananda.16x108.merseine.nu> wrote:
>>
>> Also, building iso images containing files as large as 8GB has been no problem
>> here.
>>
>
>Woops --- no problem until I extract them!
>It appeared I had made and burned an iso with an 8GB tar file in it,
>upon closer inspection only 4GB actually went to disk but it went twice.
>I got 2 duplicate (not split) 4GB archives on the disk.
If this is true, then the FreeBSD kernel does not support large files.
The "trick" with the ISO-9660 standard is that it defines that lage files
have to be written as multi-extent files that have one directory entry per
extent. The filesystem driver in the kernel needs to hide this fact from the
users.
Joerg Schilling
CeDeROM <tomek...@gmail.com> wrote:
>All this was done with latest alpha version of cdrtools:
>%mkisofs -version
>mkisofs 2.01.01a72 (i386-unknown-freebsd8.0) Copyright (C) 1993-1997
>Eric Youngdale (C) 1997-2009 J=EF=BF=BDrg Schilling
>
>Joerg, how about that? You mentioned that genisoimage will produce
>broken filesystem and hidden messages, while mkisofs also does not
>produce correct data, or we still miss something :-(
mkisofs is correct.
Check the "isoinfo" command and call isoinfo -i filesys.ori -l
isoinfo first lists all directory entries as really presend and
as required by ISO-9660 and then finally a combined total.
Joerg Schilling
>On 2010-01-15, Indi <in...@16x108.merseine.nu> wrote:
>I do wonder though why cdrtools-devel hasn't become simply cdrtools yet.
>I had to make a couple of coasters before trying the devel version. Normally
>I expect devel will be unstable/buggy, but in this case the default
>version is the buggy one. At least on my hardware.
Well as mentioned later, the current mkisofs implements support for
large files while the current FreeBSD kernel does not seem to support
large files. It seems that the current FreeBSD kernel needs to be
called "alpha" for this reason ;-)
I am sure that if FreeBSD did deliver recent cdrtools versions by default,
the missing features in the kernel would have been detected much earlier.
Michel Talon
>
> The first page from the man page as well as the -UDF description
> should be obvious enough, isn't it?
>
Joerg,
cdrecord is a wonderful program, but, whatever you may think, and for
whatever reasons it is this way, the man page is a *catastrophe*, and i
try to be polite. You cannot expect people will read pages and pages of
stuff which don't make *any sense* except for experts, and users are not
experts. Of course you are not alone with man pages of this sort, i have
a headache each time i intend to use mplayer or mencoder. It is because
of such unreadable documentation (this is more or less the same of many
Unix man pages) that people use front ends like brasero or k3b, or run
inferior operating systems.
--
Michel TALON
Joerg Schilling
Michel Talon <ta...@lpthe.jussieu.fr> wrote:
>Joerg Schilling <j...@cs.tu-berlin.de> wrote:
>>
>> The first page from the man page as well as the -UDF description
>> should be obvious enough, isn't it?
>cdrecord is a wonderful program, but, whatever you may think, and for
>whatever reasons it is this way, the man page is a *catastrophe*, and i
>try to be polite. You cannot expect people will read pages and pages of
>stuff which don't make *any sense* except for experts, and users are not
>experts. Of course you are not alone with man pages of this sort, i have
>a headache each time i intend to use mplayer or mencoder. It is because
>of such unreadable documentation (this is more or less the same of many
>Unix man pages) that people use front ends like brasero or k3b, or run
>inferior operating systems.
Did you read a recent man page?
The man pages are constantly rewritten based on feedback from users,
so the man pages are as good as the feedback from users is.
If you still believe that there is a need to make it better, you are
invited to contribute!
CeDeROM
On 17 Sty, 13:06, j...@cs.tu-berlin.de (Joerg Schilling) wrote:
> It seems that you did not read the beginning of the man page. It is
> _very_ obvious about the fact that it creates hybrid filesystems.
Correct, at that point I have used the man page from the stable
(outdated) release. In a new manual page everything is clearly
explained abut the hybrids - however it might not be obvious at first
glance and the old manual. People that want to burn a disk don't have
to be experts in this area, just users, so they will probably open
manual, search for interesting option, and apply this option. The
manual should be written in a manner that allows easy search and apply
the information. The information should be also self explanatory and
it is possible in English, as the IC manufacturers ofthen do in their
technical documents... On the other hand I wouldn't ask you so many
questions if I could write my own software for my own optical writer.
> Also the UDF description:
>
> -UDF Include UDF support in the generated filesystem image.
> UDF support is currently in alpha status and for this
> reason, it is not possible to create UDF only images.
>
> BTW: I need to remove the remark about the alpha status ;-)
> The support is mature since Spring 2007.
The current release is still aplha. If the UDF support is not in alpha
anymore - is it possible to create UDF only images already?
> The problem with programs like brasero that are developed on Linux is that
> these programs are stuck to the features from 5 years ago because too
> many Linux people believed that wodim is a successor of cdrecord although
> wodim is just a dead end from an outdated version.
I think that making releases periodicaly can help in this situation -
people get confused like I did - with no additional details it is very
easy to think that way, especially when the other solution is working.
When there is no stable release in a project it might be considered
more "dead" than active project that make often releases with a bux
fixes. You can always keep your software alpha state because always
there will be something new to add. In this situation people search
for a working solution and if they find cdrkit that is confirmed by
some other people, they will use it and wait or even support it for
the next, better, releases.
The other thing is that as you said, programs like brasero are stuck
to the features from 5 years ago, because there was no STABLE release
of cdrtools since then. This is perfectly clear to me.
> Why didn't you look at -UDF?
>
> The first page from the man page as well as the -UDF description should be obvious enough, isn't it?
Yes, in the devel package (the alpha release) it is, but the default
for us is the outdated one, because it is the stable release, so it is
not that obvious :-(
> >What does it mean "rationalized" in case of a filesystem?
>
> Did you read the -r description?
Yes I have read that section, but explictily there is no information
that this means "rationalized" - please take a look - there is only
one search result for "rationalized" and one for "Rationalized", and
none of them resides in the "-r" description.
> A stable release is a release where at the time of publishing no known
> bug exists. While there has not been a single stable "cdrkit" release as
> long as it exists, there have been more than 60 stable cdrtools
> releases since 2005.
> (...)
> What "standard" are you talking about? Are you talking about otehr
> software that published bad beta releases?
> (...)
> As any of the current releases is better than all previous releases,
> I don't see any reason to put pressure on a stable (== dead) release
> to come out soon.
This situation is sick. Joerg, plese don't get me wrong but I start to
understand the creators of the cdrkit utiliy. If you say that there
have been more than 60 stable releases of "cdrtools" since 2005, why
the version is still 2.01 since September 2004??? What is more - you
convince us that there is no pressure on a stable release :-( :-(
> >Woops --- no problem until I extract them!
> >It appeared I had made and burned an iso with an 8GB tar file in it,
> >upon closer inspection only 4GB actually went to disk but it went twice.
> >I got 2 duplicate (not split) 4GB archives on the disk.
>
> If this is true, then the FreeBSD kernel does not support large files.
>
> The "trick" with the ISO-9660 standard is that it defines that lage files
> have to be written as multi-extent files that have one directory entry per
> extent. The filesystem driver in the kernel needs to hide this fact from the
> users.
> (..)
> Well as mentioned later, the current mkisofs implements support for
> large files while the current FreeBSD kernel does not seem to support
> large files. It seems that the current FreeBSD kernel needs to be
> called "alpha" for this reason ;-)
If you think that FreeBSD kernel needs to be called "alpha" for any
reason, you are invited to make improvements -it is still open under
very nice license for modifications.
> I am sure that if FreeBSD did deliver recent cdrtools versions by default,
> the missing features in the kernel would have been detected much earlier.
Joerg this is way to far and wrong conclusion. If you read the earlier
posts you could find that the filesystem created with "-udf -iso-level
3" works fine if mounted as the UDF filesystem, and this is probably
because if the filesystem is an ISO carrying some additional UDF data,
then it could be read as ISO and UDF, where only the UDF filesystem is
correct - that is why "-udf" switch was used to create the filesystem.
This is the logical standard that I was talking about - this is clear
to me, I like it.
Now I can understand why the cdrkit was born... you write more about
the errors of the concurent software instead of improving yours and
listening for a feedback. If you read our messages carefully you could
notice that we do like cdrtools and we try to help improve it as we
can by our feedback. You did not ask for any other support than
reading the manual. For me this is enough, I got tired by the subject,
I won't ask you for anything if that's what you want. Please just
notice that this attitude brings nothing good to the *nix world. Good
luck with your software.
Anyone knows any burning solution for unix other than cdrtools? This
surely can be a commercial one, I just want it to work.
Regards,
Tomek
Indi
> In article <7recpn...@mid.individual.net>, Indi <in...@127.0.0.1> wrote:
>>
>>Woops --- no problem until I extract them!
>>It appeared I had made and burned an iso with an 8GB tar file in it,
>>upon closer inspection only 4GB actually went to disk but it went twice.
>>I got 2 duplicate (not split) 4GB archives on the disk.
>
> If this is true, then the FreeBSD kernel does not support large files.
>
Do you mean to say FBSD's implementation of cd9660 doesn't support
large files? Because using mkisofs I seem to have a 4GB limit, but that
limit doesn't appear to exist with UFS2 or ext3 in FBSD.
Joerg Schilling
CeDeROM <tomek...@gmail.com> wrote:
>Joerg this is way to far and wrong conclusion. If you read the earlier
>posts you could find that the filesystem created with "-udf -iso-level
>3" works fine if mounted as the UDF filesystem, and this is probably
>because if the filesystem is an ISO carrying some additional UDF data,
>then it could be read as ISO and UDF, where only the UDF filesystem is
>correct - that is why "-udf" switch was used to create the filesystem.
>This is the logical standard that I was talking about - this is clear
>to me, I like it.
If I get you right, then you missunderstand the situation.
Mkisofs creates correct images, this includes ISO-9660 files > 4 GB.
If FreeBSD cannot deal with them, somebody needs to fix FreeBSD.
>Now I can understand why the cdrkit was born... you write more about
>the errors of the concurent software instead of improving yours and
>listening for a feedback. If you read our messages carefully you could
>notice that we do like cdrtools and we try to help improve it as we
>can by our feedback. You did not ask for any other support than
>reading the manual. For me this is enough, I got tired by the subject,
>I won't ask you for anything if that's what you want. Please just
>notice that this attitude brings nothing good to the *nix world. Good
>luck with your software.
You missunderstand the situation here. cdrkit does not listen to
the users at all and did not add support for missing features
nor did it implement any bug fixes. There are more than 100 well known
bugs in cdrkit and none of them has been fixed during the past three
years. Every release from cdrkit did have more than 100 well known bugs
at the time of publishing, so there was not a single "stable release"
from cdrkit.
Cdrtools is constantly enhanced. If you read old man pages instead of the
recent ones, you need to ask the related FreeBSD packet maintainer
for a fix of this FreeBSD specific problem.
I am constantly listening to the users and every useful remark from a user
results in an enhancement in the software or the documentation.
The problem is not that I am not listening to users and not writing useful man
pages but that people use outdated software, read outdated man pages and try
to blame me for a situation that is more than 5 years ago.
People need to understand that a high quality developer release is worth more
than a half hearted "final release". Look at OpenSolaris, there was no "final
release" since 5 years and nobody complains as there are usable developer
releases on a regular base (as with cdrtools).
Joerg Schilling
>On 2010-01-17, Joerg Schilling <j...@cs.tu-berlin.de> wrote:
>>>It appeared I had made and burned an iso with an 8GB tar file in it,
>>>upon closer inspection only 4GB actually went to disk but it went twice.
>>>I got 2 duplicate (not split) 4GB archives on the disk.
>>
>> If this is true, then the FreeBSD kernel does not support large files.
>>
>
>Do you mean to say FBSD's implementation of cd9660 doesn't support
>large files? Because using mkisofs I seem to have a 4GB limit, but that
>limit doesn't appear to exist with UFS2 or ext3 in FBSD.
We are currently talking about ISO-9660. For this reason, I don't care on
whether other filesystems support large files. If you see more than one
directory entry with the same name, then FreeBSD seems to ignore the
multi-extent flag in the ISO-9660 directory entry.
Indi
> In article <7rgq1m...@mid.individual.net>, Indi <in...@127.0.0.1> wrote:
>>On 2010-01-17, Joerg Schilling <j...@cs.tu-berlin.de> wrote:
>>>>It appeared I had made and burned an iso with an 8GB tar file in it,
>>>>upon closer inspection only 4GB actually went to disk but it went twice.
>>>>I got 2 duplicate (not split) 4GB archives on the disk.
>>>
>>> If this is true, then the FreeBSD kernel does not support large files.
>>>
>>
>>Do you mean to say FBSD's implementation of cd9660 doesn't support
>>large files? Because using mkisofs I seem to have a 4GB limit, but that
>>limit doesn't appear to exist with UFS2 or ext3 in FBSD.
>
> We are currently talking about ISO-9660. For this reason, I don't care on
> whether other filesystems support large files.
Well ok, but IMO you did make an absolute statement which could easily be
misunderstood. :)
> If you see more than one
> directory entry with the same name, then FreeBSD seems to ignore the
> multi-extent flag in the ISO-9660 directory entry.
>
Testing further I find no problem writing files as large as 8GB (max size I
tested) in FreeBSD using mkisofs with "--iso-level 3 -udf" options (and mounting
as udf).
Thanks very much for your work on this software, Joerg. The functionality
you've provided is invaluable.
Cheers,
Joerg Schilling
>On 2010-01-17, Joerg Schilling <j...@cs.tu-berlin.de> wrote:
>> If you see more than one
>> directory entry with the same name, then FreeBSD seems to ignore the
>> multi-extent flag in the ISO-9660 directory entry.
>>
>
>Testing further I find no problem writing files as large as 8GB (max size I
>tested) in FreeBSD using mkisofs with "--iso-level 3 -udf" options (and mounting
>as udf).
OK, but then you did use the UDF filesystem part from the hybrid and not
the ISO9660 part.
Indi
> In article <7rgvl8...@mid.individual.net>, Indi <in...@127.0.0.1> wrote:
>>On 2010-01-17, Joerg Schilling <j...@cs.tu-berlin.de> wrote:
>
>>> If you see more than one
>>> directory entry with the same name, then FreeBSD seems to ignore the
>>> multi-extent flag in the ISO-9660 directory entry.
>>>
>>
>>Testing further I find no problem writing files as large as 8GB (max size I
>>tested) in FreeBSD using mkisofs with "--iso-level 3 -udf" options (and mounting
>>as udf).
>
> OK, but then you did use the UDF filesystem part from the hybrid and not
> the ISO9660 part.
>
So does that mean the "--iso-level 3" part is sperfluous, and that I need only use
"-udf"?
Joerg Schilling
>On 2010-01-17, Joerg Schilling <j...@cs.tu-berlin.de> wrote:
>> OK, but then you did use the UDF filesystem part from the hybrid and not
>> the ISO9660 part.
>>
>
>So does that mean the "--iso-level 3" part is sperfluous, and that I need only use
>"-udf"?
Mkisofs always creates a ISO-9660 filesystem as a base. You may exclude files
from the visibility from ISO-9660 with one of the '*hide*' options, but files
that are not in ISO-9660 for other reasons will not be able to appear in other
filesystems.
If you like to make files > 4 GB appear in UDF, you need to use -iso-level 3
or above. If you like to make symlinks appear in UDF, you need to add Rock
Righe attributes to ISO-9660 (and use -R or -R in addition).
Note that genisoimage does not support symlinks in UDF as it is based on a
very old mkisofs.
Indi
> In article <7rh33e...@mid.individual.net>, Indi <in...@127.0.0.1> wrote:
>>On 2010-01-17, Joerg Schilling <j...@cs.tu-berlin.de> wrote:
>
>>> OK, but then you did use the UDF filesystem part from the hybrid and not
>>> the ISO9660 part.
>>>
>>
>>So does that mean the "--iso-level 3" part is sperfluous, and that I need only use
>>"-udf"?
>
> Mkisofs always creates a ISO-9660 filesystem as a base. You may exclude files
> from the visibility from ISO-9660 with one of the '*hide*' options, but files
> that are not in ISO-9660 for other reasons will not be able to appear in other
> filesystems.
>
> If you like to make files > 4 GB appear in UDF, you need to use -iso-level 3
> or above. If you like to make symlinks appear in UDF, you need to add Rock
> Righe attributes to ISO-9660 (and use -R or -R in addition).
>
> Note that genisoimage does not support symlinks in UDF as it is based on a
> very old mkisofs.
>
Thank you for that.