279883 - Profile is locked altough there is no lockfile inside

Status: RESOLVED INCOMPLETE

(Thunderbird :: General, defect)

Description

[Bohdan Linda]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

After crash of Thunderbird, I am no table to open my profile. Profile manager
states that the profile is locked, altough nolock file is present within the
profile. To give you summary:
-- no parent.lock (or any lock) file is present in the profile
-- no stale thunderbird instance is running in OS
-- it remains locked after reboot.

I have kept the profile for further examination, thus upon request I can perform
an analysis. 

Reproducible: Couldn't Reproduce

Steps to Reproduce:
None
Actual Results:  
Can't access my profile

Expected Results:  
Launch TB with requested profile

Comment 1

[P. Henrique Silva]

The same thing happens to me with Firefox 1.0.1 (also do with 1.0). Profile
Manager state that a profile it's in use, but there are no lock file or any
instance running.

Firefox 1.0.1
SUSE 9.1
linux 2.6.4

Couldn't reproduce.

Comment 2

[Alexander Kohr]

Problem: In Macintosh thunderbird 1.0.6 20050716. It complains that the profile is in use yet there is 
no lock file. (profile was last used & exhibited similar results in Thunderbird 1.0.5 occurred due to a 
crash.)

reproducible.
This only seems to happen when the program crashes and not every time it crashes. We had very 
similar issues under Mozilla 1.6(possibly earlier) through 1.7.2 so problem is probably in the older 
shared code base. this also occurred across mac os 10.1.x through 10.3.9 for mozilla. The thunderbird 
instance occurred under 10.3.9  Under Mozilla this also occurs on multiple macintosh computers for 
different users in our organization. This is the first instance under thunderbird and thunderbird seems 
to be stabler as the user has crashed twice before & it did not occur under mozilla this would have been 
the third time it happened.

Workaround. 
Create a new profile and quit mozilla delete all of the files in the new profile. Copy all but the 
xul.fastload files from the old profile into the new profile's empty folder & launch. (I do not copy the old 
profiles xul.fastload file as in mozilla it would sometimes cause the copied profile not to work until it 
was deleted)(just deleteing xul.fastload was not sufficient to solve the in use problem.

Comment 3

[Alexander Kohr]

I think the problem for the macintosh version is different than that for windows.It seems that you stopped using a visible file for locking & started using a hidden dot file called .parentlock that unless you use the terminal and to do an ls -a you will never see it. For our site on the macintoshes removing the hidden  .parentlock file on the mac resolves the  issue. 
If you thunderbird started using a hidden file in windows this might be the problem for that user as well but it would not be just because you started using a .file it would be because the hidden attribute was set.
-alex

Comment 4

[Wayne Mery (:wsmwk)]

Henrique Silva , Alexander,

do you still see this problem in version 1.5 or version 2? 
(reporter no longer uses thunderbird)

Comment 5

[Alexander Kohr]

It apears that my problem was different from the initial .parentlock hidden file comment. However I think it is different for an entirely different reason as well. We use nfs for out home directory server & there where two fixes that worked one was forcing the clients to use TCP instead of UDP for their nfs connections the other was that the networking group claims tha didn't but definetaly did change something with configuration of the routing domain/vlan that had all of the problem computers in it. At that time over 1/2 of the problem computers have not bee changed over to tcp mounts 

I have since the "no network change was performed"  change, changed the mounts for all macintoshes in all routing domains/vlans to be nfs over tcp by default. Therefor I will probably never see the problem again. 

Comment 6

[Alexander Kohr]

The reason that nfs over tcp works and nfs over udp does not is because TCP  acknowledgmens the reciept of packets and UDP does not. Therfore if it was not acknowleged by TCP it would retransmit until it was acknowleged however using udp the client computer would be non the wiser as it was not expecting an acknowledgment and would not retranmit the change of status of the lock file. 

Comment 7

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Does the issue still occur in the latest supported Thunderbird 2.0.0.x or trunk nightlies?

Comment 8

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

No additional useful information since last comment -> resolving incomplete.

Please comment if the issue still occurs in the latest supported 2.0.0.14 / trunk nightlies.