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
__________________________________________________