The new rpm is in the testing area.

ftp://ftp.scientificlinux.org/linux/scientific/40rolling/testing/i386/RPMS/browsers/SL_firefox_parentlock_fix-1.0-6.noarch.rpm

or

   rpm -e SL_firefox_parentlock_fix
   yum --enablerepo=sl-testing install SL_firefox_parentlock_fix

Troy

Troy Dawson wrote:
> We just had a user where the
> 
> ---
> APP_FOLDER="\$HOME/.thunderbird"
> find "\$APP_FOLDER" -noleaf -type d -maxdepth 1 -mindepth 1 | while read 
> i; do
> ---
> 
> section didn't work.  The problem was that their thunderbird directory 
> was at
> $HOME/.thunderbird/default/<random>/
> 
> I hadn't had a problem on firefox or thunderbird with the original check 
> which was
> 
> ----
> APP_FOLDER="\$HOME/.thunderbird"
> for i in $(grep Path= $APP_FOLDER/profiles.ini | sed s/Path=//); do
> ----
> 
> So I'm going to go back to that one for thunderbird and firefox, but 
> leave seamonkey the way it is.
> 
> Troy
> 
> Troy Dawson wrote:
>> Stephan Wiesand wrote:
>>> Hi Troy,
>>>
>>> On Tue, 19 Sep 2006, Troy Dawson wrote:
>>>
>>>> Stephan Wiesand wrote:
>>>>> Hi Troy,
>>>>>
>>>>> there were still a couple of minor problems. For example, it's 
>>>>> broken on 64bit. And I really didn't understand the [ ! -a 
>>>>> <filename> ] tests.
>>>>>
>>>>
>>>> Thanks for the 64bit solution, I had forgotten about that.
>>>>
>>>> About the test
>>>>
>>>> [ ! -a $line/<filename> ]
>>>>
>>>> It is just checking to see if the file is there.  If there is a file 
>>>> there, I am assuming that we don't want to mess with it.  I also 
>>>> figure that if the file is there, then the directory is there.
>>>
>>> But shouldn't that be "[ ! -e" instead? The above seems to always 
>>> evaluate to true. Maybe it's some black magic I don't get yet?
>>>
>>
>> Ah ... it's from my "unix in a nutshell" book, the test conditions 
>> page.  But now that I double check, it says the this is a Korn shell 
>> option.  But it is the check for "file exists".
>> Of course when I look through the man page, -e is for "file exists" 
>> and -a is for comparing two values.  Hmmm ... maybe when there isn't 
>> anything infront of the -a, it defaults back to checking if the file 
>> exists.  It works, but yes, I think sticking with the man page would 
>> be best.
>>
>>>> [ -d "$line" -a ! -e "$line/%{cleanscript}" ]
>>>>
>>>> Although your solution is more thorough, it just seems redundant, 
>>>> doing two checks instead of one (unless I'm reading it wrong).
>>>
>>> I agree it's a bit paranoid, but then this runs with root privileges, 
>>> and I wouldn't swear that the glob above will never ever return 
>>> anything weird, no matter under what circumstances. Also, I think
>>> [ ! -e "$line/%{cleanscript}" ] is not a guarantee that $line exists 
>>> and is a directory, is it?
>>>
>>
>> I think your right.  Let's go with your rpm as it stands.
>> I'm going to recompile and resign it, so that it's consistant with the 
>> same key and build machine as the rest of the errata.
>>
>> Troy
>>
>>> Cheers,
>>>     Stephan
>>>
>>>>> I've put up a a slightly hacked version here:
>>>>>   http://www-zeuthen.desy.de/~wiesand/parentlock/
>>>>>
>>>>> Cheers,
>>>>>     Stephan
>>>>>
>>>>> On Mon, 18 Sep 2006, Troy Dawson wrote:
>>>>>
>>>>>> Hello,
>>>>>> This rpm is designed to fix the "Home Area in AFS" parentlock fix.
>>>>>>
>>>>>> The problem is triggered when your home area is in AFS, and you 
>>>>>> use firefox, thunderbird, and/or seamonkey.  Not always, but 
>>>>>> often, when you stop and restart firefox (or thunderbird, or 
>>>>>> seamonkey) the lock file, called parentlock, is not removed.  This 
>>>>>> makes it hard to start up your browser again.
>>>>>>
>>>>>> Ftp:
>>>>>> ftp://ftp.scientificlinux.org/linux/scientific/30rolling/testing/i386/RPMS/browsers/SL_firefox_parentlock_fix-1.0-3.noarch.rpm 
>>>>>> ftp://ftp.scientificlinux.org/linux/scientific/40rolling/testing/i386/RPMS/browsers/SL_firefox_parentlock_fix-1.0-3.noarch.rpm 
>>>>>>
>>>>>> Yum - S.L. 4.x
>>>>>>  yum --enablerepo=sl-testing install SL_firefox_parentlock_fix
>>>>>>
>>>>>> The rpm has already been tested on several computers, and we 
>>>>>> believe it works well.  But we would like others to test it more 
>>>>>> before it goes out.
>>>>>>
>>>>>> Thanks
>>>>>> Troy
> 
> 


-- 
__________________________________________________
Troy Dawson  [log in to unmask]  (630)840-6468
Fermilab  ComputingDivision/CSS  CSI Group
__________________________________________________