Well, not all the time. If I have netscape already running and then run up2date as myself (entering the root password), the netscape step will open up the proper page, but it appears to do it by telling my already existing copy of netscape (running as "eric" instead of "root") to open a window. Therefore when I click either submit button, I get a save dialog. This seems to happen whether I run up2date as "eric" or when I run up2date as "root" inside of an "eric" X session. If I exit netscape first, it works fine, since a new copy running as root is fired up. If I start up an X session as root and run it then, up2date works fine. I tried a workaround of placing this in my own .mailcap: application/redhat-package-list;/usr/sbin/up2date -p %s But I just get an error that up2date must be run as root. (Clearly, simply not having netscape already running is an easy workaround. But it seems to me that the mailcap entry should be more global and that up2date should do something like ask for the root password when run with the -p option, instead of simply informing me that it must be run as root.)
Remove /root/.netscape/lock before running up2date should fix the problem. It sees the stale lock file from a previous run of netscape by root, and so tries to send a command to the currently running netscape.
That does temporarily fix the problem. However, if I run netscape as root and exit normally, there is no lock file. Consistently, if I run up2date, when it runs netscape, there is a lock file left behind. I'd like to suggest 2 things: 1) figure out why the lock file gets erroneously left behind and fix that 2) Instead of just checking for a lockfile, check for a lockfile, and if it's found look at the information and determine if it's stale.
netscape has been modified for 6.2 to check the lockfile's validity before trusting it, fixing this problem.