Closed Bug 491572 Opened 11 years ago Closed 10 years ago

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


(Core :: GFX: Color Management, defect)

1.9.0 Branch
Windows XP
Not set



Tracking Status
status1.9.1 --- wontfix


(Reporter: kukulski, Assigned: jrmuizel)


User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv: Gecko/2009042315 Firefox/3.0.10
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: 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.
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.
Assignee: nobody → jmuizelaar
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?
Version: unspecified → 1.9.0 Branch
I don't think it's worth doing anything at this point.
Closed: 10 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.