Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 195868 - cdrom.eclass: cdrom_get_cds sets CDROM_SET and CDROM_MATCH incorrectly when the check fails
Summary: cdrom.eclass: cdrom_get_cds sets CDROM_SET and CDROM_MATCH incorrectly when t...
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Eclasses (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo Games
: 342269 373073 (view as bug list)
Depends on:
Reported: 2007-10-14 16:55 UTC by James Le Cuirot
Modified: 2017-04-27 21:51 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description James Le Cuirot gentoo-dev 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 gentoo-dev 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 gentoo-dev 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
            [[ -e ${CD_ROOT}/${f} ]] && break
        export CDROM_MATCH=${f}

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
            if [[ -e ${CD_ROOT}/${f} ]]; then
                export CDROM_MATCH=${f}

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 gentoo-dev 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 gentoo-dev 2017-04-05 20:41:18 UTC
*** Bug 342269 has been marked as a duplicate of this bug. ***
Comment 6 James Le Cuirot gentoo-dev 2017-04-05 20:48:57 UTC
*** Bug 373073 has been marked as a duplicate of this bug. ***
Comment 7 James Le Cuirot gentoo-dev 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.