Bug 195868 – cdrom.eclass: cdrom_get_cds sets CDROM_SET and CDROM_MATCH incorrectly when the check fails

• Status: RESOLVED FIXED
• Product: Gentoo Linux

[Description James Le Cuirot 2007-10-14 16:55:59 UTC]

A for loop is used to check for the existence of one of the given files. CDROM_SET and CDROM_MATCH are then set accordingly. But if none of the files are found, CDROM_SET and CDROM_MATCH incorrectly point to the last given file, indicating that the file was found when it wasn't. The script should probably "die" at this point.

[Comment 1 SpanKY 2007-10-14 21:58:21 UTC]

err, how ?  cdrom_load_next_cd should not return until the file is matched ... the only way out of the infinite loop is for either the user to abort or the file to be found ...

[Comment 2 James Le Cuirot 2007-10-14 22:13:29 UTC]

Heh I was trying to explain it so carefully that I forgot the crucial detail. It happens when CDROM_ROOT is given explicitly. A separate bit of code is used for that case. Check the cdrom_get_cds function where it says "now we see if the user gave use CD_ROOT ..."

[Comment 3 Jared B. 2010-07-09 01:40:21 UTC]

I've encountered this problem as well.  I believe the problem is in this logic (begins on line 1513 in eutils.eclass from 07/08/2010):

        for f in ${CDROM_CHECK_1//:/ } ; do
            ((++CDROM_SET))
            [[ -e ${CD_ROOT}/${f} ]] && break
        done
        export CDROM_MATCH=${f}
        return

It will return the last file searched and found, or the last file search if nothing was found.  Instead, I think something like this would be more appropriate:

        for f in ${CDROM_CHECK_1//:/ } ; do
            ((++CDROM_SET))
            if [[ -e ${CD_ROOT}/${f} ]]; then
                export CDROM_MATCH=${f}
                return
            fi
        done
        return

I'm not supplying an actual patch because I don't know what the expected behavior should be (I don't know how this ties in to ${CDROM_SET}, for example, which is where I see the problem on the ebuild side).  For example, maybe adding CDROM_MATCH='' or unset CDROM_MATCH would be more appropriate above the second return.  Either way, though, I can definitely confirm the bug.

Please also see bug 327549 for another, but I believe separate, issue in that block of code.

[Comment 4 James Le Cuirot 2017-03-14 22:44:29 UTC]

Heh I just ran into this again. I guess I should fix it now that I'm on the team! I was going to take Jared's approach but I notice that the non-CD_ROOT case uses "find -iname" instead of [[ -e ]] so it benefits from being case-insensitive. This would be handy for the CD_ROOT case too so I'll look at reworking it.

[Comment 5 James Le Cuirot 2017-04-05 20:41:18 UTC]

*** Bug 342269 has been marked as a duplicate of this bug. ***

[Comment 6 James Le Cuirot 2017-04-05 20:48:57 UTC]

*** Bug 373073 has been marked as a duplicate of this bug. ***

[Comment 7 James Le Cuirot 2017-04-27 21:51:17 UTC]

I ended up practically rewriting the eclass. The logic is now simpler and more consistent so this is no longer an issue.