The .lock file shouldn't prevent LR from loading

  • 1
  • Problem
  • Updated 2 years ago
  • (Edited)
There's something that I have always considered as a design/programming problem and that I'd like to comment now.

When Lightroom didn't terminate correctly or because there was a power shortage or a system crash during the execution of LR, the catalog lock (.lock file with the same name as the catalog) might not be deleted. This can prevent LR from loading, especially when the "Load most recent catalog" option is enabled. IMHO, this shouldn't happen.

Obviously, LR tries to avoid two things when loading :

- Running two instances of lightroom.exe
- Opening the same catalog twice.

This should be controlled by two different mechanisms, instead of using only the .lock file. Preventing 2 instances of lightroom.exe from running side-by-side can be achieved by using a mutex (among other possibilities based on a system object). If the .lock file is still present when LR starts and tries to open the last used catalog, this shouldn't prevent LR from loading. LR should display a message to the user, giving him/her the choice to either load another catalog or to unlock the target catalog (that is, to delete the .lock file).

If one considers the number of posts to the Adobe forums and the number of messages sent to the support saying "I can no longer launch LR" and considering that the answer is most of the time "Delete the .lock file that is stored with your catalog", I think it's now time to allow LR to boot even when this file exists. A lot of people would then avoid spending a lot of time explaining the same problem again and again.
Photo of Patrick Philippot

Patrick Philippot

  • 316 Posts
  • 47 Reply Likes
  • frustrated

Posted 2 years ago

  • 1
Photo of Rikk Flohr

Rikk Flohr, Champion

  • 1373 Posts
  • 334 Reply Likes
The Lock file is a construct of the SQL-LIte platform on which Lightroom is built.  Unless I am mistaken, it would require a complete ground-up rewrite of Lightroom to accomplish this.  
Photo of Patrick Philippot

Patrick Philippot

  • 316 Posts
  • 47 Reply Likes
Hi Rikk,
it would require a complete ground-up rewrite of Lightroom to accomplish this.
Not at all. There's no need to change or replace the SQLite code.  LR can easily detect the presence of this file and adapt its behavior if it detects something wrong. And if LR is starting and trying to open a catalog for which this lock file exists, there's actually something wrong that LR should be able to handle.

As explained above, if LR used another mechanism to detect an already running instance, there would be no problem. Maybe it does but in that case, I don't understand why the presence of this lock file prevents it from loading.

From a developer's point of view, before opening a catalog, it's very easy to check the presence of the lock file (before making any function call into the SQLite database) and to ask the user what to do. Currently, it seems that LR doesn't make any check and finds itself "auto-locked" because SQLite refuses to open the database. Then LR waits for ever until someone kills the process.
Photo of Victoria Bampton - Lightroom Queen

Victoria Bampton - Lightroom Queen, Champion

  • 4133 Posts
  • 1473 Reply Likes
It does check for the lock file and remove it automatically in most cases, which is why there are far fewer reports these days. I agree it could be useful to display a message describing why it might be unable to open though.
Photo of Patrick Philippot

Patrick Philippot

  • 316 Posts
  • 47 Reply Likes
Hi Victoria,

Do you know when this check was implemented? After 6.0 ? It seems that the problem is still there with recent versions of LR.
Photo of Victoria Bampton - Lightroom Queen

Victoria Bampton - Lightroom Queen, Champion

  • 4133 Posts
  • 1473 Reply Likes
The last engineering conversation I had on the subject was mid-2013, so way before LR6.
Photo of Reinard Schmitz

Reinard Schmitz

  • 55 Posts
  • 7 Reply Likes
It's really easy to check the lock file, ask the user and do the 'delete' for him – an evident service... :-)
Photo of Simon Chen

Simon Chen, Principal Computer Scientist

  • 1417 Posts
  • 437 Reply Likes
That won't do the user any good -- because the other instance of Lightroom is still possibly running and might have the problem of concurrently writing to the same database, potentially corrupting the database.
Photo of Patrick Philippot

Patrick Philippot

  • 316 Posts
  • 47 Reply Likes
If a second instance of lightroom.exe uses a mutex to detect an already running instance *before* trying to access any catalog, there will be no problem.
Photo of Chris Cox

Chris Cox

  • 20280 Posts
  • 812 Reply Likes
A mutex is a per-process thing, and can't easily be shared between processes.
A .lock file is a inter-process mutex via the file system.
Photo of Patrick Philippot

Patrick Philippot

  • 316 Posts
  • 47 Reply Likes
> A mutex is a per-process thing

Not a global mutex created in the \Global namespace (at least under WIndows)
Photo of Patrick Philippot

Patrick Philippot

  • 316 Posts
  • 47 Reply Likes
See the CreateMutex API at least under Windows - I'm sure that there's some equivalent under the Mac OS. In all applications that I have written, I have always used a mutex to prevent multiple instances  from running side-by-side.
Photo of Patrick Philippot

Patrick Philippot

  • 316 Posts
  • 47 Reply Likes
Actually, a named mutex can be shared between processes in order to synchronize these processes. Only an unnamed mutex is more difficult to share because other processes need to get the handle. The DuplicateHandle API can help in that case.
(Edited)