491572 - read lock on file named by gfx.color_management.display_profile prevents rename or deletion

Status: RESOLVED WONTFIX

(Core :: Graphics: Color Management, defect)

Description

[Timothy Kukulski]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.10) Gecko/2009042315 Firefox/3.0.10
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.8) Gecko/2009032609 Firefox/3.0.8

When color management is enabled, firefox holds a read lock on the file specified by gfx.color_management.display_profile -- e.g: C:\WINDOWS\system32\spool\drivers\color\sRGB Color Space Profile.icm  

This prevents the file from being renamed or deleted (i.e: replaced). 

As a result, if Firefox is running, installers (e.g: Adobe Creative Suite) fail when attempting to replace this file. (In practice, the result is that installers that might update any color profiles require the user to quit firefox before continuing.)

Reproducible: Always

Steps to Reproduce:
1. set gfx.color_management.enabled to true
2. set gfx.color_management.display_profile to C:\WINDOWS\system32\spool\drivers\color\sRGB Color Space Profile.icm
3. restart firefox
4. attempt to rename C:\WINDOWS\system32\spool\drivers\color\sRGB Color Space Profile.icm
4a. (alternate) -- use a utility such as OpenedFilesView to see that firefox has the following locks on the file: Read, Shared Read, Shared Write
Actual Results:  
windows alert: title: "Error renaming file or folder"
text: Cannot rename sRGB Color Space Profile: It is being used by another person or program. Close any programs that might be using the file and try again. 

(attempt to delete produces similar results)

Expected Results:  
firefox should not be holding a lock on the file.

Comment 1

[Timothy Kukulski]

This is one of the leading gripes against the install/update process. Once this is resolved, future updates need not ask the user to quit Firefox before proceeding.

Comment 2

[Jeff Muizelaar [:jrmuizel]]

lcms holds the profile file open for the entire lifetime of the profile object. qcms doesn't have this problem, so this should be fixed on trunk and in 3.5. I'm not sure what/if we should do anything about this for 3.0.x. Vlad?

Comment 3

[Jeff Muizelaar [:jrmuizel]]

I don't think it's worth doing anything at this point.