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
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:18.104.22.168) Gecko/2009042315 Firefox/3.0.10 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:22.214.171.124) 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.
11 years ago
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.
You need to log in before you can comment on or make changes to this bug.