Bug 208753 - Error when a module which is also a directory name is given to modinfo
Error when a module which is also a directory name is given to modinfo
Product: Fedora
Classification: Fedora
Component: module-init-tools (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jon Masters
Depends On:
  Show dependency treegraph
Reported: 2006-10-01 13:04 EDT by Radek Bíba
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-08-20 02:33:52 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Radek Bíba 2006-10-01 13:04:09 EDT
Description of problem:
If a user calls modinfo with a parameter that's also a name of a directory in
current working directory, modinfo complains that it's a directory. It's true
but it's not what is expected from modinfo.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
(For example: )
1. cd /lib/modules/`uname -r`/kernel/drivers/net
2. modinfo e1000
Actual results:
modinfo: could not open e1000: Is a directory

Expected results:
information about the given module, as it does when one runs the command in
another directory
Comment 1 Jon Masters 2006-11-10 06:12:41 EST
Yup. Good catch. I'll get modinfo fixed.
Comment 2 Jon Masters 2007-01-25 17:51:33 EST
Actually, not sure this is a bug since modinfo can also take a specific path as
an argument - yes, it might be nice to fallback in case it's a directory - but a
file is a directory at the end of the day...I'm not counting this as anything
but literally correct behavior at the moment.

Let me know what you think?

Comment 3 Radek Bíba 2007-01-26 02:31:08 EST
It may be a correct behavior from a programmer's point of view but it's not what
one would expect. I think modinfo should really accept a real (path to a) module
file or a module name, and not get into the described state if the given argument
happens to be a directory, especially when it's not a path (no slash in it).
Comment 4 Jon Masters 2007-08-20 02:33:52 EDT
Hmm. This is pre-existing behavior of m-i-t. I don't like it, but I don't
consider it a huge bug either. I will fix it upstream in due course.


Note You need to log in before you can comment on or make changes to this bug.