Talk:Optical disc drive

From ArchWiki
(Redirected from Talk:Optical Disc Drive)
Jump to: navigation, search

Verifying the burnt ISO image

Although the part with getting the md5sum of the previously created ISO image is quite obvious, the part with verifying the actual contents of the burnt disc seems to be somewhat inaccurate.

As soon as you have an alias like alias ls='ls-hF --color=auto' in your .profile, which could come in handy, the mentioned method for getting the block count is wrong:

$ blocks=$(expr $(ls -l isoimage.iso | awk '{print $5}') / 2048)

To make sure the calculated block count is valid for various user defined environments I would recommend the use of du -b:

$ blocks=$(expr $(du -b isoimage.iso | awk '{print $1}') / 2048)


That's what I just stumbled upon while trying to verify my burnt image.

I did not think of such aliases. My ~/.bashrc has: alias ls=ls
Your proposed du seems less prone to aliasing. Option -b is promised to be safe from pitfalls of sparse files. So i will put it into the wiki.
I wonder, though, whether stat(1) would be ubiquitous enough in archlinux:
$ blocks=$(expr $(stat -c '%s' isoimage.iso) / 2048)
Scdbackup (talk) 15:42, 29 August 2013 (UTC)
General thoughts:
alias is an arbitrary nasty problem with shell commands, of course. One cannot avoid it by alias ls=ls in a sub shell. man 1 bash is merciless in that aspect. Inquiring alias manually, unaliasing, executing size determination, re-aliasing ... is much too complicated. Should we bet on the existence of /bin/ls or /bin/du ? Any other ideas to surely prevent alias evaluation in an interactive command ? Scdbackup (talk) 16:09, 29 August 2013 (UTC)
Research:
http://www.tldp.org/LDP/Linux-Filesystem-Hierarchy/html/bin.html and http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard promise the existence of /bin/ls . du is not listed there. So /bin/ls is currently my best bet to prevent alias evaluation.
I will wait a few days for objections or better ideas before changing the size command in the wiki page again. Please keep me from doing stupid things. Scdbackup (talk) 16:27, 29 August 2013 (UTC)
Of course there's no way to find a one-size-fits-all solution, maybe it's just worth to quickly mention the problem and propose the ls method as an alternative. I'd keep du as the main method because it's indeed less likely to be aliased. About its existence on all systems, this is the wiki for Arch Linux, whose basic, default installation includes coreutils, where both ls and du are provided. -- Kynikos (talk) 03:55, 31 August 2013 (UTC)
du -b seems quite robust. I tried to fool it by alias definitions like du='du --human-readable'. But an explict option -b overrides it properly. I still get the byte count. (Sequence matters. du -b --human-readable would show e.g. "590M"). My doubts about availability are rather about stat(1). It would be more appealing than du, because du's main job is to report disk usage, not the addressable byte size.
One of the problems i feared is demonstrated by :
dd if=/dev/zero bs=1 count=1 seek=10000000 of=/tmp/sparse_test ; ls -l /tmp/sparse_test ; du /tmp/sparse_test ; du -b /tmp/sparse_test
On my machine i get a file of adressable 10000001 bytes which uses only 12 disk blocks of 1 KB. But du -b does it right. So for now i postpone my plan to change the size determination once again. Scdbackup (talk) 09:30, 31 August 2013 (UTC)
The current command for calculating the block size gives a syntax error because I have the following alias alias du=du -c -h' in my .zshrc. The -c results in another row of output and the expr fails, the following change to the command solves this issue. I'm not really sure if its worth including it in the wiki but I thought I'll leave a suggestion here.
$ blocks=$(expr $(du -b isoimage.iso | awk 'NR==1{print $1}') / 2048)
The NR==1 makes sure that only the first row of output is used for the expression. --Saifazmi (talk) 13:54, 9 January 2018 (UTC)

restructure to read/play/write

can we slightly restructure the article please into three paragraphs:

  • read / copy, includes mount, read an iso image
  • write / burn, includes creating iso9660 image
  • play

the problem is that currently the paragraph to read an image is kind of hidden in a paragraph called "burning". i fell over this as i did not want to burn a dvd, but just copy one to disk and play to avoid scratching it. so i tried all the tools listed in ripping and none worked. it took a while to clue into the fact that one could just copy the iso off the disk and play it like one would do with an optical disk, no need to rip it. --Soloturn (talk) 04:30, 5 January 2017 (UTC)

Copying an optical disk means reading one disk and writing it to another optical disk. As it involves both reading and burning, it is too strict to split these topics. Also, Ripping is a topic of its own as it implies time-consuming transcoding of the media into a different format, so I don't agree with this organization. -- Lahwaacz (talk) 09:24, 5 January 2017 (UTC)

how do we solve it then, duplicate the info? ask somebody else what he thinks? --Soloturn (talk) 19:45, 5 January 2017 (UTC)

ISO 9660 and burning on-the-fly

The command provided for burning a DVD on the fly is missing the -dvd-compat parameter.

$ growisofs -Z /dev/sr0 -V "ARCHIVE_2013_07_27" -r -J ./for_iso

I suggest that the command mentioned above changes to include the -dvd-compat parameter.

$ growisofs -dvd-compat -Z /dev/sr0 -V "ARCHIVE_2013_07_27" -r -J ./for_iso

As without it once the data has been written to the DVD it cannot be mounted using the mount command, resulting in the following error.

$ sudo mount /dev/sr0 /mnt
mount: /mnt: wrong fs type, bad option, bad superblock on /dev/sr0, missing codepage or helper program, or other error.

The wiki already mentions the -dvd-compat parameter under the Burning an ISO image to CD, DVD, or BD section

$ growisofs -dvd-compat -Z /dev/sr0=isoimage.iso

But it's somehow missing from the ISO 9660 and burning on-the-fly section.

--Saifazmi (talk) 18:15, 9 January 2018 (UTC)