Prev: 9,000 ZFS mount points
Next: No internet access
From: CeDeROM on 16 Jan 2010 06:33
Hello Clemens!

On 15 Sty, 09:33, Clemens Zauner <cz+use...(a)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
From: CeDeROM on 16 Jan 2010 07:57
Hello Joerg!

On 15 Sty, 16:41, j...(a)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
From: CeDeROM on 16 Jan 2010 11:11
Hello Joerg!

On 15 Sty, 16:42, j...(a)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
From: Indi on 16 Jan 2010 11:32
On 2010-01-15, Indi <indi(a)16x108.merseine.nu> wrote:
> On 2010-01-15, Joerg Schilling <js(a)cs.tu-berlin.de> wrote:
>>
>> 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.
>

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.
From: Indi on 16 Jan 2010 12:54
On 2010-01-16, Indi <indi(a)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.
So apparently writing files larger than 4GB is broken, even with cdrtools-devel.
How 1998...

--
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.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6
Prev: 9,000 ZFS mount points
Next: No internet access