Open
Bug 702045
Opened 13 years ago
Updated 1 year ago
Tracking bug: make Firefox able to survive a Windows System Restore
Categories
(Toolkit :: Application Update, defect, P3)
Tracking
()
NEW
People
(Reporter: blizzard, Unassigned)
References
(Depends on 3 open bugs)
Details
Attachments
(1 file)
13.57 KB,
text/xml
|
Details |
Right now Firefox does not survive a Windows system restore. This is because during a system snapshot only certain files are saved. We need to make sure that all of the files in our windows install have extensions that will be backed up when a system snapshot is made. We know that this affects hundreds of thousands of people during every release we do. Hang issues off this bug.
Reporter | ||
Comment 1•13 years ago
|
||
File names that are monitored for a system restore: http://msdn.microsoft.com/en-us/library/windows/desktop/aa378870%28v=vs.85%29.aspx
Comment 2•13 years ago
|
||
(In reply to Robert Strong [:rstrong] from bug 691847 comment 39) > Specifically iirc, unless there has been a complete restore point created > which is often not the case and we don't definitely create one at this time > because that could add several minutes to the update process. We are > evaluating creating the restore point with the service in the future after > we have the service. It is important to note that this has always been the > case regarding system restore and Firefox. 1. Under what conditions does creating a restore point take a long time? 2. How frequently does that happen? 3. Do we know if this is better or worse for particular versions of Windows or particular configurations that we can detect at runtime? Note that the document that blizzard links to says that those file extensions are monitored in VISTA or later--not necessarily XP. If we are going to continue along the "rename files" path, we need to find documentation that indicates that it will work on XP too. Basically, this is me asking if/why we really need to avoid having our installer do things the transactional(-ish?) way that Microsoft recommends and/or Windows requires to prevent these kinds of problems.
Comment 3•13 years ago
|
||
Whuck. How is it that JAR isn't on that list? Java's been big in enterprise, so can't help but wonder how this manages to not bite such Java apps. Or maybe it does? Also, is there no API to allow apps to control how system restore impacts them (not seeing it from a brief search)? CCing some platform integration folks who should really be involved with this.
Comment 4•13 years ago
|
||
(In reply to Christopher Blizzard (:blizzard) from comment #1) > File names that are monitored for a system restore: > > http://msdn.microsoft.com/en-us/library/windows/desktop/aa378870%28v=vs. > 85%29.aspx I verified that "ja" is in the filelist.xml on an XP machine in the office.
(In reply to Brian Smith (:bsmith) from comment #2) > Note that the document that blizzard links to says that those file > extensions are monitored in VISTA or later--not necessarily XP. If we are > going to continue along the "rename files" path, we need to find > documentation that indicates that it will work on XP too. From the link in comment 1, XP stores files in %windir%\WINDOWS\system32\Restore\filelist.xml In my XP virtual machine, this is what that xml file looks like.
Comment 6•13 years ago
|
||
Bug 701875 appears to be enough for firefox to mostly survive a system restore. I installed firefox, made a system restore point, and then deleted everything in the firefox directory. After restoring, we lose: - Dictionaries - Search plugins - The update channel prefs file .. or maybe not. I expected this one to go away but I see it's back again. - update.locale - This may be a problem since it appears that the updater throws a fit if it can't find this. However, it wouldn't be a problem in the normal system restore scenario if nobody deleted it. - blocklist.xml - NSS's .chk files - precomplete - removed-files - The default theme (so users wouldn't be able to switch back to the default theme)
Comment 7•13 years ago
|
||
This wasn't implied in Comment 6, but just to be clear I wanted to add that from any system restore, it won't remove the file types that aren't included in that system restore point. So comment 6 mentioned a directory that had no dictionaries, search plugins, ... That test was useful to see what was included, but that exact scenario would only happen if the user uninstalled or deleted Firefox before running the system restore. So let's say a user restores to 3 weeks ago, they will still have the dictionaries, search plugins, ..., but they will be the current ones, and not the ones from 3 weeks ago. But having files that are consistent with each other is obviously important if they are not backwards compatible.
Comment 8•13 years ago
|
||
> 3. Do we know if this is better or worse for particular versions of > Windows or particular configurations that we can detect at runtime? Windows Vista and Windows 7 rely on volume shadow copy so they create restore points much faster. For me it only takes about 15 secons on my development machine. XP works by file copy and compression so is slower. Also people cusotmize filelist.xml so it gets slower and slower as you get more stuff on your computer. The server operating systems don't have system restore installed by default, but you can install it. Other than providing our own rollbacks for updates, I'm not sure what benefit creating our own system restore points would give us. Creating system restore points ourselves would be nice to have but not related to this bug. omni.jar was obviously important, but I'm not sure which of the list of Comment 6 are the important non backwards compatible files. If it wasn't for omni.jar I don't think this bug would have been noticed. But its' definitely something to look out for. For the files that will always be backwards compatible, if any, if a user decides to uninstall or delete all of our files, I'm not sure that system restore should be a supported way for us to be re-installed.
(In reply to Brian R. Bondy [:bbondy] from comment #8) > > 3. Do we know if this is better or worse for particular versions of > > Windows or particular configurations that we can detect at runtime? > > Windows Vista and Windows 7 rely on volume shadow copy so they create > restore points much faster. of note here is the volume shadow copy service backs up all files on the volume, so this bug should be limited to xp users only (http://blog.szynalski.com/2009/11/23/volume-shadow-copy-system-restore/ and http://technet.microsoft.com/en-us/library/ee923636%28WS.10%29.aspx). > For the files that will always be backwards compatible, if any, if a user > decides to uninstall or delete all of our files, I'm not sure that system > restore should be a supported way for us to be re-installed. we should at least detect it, and provide the means for the user to get firefox back to a working state. an option may be to keep a copy of the setup executable and offer to launch this after firefox is partially restored by system-restore.
Comment 10•13 years ago
|
||
> so this bug should be limited to xp users only
It still only protects a filtered file list on Vista and Win7.
Comment 11•13 years ago
|
||
(In reply to Brian Smith (:bsmith) from comment #2) > (In reply to Robert Strong [:rstrong] from bug 691847 comment 39) > > Specifically iirc, unless there has been a complete restore point created > > which is often not the case and we don't definitely create one at this time > > because that could add several minutes to the update process. We are > > evaluating creating the restore point with the service in the future after > > we have the service. It is important to note that this has always been the > > case regarding system restore and Firefox. > > 1. Under what conditions does creating a restore point take a long time? As I understand it this is dependent on how many changes since the last restore point was created and as bbondy points out it is slower on XP and below. > 2. How frequently does that happen? In my experience often which is entirely anecdotal > 3. Do we know if this is better or worse for particular versions of Windows > or particular configurations that we can detect at runtime? XP > Note that the document that blizzard links to says that those file > extensions are monitored in VISTA or later--not necessarily XP. If we are > going to continue along the "rename files" path, we need to find > documentation that indicates that it will work on XP too. > > Basically, this is me asking if/why we really need to avoid having our > installer do things the transactional(-ish?) way that Microsoft recommends > and/or Windows requires to prevent these kinds of problems. I think you think I don't want to create restore point which is not the case at all. Restore points need to be created prior to changing files / registry and iirc requires admin privileges. So, without going into the specific details based on the previous sentence, using the maintenance service to create a restore point is viable from a technical and a UX point of view where as without the maintenance service... not so much.
Comment 12•13 years ago
|
||
The following is not applicable to the case where someone manually deletes the installation directory and then performs a system restore and IMO this is a case that we shouldn't try to fix. First off, updates still work per Juan's investigation and I have also verified this - blocklist.xml Used on first run when we don't have a blocklist.xml in the profile. A minor issue as I see it. - NSS's .chk files These being out of sync will disable FIPS mode A serious issue for organizations that require FIPS mode. Users in these organizations should not be able to system restore since they would need admin privileges which would also allow them to disable FIPS themselves so I think this is less of an issue than initially thought. - precomplete Used to remove old application files prior to a complete update Not a serious issue as I see it. - removed-files Not used by applications (I have plans to remove it though doing so is extremely low priority) Not an issue - install.log Not used by applications Not an issue - The default theme The default theme metadata will not be rolled back, the default theme will be reported as incompatible, and the newer default theme images will be left in place. Medium issue - even though the default theme is displayed as incompatible the default theme can still be selected / enabled. - dictionaries, hyphenation, and searchplugins Newer files will be left behind Not a serious issue to have the newer files as I see it though a format change could cause problems. - channel-prefs.js This file is not updated during an update Not an issue - dependentlibs.list Tested with the file missing, with entries that don't exist, and with missing entries. Everything worked fine. Also took a look at the code and it appears to fallback gracefully. Quite certain this is not an issue. Reference: bug 298044 - uninstall.log Doesn't affect Firefox use but could affect Firefox uninstall. If there are dll / exe files in the older build that don't exist in the newer build then uninstalling won't remove these files. Minor issue As I see it, renaming omni.jar to omni.ja is a good thing to do and we can address the remaining items above as time permits.
Comment 13•13 years ago
|
||
bug 577563 will make the uninstall.log participate in session restore
Depends on: 577563
Updated•12 years ago
|
Flags: in-litmus?
Comment 14•11 years ago
|
||
(In reply to Robert Strong [:rstrong] (do not email) from comment #12) > The following is not applicable to the case where someone manually deletes > the installation directory and then performs a system restore and IMO this > is a case that we shouldn't try to fix. What about bookmarks & history, saved passwords, cookies ? Should they be restored ?
Comment 15•11 years ago
|
||
(In reply to Paul Silaghi [QA] from comment #14) > (In reply to Robert Strong [:rstrong] (do not email) from comment #12) > > The following is not applicable to the case where someone manually deletes > > the installation directory and then performs a system restore and IMO this > > is a case that we shouldn't try to fix. > What about bookmarks & history, saved passwords, cookies ? Should they be > restored ? Note: the point I was making with the above statement is that system restore is a first in first out system so deleting the files and then performing a restore can cause files that haven't been backed up for a while to no longer be present when restoring the directory. As for files in the profile they will be restored as long as there is still a copy of the file in system restore.
Comment 16•2 years ago
|
||
In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.
Severity: major → --
Updated•1 year ago
|
Component: General → Widget: Win32
Updated•1 year ago
|
Severity: -- → S3
Component: Widget: Win32 → Application Update
Priority: -- → P3
Product: Core → Toolkit
You need to log in
before you can comment on or make changes to this bug.
Description
•