Silent failure when out of /tmp space

[Tristan]

Binary package hint: gnomebaker

In Gnomebaker 0.6.2, copying a DVD when /tmp is low on space will result in a truncated, broken copy. There is no visual error report .

Steps to reproduce:

1. Use a small (hint: ramdisk) /tmp space and plan to copy a larger-than-/tmp DVD.
2. Tools->Copy DVD
3. Copy with "Burn the disk" (single optical drive system, if that matters).
4. Watch the burn "succeed" and enjoy a new coaster/frisbee.

I suggest catching and failing on a out-of-space error when writing the temporary iso file.

User workaround: In the preferences, set the temporary folder to a place that has plenty of room.

[Mario Đanić (mario-danic)]

Would you be willing to provide a patch for this?

[Tristan (tristan-willy)]

I decided to take a deeper look into it, and it looks like it's not gnomebaker's fault; it's cdrkit's fault. Should this bug be filed elsewhere?

`readom` will detect the error, but it returns a success error code. I wrote a quick sh script wrapper to return a failed exit code. gnomebaker picks it up and reports a failed copy.

Here's what I did to test readom:

$ mkdir /tmp/tmpfs
$ sudo mount -t tmpfs -o size=10M,mode=0777 /dev/null /tmp/tmpfs
$ readom dev=/dev/sr0 f=/tmp/tmpfs/test.iso
Read speed: 8467 kB/s (CD 48x, DVD 6x).
Write speed: 8467 kB/s (CD 48x, DVD 6x).
Capacity: 1677248 Blocks = 3354496 kBytes = 3275 MBytes = 3435 prMB
Sectorsize: 2048 Bytes
Copy from SCSI (8,0,0) disk to file '/tmp/tmpfs/test.iso'
end: 1677248
addr: 5120 cnt: 64
readom: No space left on device. Cannot write '/tmp/tmpfs/test.iso'
addr: 5120
Time total: 4.603sec
Read 10240.00 kB at 2224.6 kB/sec.
$ echo $?
0
$ sudo umount /tmp/tmpfs
$ sudo rm -rf /tmp/tmpfs

[udude (igal)]

It's been a while since this bug saw some activity, but I'd like to try my luck anyway.
Tristan - how did you detect readom's silent failure? I'm trying to do something similar from a bash script
(bump...)

[Tristan (tristan-willy)]

It has been a while, but I do recall how it works. gnomebaker calls other tools, in this case readom, and checks the return codes from these tools. The problem is this part of my previous post:

$ readom dev=/dev/sr0 f=/tmp/tmpfs/test.iso
...
readom: No space left on device. Cannot write '/tmp/tmpfs/test.iso'
...
$ echo $?
0

So the problem is that readom detects an error, but returns a success exit code. The exit code should be non-zero for gnomebaker to detect the error.

[udude (igal)]

thanks for the fast reply. I apologize, I wasn't very clear in my question.
I'm calling readom from a different, custom script (not using gnomebaker).
In more detail, I'm instructing readom to create a cd/dvd image from optical media I place in the drive. Problem is, that if readom encounters bad blocks (used in various copy protections), it quits and exit status is 0 while I'd expect it to communicate the failure somehow (apart from the log). I'd hate to grep the output of readom for errors, it's too messy...

[Tristan (tristan-willy)]

I'm afraid you're stuck with grepping for errors without modifying the readom source. I worked around the bug by supplying a sufficient temp directory for gnomebaker to make the error I encountered unlikely.

A correct fix here is to fix readom to return with an error exit code when it detects errors. That said, readom was messy code that'd take a bit of work to fix when I initially investigated. Perhaps a quick mostly-correct strategy is to set a global static variable in readom with a desired exit code and have anything that attempts to print out errno codes (strerror() and such) set the global variable to something non-zero.

[Schily (schilling-fokus)]

readom is a very old version from the program readcd.

readcd is a descendent from a 23 year old demo/skeleton program that originally was
written to demonstrate the first SCSI pass through driver. Although readcd itself does a lot
of error checking and recovery, it was never tested for having a non-zero exit code for all
possible fatal errors - although it seems that it correctly exits with non-zero code in n - 2 cases.

While readom is unmaintained since ~2 years, the original software if of course still actively maintained.

Please fetch the latest original source from ftp://ftp.berlios.de/pub/cdrecord/alpha/
which currently is 2.01.01a56pre3 and test whether it fixes your problem.

Note that dev=/dev/sr0 is an deprecated device syntax that is not granted to work.

[Schily (schilling-fokus)]

Just a small additional comment. The original unmodified readcd program (even in
case it is very old) definitely does not exit(0) in your case but rather returns:

Condition not caught: file_write_err.

Abort - core dumped

exit code is 6 in this case.

The new readcd exits this way:

addr: 1000552 cnt: 28
readcd: No space left on device. Cannot write '/var/tmp/AA2'
addr: 1000552
Time total: 172.762sec
Read 2001104.00 kB at 11583.0 kB/sec.
2:52.806r 0.220u 7.620s 4% 0M 0+0k 0st 0+0io 0pf+0w
r# echo $?
28

[Thomas Hotz (thotz-deactivatedaccount)]

Confirming this bug.