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




10 years ago
9 years ago


(Reporter: kukulski, Assigned: jrmuizel)


1.9.0 Branch
Windows XP

Firefox Tracking Flags

(status1.9.1 wontfix)




10 years ago
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.

Comment 1

10 years ago
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.


10 years ago
Assignee: nobody → jmuizelaar

Comment 2

10 years ago
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

Comment 3

9 years ago
I don't think it's worth doing anything at this point.
Last Resolved: 9 years ago
status1.9.1: --- → wontfix
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.