Hi,
> mkisofs -r -J -C `cdrecord dev=0,3,0 -msinfo` -M /dev/cdrw -o immagine3.iso
> path3 -> ERROR : genisoimage: Invalid argument. Seek error on old
> image
>
> If i eject the cd then insert it again the comand mkisofs -r -J -C `cdrecord
> dev=0,3,0 -msinfo` -M /
[Robert Millan]
> In 2006, the cdrtools version of mkisofs spawned another fork:
> genisoimage, which was included as part of cdrkit package in the
> Debian GNU/Linux distribution.
I don't know if this is any use, but: my humble contributions to the
cdrkit project, past and
Robert Millan wrote:
> On Sun, Jan 10, 2010 at 12:09:50AM +0100, Joerg Schilling wrote:
> > If you really like to take the outdated mkisofs and play with it, I urge
> > you not to use the name "mkisofs" for this
>
> Next release will be renamed to GNU isofs
Hi,
On Sun, Jan 10, 2010 at 12:09:50AM +0100, Joerg Schilling wrote:
> If you really like to take the outdated mkisofs and play with it, I urge
> you not to use the name "mkisofs" for this
Next release will be renamed to GNU isofsmk to make sure users won't get
confused.
Robert Millan wrote:
> So if you'd like to create a GRUB bootable disk, you'd do something
> like:
>
> cat boot.img core.img > tmp
> mkisofs --embedded-boot tmp -o grub.iso -r somedir
>
> Of course, if you put together all the details (like building co
les like filesystem driver).
So one does not have to search for it.
> - core.img is instructed to search in /boot/grub/ for
> grub.cfg and other modules, etc.
Very convenient.
> So if you'd like to create a GRUB bootable disk, you'd do something
> like:
> cat boot.i
ust as much as occupied by
core.img).
So if you'd like to create a GRUB bootable disk, you'd do something
like:
cat boot.img core.img > tmp
mkisofs --embedded-boot tmp -o grub.iso -r somedir
Of course, if you put together all the details (like building core.img and
filling up /bo
Robert Millan wrote:
> On Fri, Jan 08, 2010 at 05:30:09PM +0100, Joerg Schilling wrote:
> >
> > You also do not mention that the even outdated version of mkisofs you are
> > using
> > contains code from me.
>
> This is true (at least for files proto
On Sat, Jan 09, 2010 at 10:27:20PM +0100, Mario Đanić wrote:
>
> Both a mentor and a student, and an unofficial admin (reading all
> applications, and ranking them *sigh*). Being part of the program is
> very rewarding, and subsequently its a great privilege to work with a
> great student.
:-)
>
iented capabilities of
http://scdbackup.sourceforge.net/xorriso_eng.html
(genisofs would be our mkisofs emulator. But i
deem the architecture of separate ISO generator
and burn program quite suboptimal. So i rather
started an integrated ISO+burn tool.)
Have a nice day :)
Thomas
--
To UNSUBSCRIBE, em
tough task IMO and you get a nice
> tshirt! ;-)
Both a mentor and a student, and an unofficial admin (reading all
applications, and ranking them *sigh*). Being part of the program is
very rewarding, and subsequently its a great privilege to work with a
great student.
>
>> Also, I'd encourage
ew libisofs we were designing.
Hi Mario!
Thanks for your offer, it's very kind of you. I'm not sure if you've been
a mentor in GSoC before, but it's not a tough task IMO and you get a nice
tshirt! ;-)
> Also, I'd encourage working on UDF inside libisofs and event
;t have a thorough understanding of the UDF
standard, but know a bit or two about it because I studied it when I
wrote an enchantment ticket against new libisofs we were designing.
Also, I'd encourage working on UDF inside libisofs and eventual
genisofs (CLI-compatible mkisofs-alike tool based o
l MBRs in general.
> (The question is about how one has to patch
> the boot image and/or the MBR after the block
> address of the boot image is determined.)
I don't understand your question. First 32 kiBs are used to embed a chunk
of arbitrary data. mkisofs is agnostic to its m
Hi,
> * Support for creating large images (> 4 GiB).
You are aware that even quite young Linux kernels
have problems to read multi-extent files ?
My 2.6.18 swallows the last few bytes if the file
size is not a multiple of 2048.
(libisofs can dare to produce such files without
warning because its
On Fri, Jan 08, 2010 at 08:24:10PM +0100, Thomas Schmitt wrote:
> > bringing it to up-to-date standards, as
> > well as implementing some unique features that are necessary for GRUB,
> > the GNU bootloader.
>
> Would you be interested in cooperating with
> the libburnia project ? (Exchanging knowl
Hi,
On Fri, Jan 08, 2010 at 05:30:09PM +0100, Joerg Schilling wrote:
>
> You also do not mention that the even outdated version of mkisofs you are
> using
> contains code from me.
This is true (at least for files prototyp.h, fctldefs.h, statdefs.h and
mconfig.h where your
Hi,
> I'm proud to announce the release of GNU mkisofs version 1.13.
Wow. That is kindof a blast from the past.
> bringing it to up-to-date standards, as
> well as implementing some unique features that are necessary for GRUB,
> the GNU bootloader.
Would you be interested in
Til Schubbe wrote:
> > Well, your source does not even compile
>
> At least it compiles on my machine.
Nobody is interested in software from 1997 and with only the features from 1997.
Jörg
--
EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
j...@cs.tu-b
* On 08.01. Joerg Schilling muttered:
> Well, your source does not even compile
At least it compiles on my machine.
Regards
Til
--
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@other.debian.org
Robert Millan wrote:
> I'm proud to announce the release of GNU mkisofs version 1.13.
Could you please explain this?
Do you like to confuse people with outdated software?
This looks like complete nonsense. The official mkisofs is part of cdrtools
since a long time and the official
Hi,
I'm proud to announce the release of GNU mkisofs version 1.13.
This release implements a few new features relative to the previous one
(mkisofs 1.12b5). But most importantly, the codebase has been updated
to modern standards and the build system has been rewritten from scratch
using r
l nor too brief. I always appreciate someone
with communication skill like you do.
I thus doubt there are something wrong with the "superblock". I think
now what I can do is to get you dump of everything until 190, end of
volume descriptor, to see if there are something wrong. It is not
Gregoire Favre wrote:
> > If you are interested in the reason for your original problem, plese
> > deliver
> > the needed information.
>
> I guess it's a limitation of iso9660, but'll go for UDF, thank you very
> much !!!
iso9660 supports single files up to 8 TB.
Jörg
--
EMail:jo...@schily
On Sun, Jan 18, 2009 at 12:06:30AM +0100, Joerg Schilling wrote:
>
> iso9660 supports single files up to 8 TB.
Ouch, then it's something else, but as I can make it works with UDF I am
pretty happy so ;-)
Thanks again for solving my problem !!!
--
Grégoire FAVRE http://gregoire.favre.googlepages
hich would work
> instead of mkisofs in the script you
> posted a few days ago.
> (As said: for the case without -dvd-video)
>
> Or in xorriso's own personality and notation:
> target=/dev/sr1
> xorriso \
> -outdev "$target" -blank as_needed \
>
On Sat, Jan 17, 2009 at 11:24:53PM +0100, Joerg Schilling wrote:
> mkisofs also supports UDF and if you tell mkisofs to add UDF, you will
> probably
> see the same as with nero.
You are a GENIUS !!!
I added the "-UDF -udf" and now it works ;-)
> If you are interested
Gregoire Favre wrote:
> On Sat, Jan 17, 2009 at 08:05:52PM +0100, Thomas Schmitt wrote:
>
> > I can offer program xorriso as an alternative
> > to mkisofs as long as it is for ISO 9660 data file
> > recording.
>
> Just compiled it ;-)
>
> > Afaik, there
I just gave a small look at xorriso.1 : do you think I can create a iso
> with it in order to try if that would work ?
After installing it, there should be
a command xorrisofs which would work
instead of mkisofs in the script you
posted a few days ago.
(As said: for the case without -dvd-video
On Sat, Jan 17, 2009 at 08:05:52PM +0100, Thomas Schmitt wrote:
> I can offer program xorriso as an alternative
> to mkisofs as long as it is for ISO 9660 data file
> recording.
Just compiled it ;-)
> Afaik, there is a standard for auxiliary data files
> in an UDF file system
"Thomas Schmitt" wrote:
> Hi,
>
> > Different is not the same.
> > I don't understand why when I write a large file with cdrecord and
> > mkisofs it's md5sum change and when I burn it with nero it stay the
> > same.
>
> This does not look
Gregoire Favre wrote:
> On Sat, Jan 17, 2009 at 06:44:07PM +0100, Joerg Schilling wrote:
>
> > What is "different"?
>
> Different is not the same.
> I don't understand why when I write a large file with cdrecord and
> mkisofs it's md5sum change and
Hi,
> Different is not the same.
> I don't understand why when I write a large file with cdrecord and
> mkisofs it's md5sum change and when I burn it with nero it stay the
> same.
This does not look like a problem with cdrecord
but rather like one with mkisofs.
> My o
On Sat, Jan 17, 2009 at 06:44:07PM +0100, Joerg Schilling wrote:
> What is "different"?
Different is not the same.
I don't understand why when I write a large file with cdrecord and
mkisofs it's md5sum change and when I burn it with nero it stay the
same.
So my conc
but if I use cdrecord/mkisofs then
> it's different, so there is something which didn't work well, certainly
> because I didn't give the right option to burn, but maybe that's not the
> problem.
What is "different"?
> > If mplayer correclty plays the
On Sat, Jan 17, 2009 at 06:05:13PM +0100, Joerg Schilling wrote:
> You unfortunately do not give information on the problem..
If I burn my files with nero, and then do a md5sum of the files, they
are the same than the one from my HD, but if I use cdrecord/mkisofs then
it's diffe
Gregoire Favre wrote:
> On Sat, Jan 17, 2009 at 12:35:41PM +0100, Joerg Schilling wrote:
>
> > You will need to fix mplayer - it seems to be not largefile aware.
>
> No mplayer is fine.
>
> > BTW: The maximum file size for the official DVD-Video DVD format is
> > 1 GB - 2048 bytes.
>
> I don't s
On Sat, Jan 17, 2009 at 12:35:41PM +0100, Joerg Schilling wrote:
> You will need to fix mplayer - it seems to be not largefile aware.
No mplayer is fine.
> BTW: The maximum file size for the official DVD-Video DVD format is
> 1 GB - 2048 bytes.
I don't speak about DVD-Video, just Data DVD.
>
Gregoire Favre wrote:
> I wrote a small wrapper script to burn DVD, it works very well for files
> smaller than 2Gb but the big one are readable in a "funny" way : if they
> are video files for example, mplayer can plan them, but not seek in
> those files ???
You will need to fix mplayer - it se
fi
VIDEO=`ls $2|grep -i VIDEO_TS 2> /dev/null |wc -w`
if [ $VIDEO -eq 0 ]; then
OPTS=$COM
SIZE=`mkisofs -f -J -r -graft-points -quiet -print-size -V $1
$2`
else
OPTS="$COM -dvd-video"
SIZE=`mki
me
to communicate with dvd+rw-tools users. In other words yes, if I have
few minutes I'd rather do that.
> but to not like to support
> mkisofs.
I don't understand... "You have time ... to not like support mkisofs"?
Like "have time to dislike doing something [w
nsupported
by mkisofs, so please reorder your list to let #2 appear last.
Why? Bug #2 doesn't have anything to do with other bugs and steps to
reproduce it were very detailed:
http://lists.debian.org/cdwrite/2008/07/msg00082.html.
For the reasons mentioned above, I propose that you present
ntroduce obvious new problems and in case that some
basic tests pass with the new code.
As ISO-9660 allows to introduce many dirty tricks, many of them are unsupported
by mkisofs, so please reorder your list to let #2 appear last.
For the reasons mentioned above, I propose that you present
dure uses the return
value itself and modification let it use wrong value. See below for
further details. Rest of the problems were left without attention.
For reference, here is how to reproduce #5:
1. touch 5G; perl -e 'truncate("5G",5*1024*1024*1024)'
2. ./mkisofs -iso-
utodetect" this?
>
> The documentation of webcdwriter claims that this is autodetected.
If this is related to mkisofs it seems to be wrong.
Maybe it is related to your work environment that does not use UTF-8?
In any case, it usually seems to be better to let mkisofs auto-detect
the file name codi
Hallo Jörg,
Am Freitag, 5. Dezember 2008 14:00 schrieb Joerg Schilling:
> > [webcdwriter log]
> > 163515 T08894 L5 "useUTF8" "false"
>
> How could it "autodetect" this?
The documentation of webcdwriter claims that this is autodetected.
--
Gruss Marcus
Marcus Roeckrath -- Vikarsbusch 8 -- D-4
Marcus Roeckrath <[EMAIL PROTECTED]> wrote:
> > > what does happen if mkisofs is started with -input-charset UTF-8 on a
> > > system which is not utf-capable?
> >
> > Why would you do ths is the local filesystem does not use UTF-8
> > file names?
>
Hi Jörg,
Am Freitag, 5. Dezember 2008 12:38 schrieb Joerg Schilling:
> > what does happen if mkisofs is started with -input-charset UTF-8 on a
> > system which is not utf-capable?
>
> Why would you do ths is the local filesystem does not use UTF-8
> file names?
Its the webc
Marcus Roeckrath <[EMAIL PROTECTED]> wrote:
> Hi Jörg,
>
> what does happen if mkisofs is started with -input-charset UTF-8 on a
> system which is not utf-capable?
Why would you do ths is the local filesystem does not use UTF-8
file names?
If your system is halfway consistent
Hi Jörg,
what does happen if mkisofs is started with -input-charset UTF-8 on a
system which is not utf-capable?
--
Gruss Marcus
Marcus Roeckrath -- Vikarsbusch 8 -- D-48308 Senden -- Germany
Phone : +49-2536-9944 -- Fax : +49-2536-9943
E-Mail : [EMAIL PROTECTED]
WWW: http
Joerg Schilling wrote:
Giulio Orsero <[EMAIL PROTECTED]> wrote:
The incorrect perms are a result of the bugs in the mkisofs version that comes
with Redhat.
Actually I was always talking about the permissions/timestamp on the test
directory "dir1", these were incorre
ly use mkisofs or to create a fix soon.
This is an important difference to the fork used by some Linux distros ;-)
For once we are in total agreement. ;-)
--
Bill Davidsen <[EMAIL PROTECTED]>
"Woe unto the statesman who makes war without a reason that will still
be valid whe
On Wed, 09 Jul 2008 16:48:13 +0200, [EMAIL PROTECTED]
(Joerg Schilling) wrote:
>Giulio Orsero <[EMAIL PROTECTED]> wrote:
>
>> >The incorrect perms are a result of the bugs in the mkisofs version that
>> >comes
>> >with Redhat.
>>
>> Actually I
Bill Davidsen <[EMAIL PROTECTED]> wrote:
> > Please check again with the following patch, it should then work even
> > without
> > -find:
> >
> >
>
> Thank you for the patch.
Well, if a problem was described decently, I am usually able to explain ho
Giulio Orsero <[EMAIL PROTECTED]> wrote:
> >The incorrect perms are a result of the bugs in the mkisofs version that
> >comes
> >with Redhat.
>
> Actually I was always talking about the permissions/timestamp on the test
> directory "dir1", these were i
Joerg Schilling wrote:
Giulio Orsero <[EMAIL PROTECTED]> wrote:
isoinfo output was always right (at least as for permissions and timestamp
which I was interested in).
isoinfo displayed wrong timestamps for "." and ".." with the old mkisofs clone
that com
On Wed, 09 Jul 2008 09:50:09 -0400, Bill Davidsen <[EMAIL PROTECTED]> wrote:
>I believe that this may be a result of the loop mount.
I used loop mount just as a quick test case.
I first encountered the issue with real DVDs on which I burned the iso
image.
--
[EMAIL PROTECTED]
--
To UNSUBSCR
/timestamp if mounted on RHEL3
>
>The incorrect perms are a result of the bugs in the mkisofs version that comes
>with Redhat.
Actually I was always talking about the permissions/timestamp on the test
directory "dir1", these were incorrect even when the iso was created with
mkisofs
Giulio Orsero <[EMAIL PROTECTED]> wrote:
> isoinfo output was always right (at least as for permissions and timestamp
> which I was interested in).
isoinfo displayed wrong timestamps for "." and ".." with the old mkisofs clone
that comes with RedHat.
isoinfo
On Wed, 09 Jul 2008 11:06:33 +0200, [EMAIL PROTECTED]
(Joerg Schilling) wrote:
>> So, is this a RHEL5 general fs issue or a RHEL5 isofs issue?
>>
>> Why would the method used my mkisofs matter if isoinfo show the same output?
>
>I don't understand you.
>
>I tho
ld
> >work. Did you test it?
>
> Sorry, I hadn't seen it, here's the output:
>
> ===
> mkisofs 2.01.01a42 (i686-pc-linux-gnu) Copyright (C) 1993-1997 Eric
> Youngdale (C) 1997-2008 Jörg Schilling
> Setting input-charset to 'UTF-8' from locale.
[EMAIL PROTECTED] d0]#
>
>OK, so the filesystem does not behave as expected on UNIX:
>
>If "." and ".." are delivered at all, they come first.
>
>In any case, the -find variant of the command line I send you should
>work. Did you test it?
Sorry, I hadn'
Giulio Orsero <[EMAIL PROTECTED]> wrote:
> On Wed, 09 Jul 2008 01:37:03 +0200, [EMAIL PROTECTED]
> (Joerg Schilling) wrote:
>
> >[EMAIL PROTECTED] (Joerg Schilling) wrote:
> >
> >> "Giulio Orsero" <[EMAIL PROTECTED]> wrote:
> >> >
On Wed, 09 Jul 2008 01:37:03 +0200, [EMAIL PROTECTED]
(Joerg Schilling) wrote:
>[EMAIL PROTECTED] (Joerg Schilling) wrote:
>
>> "Giulio Orsero" <[EMAIL PROTECTED]> wrote:
>> > mkisofs 2.01.01a42 (i686-pc-linux-gnu) Copyright (C) 1993-1997 Eric
>> >
[EMAIL PROTECTED] (Joerg Schilling) wrote:
> "Giulio Orsero" <[EMAIL PROTECTED]> wrote:
>
> > # isoinfo -version
> > isoinfo 2.01.01a42 (i686-pc-linux-gnu) Copyright (C) 1993-1999 Eric
> > Youngdale (C
> > ) 1999-2008 Jörg Schilling
> > # mk
"Giulio Orsero" <[EMAIL PROTECTED]> wrote:
> # isoinfo -version
> isoinfo 2.01.01a42 (i686-pc-linux-gnu) Copyright (C) 1993-1999 Eric Youngdale
> (C
> ) 1999-2008 Jörg Schilling
> # mkisofs -version
> mkisofs 2.01.01a42 (i686-pc-linux-gnu) Copyright (C) 1993-
.g. this one
>
> If you still see the problem, do the following:
>
> become root, then call
>
> rm /bin/mkisofs
> rm /bin/genisoimage
# isoinfo -version
isoinfo 2.01.01a42 (i686-pc-linux-gnu) Copyright (C) 1993-1999 Eric Youngdale (C
) 1999-2008 Jörg Schilling
# mkisofs -versi
"Giulio Orsero" <[EMAIL PROTECTED]> wrote:
> On Tue, Jul 8, 2008 at 10:13 PM, Joerg Schilling
> <[EMAIL PROTECTED]> wrote:
> > Giulio Orsero <[EMAIL PROTECTED]> wrote:
>
> >> # uname -r
> >> 2.6.18-92.1.6.el5
> >> # mki
On Tue, Jul 8, 2008 at 10:13 PM, Joerg Schilling
<[EMAIL PROTECTED]> wrote:
> Giulio Orsero <[EMAIL PROTECTED]> wrote:
>> # uname -r
>> 2.6.18-92.1.6.el5
>> # mkisofs -version
>> mkisofs 2.01 (cpu-pc-linux-gnu)
>> (I tried stock 2.01.01a42 with no cha
Giulio Orsero <[EMAIL PROTECTED]> wrote:
> This is very likely a CENTOS5 (RHEL5) isofs driver issue, but since it's
> very weird I thought to ask here whether someone can reproduce it just to be
> sure this is not a misconfiguration/error on my part.
>
> Problem
This is very likely a CENTOS5 (RHEL5) isofs driver issue, but since it's
very weird I thought to ask here whether someone can reproduce it just to be
sure this is not a misconfiguration/error on my part.
Problem: dirs on which an mkisofs exclusion is made show with wrong
permissions/time
t; multi-extent files. Once again I want to point out that I make no claims
> that the patches are complete solution to the problem. Their purpose is
> to support claims in original bug report. A.
>
Your new patch still is not correct:
- It does not honor the data structures f
You used mkisofs incorrectly
Command line sequence was *tailored* to allow to produce usable input
for *hex editor* in less than minute.
Why did you use -C16,xxx?
This is definitely wrong.
The reason is in the beginning of merge_isofs() in multi.c. In
particular for (i=0;i<100;i++) loop.
Joerg Schilling wrote:
Andy Polyakov <[EMAIL PROTECTED]> wrote:
You used mkisofs incorrectly
Command line sequence was *tailored* to allow to produce usable input
for *hex editor* in less than minute.
Why did you use -C16,xxx?
This is definitely
Andy Polyakov <[EMAIL PROTECTED]> wrote:
> >>>>> You used mkisofs incorrectly
> >>>> Command line sequence was *tailored* to allow to produce usable input
> >>>> for *hex editor* in less than minute.
> >>> Why did you use -C16,x
You used mkisofs incorrectly
Command line sequence was *tailored* to allow to produce usable input
for *hex editor* in less than minute.
Why did you use -C16,xxx?
This is definitely wrong.
The reason is in the beginning of merge_isofs() in multi.c. In
particular for (i=0;i<100;i++) loop.
Andy Polyakov <[EMAIL PROTECTED]> wrote:
> Exhibit #7. 'isoinfo -l -T -i /dev/dvd' output for same recording:
>
> Directory listing of /
> d- 000 2048 May 20 2008 [2621639 02] .
> d- 000 2048 May 20 2008 [2621639 02] ..
> -- 00
Bill Davidsen <[EMAIL PROTECTED]> wrote:
> > The second step will be to make retained multi-extent files correclty in
> > the
> > next session.
> >
> > If there is a remaining problem, lets see.
> >
> >
> I have no problem with following correct steps in order. I think there's
> a proble
ins. I will continue to do things right with mkisofs rather than
trying to find quick ways to hide problems at first sight (as done in
"genisoimage"). Users of my software can rely on me taking things seriously. In
the long term, I will be able to keep software maintainable that's
there is a remaining problem, lets see.
Doing things correct may look as if it takes more time than doing things quickly
but it finally wins. I will continue to do things right with mkisofs rather
than
trying to find quick ways to hide problems at first sight (as done in
"genisoimage")
Joerg Schilling wrote:
Andy Polyakov <[EMAIL PROTECTED]> wrote:
You used mkisofs incorrectly
Command line sequence was *tailored* to allow to produce usable input
for *hex editor* in less than minute.
Why did you use -C16,xxx?
This is definitely wrong.
Andy Polyakov <[EMAIL PROTECTED]> wrote:
> >>> You used mkisofs incorrectly
> >> Command line sequence was *tailored* to allow to produce usable input
> >> for *hex editor* in less than minute.
> >
> > Why did you use -C16,xxx?
> >
&g
>>> You used mkisofs incorrectly
>> Command line sequence was *tailored* to allow to produce usable input
>> for *hex editor* in less than minute.
>
> Why did you use -C16,xxx?
>
> This is definitely wrong.
Why I even bothered to report this? To be told
Bill Davidsen <[EMAIL PROTECTED]> wrote:
> > mkisofs is a well known program name and I cannot see that your proposal
> > for a
> > name change could help to reduce confusion for users.
> >
> >
> Wow, think about that! You have to tell people many t
dia, that a name like "mkoptimage" would be more correct as well as
preventing confusion.
mkisofs is a well known program name and I cannot see that your proposal for a
name change could help to reduce confusion for users.
Wow, think about that! You have to tell people many ti
a name like "mkoptimage" would be more correct as well as
> preventing confusion.
mkisofs is a well known program name and I cannot see that your proposal for a
name change could help to reduce confusion for users.
The probably biggest help for _new_ users was to list only the "m
Andy Polyakov <[EMAIL PROTECTED]> wrote:
> > You used mkisofs incorrectly
>
> Command line sequence was *tailored* to allow to produce usable input
> for *hex editor* in less than minute.
Why did you use -C16,xxx?
This is definitely wrong.
BTW: isoinfo gives you all in
Consider creating say 5GiB file and mastering an image:
$ touch 5G.0
$ perl -e 'truncate("5G.0",5*1024*1024*1024)'
$ ./mkisofs -iso-level 3 5G.0 > 1st.iso
One does not have to wait till mkisofs completes, just press ctrl-c as
soon as progress indicator goes off and exam
"Thomas Schmitt" <[EMAIL PROTECTED]> wrote:
> Hi,
>
> > 5G.0;1 0x804GB-2KB X
> > 5G.0;1 0x005GB-(4GB-2KB) X+0x20-1
>
> as an interested bystander i wonder how
> it is about general mountability of this
> image. Is this supported in contemporary
> Linux ?
A
Andy Polyakov <[EMAIL PROTECTED]> wrote:
> $ ./mkisofs -v
> mkisofs 2.01.01a39 ...
>
> Consider creating say 5GiB file and mastering an image:
>
> $ touch 5G.0
> $ perl -e 'truncate("5G.0",5*1024*1024*1024)'
> $ ./mkisofs -iso-level 3 5G.0 &g
Joerg Schilling wrote:
mkisofs is a program that has been originally writen in 1993 by Eric Youngdale
and that has been extended by many people.
In 1997, after Eric Youngdale mostly stopped working on mkisofs, I added
mkisofs to the cdrecord source tree and started working on bugs and
>> 5G.0;1 0x804GB-2KB X
>> 5G.0;1 0x005GB-(4GB-2KB) X+0x20-1
>
> as an interested bystander i wonder how
> it is about general mountability of this
> image. Is this supported in contemporary
> Linux ?
Define "supported." Multi-extent files are recognized by
Hi,
> 5G.0;1 0x804GB-2KB X
> 5G.0;1 0x005GB-(4GB-2KB) X+0x20-1
as an interested bystander i wonder how
it is about general mountability of this
image. Is this supported in contemporary
Linux ?
Have a nice day :)
Thomas
--
To UNSUBSCRIBE, email to [EMA
$ ./mkisofs -v
mkisofs 2.01.01a39 ...
Consider creating say 5GiB file and mastering an image:
$ touch 5G.0
$ perl -e 'truncate("5G.0",5*1024*1024*1024)'
$ ./mkisofs -iso-level 3 5G.0 > 1st.iso
One does not have to wait till mkisofs completes, just press ctrl-c as
soo
mkisofs is a program that has been originally writen in 1993 by Eric Youngdale
and that has been extended by many people.
In 1997, after Eric Youngdale mostly stopped working on mkisofs, I added
mkisofs to the cdrecord source tree and started working on bugs and important
extensions.
After 2
Joerg Schilling wrote:
Bill Davidsen <[EMAIL PROTECTED]> wrote:
What you do here did never work as you believe.. You are using incorrect
syntax.
What I have been doing has been working for years, and worked with the
mkisofs from wodim, and with "mkisofs 2.01a12 (i6
Bill Davidsen <[EMAIL PROTECTED]> wrote:
> > What you do here did never work as you believe.. You are using incorrect
> > syntax.
> >
>
> What I have been doing has been working for years, and worked with the
> mkisofs from wodim, and with "mkisofs 2
Joerg Schilling wrote:
Bill Davidsen <[EMAIL PROTECTED]> wrote:
After installing the recent cdrtools (a35), I started a backup script
which writes all the backup information in a file and then creates an
ISO image thus:
mkisofs -o $DATE.iso -RU -graft-points -path-list $DATE.fi
Bill Davidsen <[EMAIL PROTECTED]> wrote:
> After installing the recent cdrtools (a35), I started a backup script
> which writes all the backup information in a file and then creates an
> ISO image thus:
> mkisofs -o $DATE.iso -RU -graft-points -path-list $DATE.filelist
&
After installing the recent cdrtools (a35), I started a backup script
which writes all the backup information in a file and then creates an
ISO image thus:
mkisofs -o $DATE.iso -RU -graft-points -path-list $DATE.filelist
The run aborted saying that files had the same Rockridge name. After
1 - 100 of 647 matches
Mail list logo
