311667 - Different lock-file-names on different OS - Cross platform users could loose their data

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Profile: BackEnd, defect)

Description

[Alex Ihrig [:Thunderbird_Mail_DE]]

Mozilla applications protect their profiles with a lock file, when running. The
lock file should protect from using a profile with more than one copy of the
application at the same time.

Some people use Mozilla applications on different platforms in a netwerk
environment at the same time. They should be protected to use one profile over
the netwerk from different machines. But they aren't protected because of
different lock file names on different OS:

Windows: "parent.lock"
Mac OS X: ".parentlock"
Linux: ?

We should have the same file name on all platforms. Maybe Windows isn't able to
handle ".parentlock" as file name, so I would prefer to have "parent.lock" on
all platforms. "parent.lock" wouldn't be hidden in unix, but this shouldn't be a
problem.

IMHO it would be a good idea to have the lock file visible on all platforms.
This would make live easier after an application crash - users could see the
lock file and would be able to remove it, so the profile could be used again
after a crash. This would make support easier.

Comment 1

[timeless]

this always bothered me ...

Comment 2

[Boris Zbarsky [:bzbarsky]]

Alexander, are you working on this?

Comment 3

[Alex Ihrig [:Thunderbird_Mail_DE]]

Sorry, I'm not able to do this in C++, so we've to reasign this bug.

http://lxr.mozilla.org/seamonkey/source/profile/dirserviceprovider/src/nsProfileLock.cpp#425
http://lxr.mozilla.org/mozilla1.8/source/profile/dirserviceprovider/src/nsProfileLock.cpp#425

Comment 4

[Boris Zbarsky [:bzbarsky]]

So is there a good reason we do have different filenames?  If not, it's a trivial change to just remove the ifdefs....

Comment 5

[Boris Zbarsky [:bzbarsky]]

For what it's worth, the name difference was there in the initial checkin in bug 76431.

Comment 6

[Benjamin Smedberg]

There was not a good reason initially, AFAICT, but we're stuck with the names now.

Comment 7

[Boris Zbarsky [:bzbarsky]]

> but we're stuck with the names now.

Are we?  We can recognize the old lock files as lock files while using a new name for our new ones.  Or even create both.

I do think the problem this bug describes is a serious one, especially on college networks.

Comment 8

[Benjamin Smedberg]

> Are we?  We can recognize the old lock files as lock files while using a new
> name for our new ones.  Or even create both.

Since profiles are not versioned, we would have to create both. I'm not convinced that the use-case of sharing profiles across OSes is worth fixing, though. Each platform uses a different mechanism to lock profiles in any case.

Comment 9

[Hermann Schwab]

(In reply to comment #8)
> > Are we?  We can recognize the old lock files as lock files while using a new
> > name for our new ones.  Or even create both.
> 
> Since profiles are not versioned, we would have to create both. I'm not
> convinced that the use-case of sharing profiles across OSes is worth fixing,
> though. Each platform uses a different mechanism to lock profiles in any case.

If you can't get rid of the old mechanism a new one is of no use. But why can't we start versioning profiles? 
Of course that's not important for normal users, but it will be important for the 'wannabe' power users, the users marketing can't buffalo by using other names instead of firefox. Simple versioning, just giving a warning could have prevented some trouble with apostrophs in bookmark files when switching between 1.7 and then 1.8-trunk browsers back and forth. I'm using -profilemanager, but often just click start instead of changing to the correct profile.

Comment 10

[Boris Zbarsky [:bzbarsky]]

Benjamin, for what it's worth I've been bitten by this bug a number of times over the last 6 years or so... Hence my wanting it fixed; I can stop worrying about profile corruption every time I start a browser on campus.

Comment 11

[(no longer active)]

Taking over...

Comment 12

[(no longer active)]

Hmmm, is there any special reason why the profile locking is implemented the way it is?  Couldn't we use a simpler implementation, such as below:

nsProfileLock::Lock(aProfileDir)
{
  NS_NAMED_LITERAL_STRING(LOCKFILE_NAME, "some name");
  if (a file named LOCKFILE_NAME exists in aProfileDir) {
    fail
  }
  else {
    mHaveLock = PR_TRUE;
  }
}

The way the current code works, unifying the file name doesn't solve the problem, as mentioned in comment 8.

If a simple scheme like I suggested above works for us, then we can have a new name defined which would be the same across all platforms, which would be used to create new profiles, which can be checked for across different machines/platforms.

Comment 13

[(no longer active)]

Updating to reality: I won't have the time to work on this for the foreseeable future!

Comment 14

[Benjamin Smedberg]

This bug is filed in a bugzilla component related to pre-Firefox code which no longer exists. I believe it is no longer relevant and I am therefore closing it INCOMPLETE.

If you believe that this bug is still valid and needs to be fixed, please reopen it and move it to the Toolkit:Startup and Profile System product/component.