Silent failure when out of /tmp space

Would you be willing to provide a patch for this?

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

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...)

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.

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...

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.

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.

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

Confirming this bug.