Bug 134433 - gconftool-2 hangs when TMP is set to not existing location
Summary: gconftool-2 hangs when TMP is set to not existing location
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: GConf2
Version: 2
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Ray Strode [halfline]
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-10-02 15:35 UTC by Peter Englmaier
Modified: 2008-05-01 15:38 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-05-11 21:35:05 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Peter Englmaier 2004-10-02 15:35:41 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3)
Gecko/20040922

Description of problem:
When moving to a new machine, a user copied his .tcshrc
He made sure, that 'tcsh --login' worked with the new setup.
However, after he logged out, he could not log in using GNOME.
When logging in with KDE, he couldn't run tools like oowriter.

This was caused by having set the TMP variable to a nonexisting 
location (the user simply didn't yet create this tmp directory).

While beeing the users fault, it is clearly an obstacle for
many users. The hang was caused by gconftool-2.

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

How reproducible:
Always

Steps to Reproduce:
1. using bash shell, enter:
   $ TMP=/undefined_location gconftool-2 --get /blub
   -command hangs indefinitly-

Compare this to:
   $ gconftool-2 --get /blub
   No value set for `/blub'
   $ 

Actual Results:  gconftool-2 was not returning. A strace revealed it
wanted to
create temporary files.

Expected Results:  Rapid return with success or failure (depending on
wether /blub exists or not).


Additional info:

My suggestion is, to add a test to gconftool-2 such, that it
prints an error message if a temporary file cannot be created or
it runs out of disk space while doing so.

Comment 1 Matthew Miller 2005-04-26 16:37:50 UTC
Fedora Core 2 is now maintained by the Fedora Legacy project for
security updates only. If this problem is a security issue, please
reopen and reassign to the Fedora Legacy product. If it is not a
security issue and hasn't been resolved in the current FC3 updates or
in the FC4 test release, reopen and change the version to match.

Comment 2 Ray Strode [halfline] 2005-05-11 21:35:05 UTC
Hi,

This bug is being closed because it has been in the NEEDINFO state for a long
time now.  Feel free to reopen the bug report if the problem still happens for
you and you can provide any information that was requested.


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