0

Is creating .iso image before burning to DVD-ROM necessary? I mean, I never noticed this on windows before burning my files to DVD-ROM, I never created an iso image file. But I had shifted to linux, and on the course of learning some terminal commands, I saw it being mentioned After creating an iso file, we would burn it to disk., So, my curiosity is summarized as:

1) Is creating .iso image files before burning necessary?
2) If yes, why is it that is it needed?

1

The data needs to be written to the DVD in the correct format with the correct disk lead-in, lead-out and filesystem structure.

Writing to disk either needs the ISO formatting applied on-the-fly to the collected data (files) before being passed to the disk writing buffer, or it can be helpful to create an image file that can be streamed directly to the drive.

One way or another the data needs to be organised properly before writing.

Linux has a habit of making "one good tool" to do a job, and then chaining up tools to achieve a complete task. Hence a lot of disk writing tools are little more than a graphical user interface for another tool or set of tools that do the actual work. After all why would you reinvent the wheel when you have a perfectly good set of wheels available already?

1

Is creating .iso image files before burning necessary?

Yes and no. Yes, you must create a suitable stream of bytes; and no, because you don't need to store it as a regular file on your HDD or SSD.

why is it that is it needed?

Many Linux tools follow "do one thing and do it well" rule. We have mkisofs for creating an ISO image, then e.g. cdrecord or cdrskin for burning it. In Windows tools that bloat to do all things by themselves are far more common. Another answer has already suggested they may build images on the fly; they may also store these images as temporary files.

Note you can achieve something similar in Linux. Check -o option of mkisofs; if this option is lacking, stdout is used. Programs writing to optical media can use their stdin in "Track At Once" mode.

Or you can create temporary files, even in memory (like in /dev/shm/).

  • can you provide a bit of more explanation on "you don't need to store it as a regular file on your HDD?" – Nis Apr 2 '18 at 3:02
  • @Nis Have you read about -o option of mkisofs? Have you scanned man cdrecord or man cdrskin for references to stdin? Are you familiar with piping commands in Linux? Have you done your research on what /dev/shm/ is? What explanation do you need? – Kamil Maciorowski Apr 2 '18 at 7:40
0

Burning a CD-ROM compatible with ISO9660 on command-line will always require a step to build the iso(9660) image, I think.

However, graphical tools like k3b (KDE) or brasero (gnome) will allow you to create data CD-ROMs without you need to explicitely run this step, they probably build the image on the fly during burning process.

0

1) No. As said by others, the data do not need to be stored intermediately on hard disk. The producer programs for ISO 9660 can emit a data stream to "standard output" and the burner programs can take this data stream by their "standard input". That's called a "pipe", a very fundamental Unix shell gesture.

The classic example is some variation of:

mkisofs /some/directory | cdrecord -v dev=/dev/sr0 -
My own way to do the same is:
xorriso -outdev /dev/sr0 -blank as_needed -map /some/directory /
(The data transfer is done internally between libisofs and libburn.)

Not to forget the GUI burn programs: K3b, Xfburn, Brasero, ... They coordinate ISO producer program and burn program without much assistance by the user.

Edit: Attempt to react on Nis' comment:

If you want to store not more than the content of a single file, then you could simply burn that file to the medium. If you later open file /dev/sr0, then it will bear your stored content (plus probably some trailing garbage).

If you want to store more than one file, or file names and other attributes, then you need to wrap your files into some filesystem or archive format. This format will later be readable by the appropriate filesystem driver (e.g. Linux "iso9660") or archive unpacker (e.g. program "tar").

You are of course free to pick only a few files from your hard disk and to give them different names in the resulting filesystem or archive. (mkisofs has option -graft-points and "pathspecs" /ISO/PATH=/DISK/PATH to control the renaming. Some archive programs may have similar capabilities to change file names when they get copied into their archive.)

Most filesystems would have to be created in a random-access writable device or in a filesystem image file on disk. That's because there is no producer program which would create them as sequential data stream. Such a sequential stream is a precondition for piping.

Archivers (e.g. "tar" or "zip") and ISO 9660 filesystem producers have the capability to emit their result as sequential stream. So they are the ones which can pipe their output into the input of a burn program.

(End of editing)

2) Now for the reason why so many proposals are around, which tell you to first store the ISO image file and to then burn it to medium.

In the bad old times of the first CD burners there was the risk of "buffer underrun". As soon as the drive wrote faster than the ISO producer program could deliver data, the drive threw an error and left the CD-R only partly written. The chance for success increased if the computer first ran the ISO program, until all data was produced, and only then started the burn program to read the ISO image from hard disk.

This time ended in the late 1990s by the invention of "burn free", which enabled the drive to wait for more data and to resume burning the CD. The problem of buffer underrun and burn abort did never hit DVD or BD media.

  • in my first point, I wanted to ask not the necessity of data being store somewhere, but if there was a necessity for the CDROM to mirror the filesystem of the hard disk? – Nis Apr 2 '18 at 3:04
  • I tried to address this comment by a few statements betwen "Edit:" and "End of editing". – Thomas Schmitt Apr 2 '18 at 8:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.