From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020513

Description of problem:
Was trying to use minicom with /dev/usb/ttyUSB0.  Since I couldn't get the lock
file, I tried using --noinit and -o, which did not work.  Minicom was still
trying to get the lock file and failing.  Verified that using the vanilla
minicom source, the --noinit or -o option skipped grabbing the lock on the file.
 Checked out the Red Hat source RPM and found a minor change in the open_term
logic that was keeping the --noinit option from skipping lock file attempts.

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


How reproducible:
Always

Steps to Reproduce:
1.  Start up minicom (type "minicom").  If you haven't created a default or
something that works, do so now so you can go on to the next step.
2.  Assuming step one was successful, while minicom is still running, observe
lock files in /var/lock in another terminal.
3.  Quit out of minicom.
4.  Start up minicom with the --noinit option (type "minicom --noinit").
5.  Assuming step four was successful, while minicom is still running, observe
lock files in /var/lock from another terminal.  Since the --noinit option was
used, there shouldn't be lock files.


Actual Results:  Minicom attempts to create lock files even when the --noinit
option is used.  This kept me from opening /dev/usb/ttyUSB0 without using a lock
file.

Expected Results:  Minicom should have skipped lock file creation and merely
opened the port without checking if it could be locked.

Additional info:

I've created a patch, and new SRPM to fix the problem.  It's a one liner.  I'll
add them to the bug later.

Incidentally, this whole thing was stumbled upon because we have two copies of
ttyUSB0 in the dev tree (one in /dev/usb and one in /dev).  The lockdev package
was redirecting me to /dev/ttyUSB0 from /dev/usb/ttyUSB0 when it makes a call to
ttyname() from the dev_lock() call.  I figured out that I had to change the
perms on /dev/ttyUSB0.  Didn't even realize if was there until I debugged
lockdev a little.  I'm not sure whether to file a bug against lockdev or the dev
package.