Now that FF has a sync feature, and assuming that there are folks who are ok with their data being stored on the cloud, does it still make sense to have a backup process using MozBackup?
More background:
I have a script that I use to take a zip of the complete profile folder, and move it from time-to-time onto my cloud backups. But, since FF Sync does all the backups (including preferences, open tabs, bookmarks, installed extensions, themes), I am not sure if I still need such a manual backup. as long as I click the "Sync now" button/menu item from time-to-time, can I rest assured that my offline backup is no longer needed?
I found out that the FF Sync does indeed sync the preferences, installed addons, etc, and all the open tabs on the first machine showed up in the "sync sidebar" on the second machine as well. BUT, the synced tabs lose a couple of important "features"
The order of the open tabs is messed up
The status of whether tab was pinned or not was also lost.
With the above, at this point, I feel I still need to continue with a full-backup of the profile folder.
Related
I would like to restore not the last "Restore Previous Session".
Open firefox (v78.0) with few tabs: aaa.com, bbb.com.
Close Firefox.
Open Firefox, open few tabs, ccc.com, ddd.com.
Close Firefox.
Open Firefox. How to get those tabs aaa.com, bbb.com from "Restore Previous Session"?
I went to the address bar of Firefox, typed about:support and saw which is the profile folder of Firefox.
I figured out that some versions of Firefox create a
c:\Users\MY_USER\AppData\Roaming\Mozilla\Firefox\Profiles\j1hcxbyk.default-release\sessionstore.jsonlz4 file when Firefox is closed.
I also found a copy of a session file
c:\Users\MY_USER\AppData\Roaming\Mozilla\Firefox\Profiles\j1hcxbyk.default-release\sessionstore-backups\upgrade.jsonlz4-20200630195452
So, I:
stopped Firefox,
made a back-up copy of the profile folder,
replaced sessionstore.jsonlz4 (or copied there if that file didn't exist) with upgrade.jsonlz4-20200630195452,
started Firefox,
restored the previous session with: Menu->History->Restore Previous Session,
checked that the old session, with my tabs, was restored.
Note: I chose upgrade.jsonlz4-20200630195452 because it was created in the same day, when I closed Firefox with all my tabs.
Recently, I faced the same issue of missing tabs when I restored the correct system date from some earlier date. After scouring the internet, I got the following tip to restore the firefox tabs back from saved sessions. My PC runs Microsoft Windows 10 Home with Firefox version 91.0.
Reference: https://support.mozilla.org/en-US/questions/1314940
"At startup, Firefox usually will look first for sessionstore.jsonlz4 at the main level of your profile folder and if it finds it, use its contents to create recovery.jsonlz4 -- if you restore automatically -- or previous.jsonlz4 -- if you do not restore automatically. So you could try replacing that file if you haven't already (as well as recovery.jsonlz4)".
Close the firefox browser.
Open %AppData%/Mozilla/Firefox/Profiles folder
Select the latest folder that contains .default in it.
Open sessionstore-backups folder. Now your path would be something like %AppData%\Mozilla\Firefox\Profiles\13dn9aq1.default-1473265690957-1560267471460\sessionstore-backups
Locate files with upgrade.jsonlz4- prefix and select the one which you think probably would contain your tabs.
Keep the original one untouched. Create a copy of it and rename it to sessionstore.jsonlz4
Copy the sessionstore.jsonlz4 file. Locate the sessionstore.jsonlz4 file in the folder one level down: %AppData%\Mozilla\Firefox\Profiles\13dn9aq1.default-1473265690957-1560267471460\ and replace it with the sessionstore.jsonlz4 file just copied.
Now you can open Firefox and you will get all your old tabs from the restored session.
The folder .default. can be located as follows also,
Type "about:profiles" in firefox and press enter
Click "Open Folder " next to Root Directory path
I had the same issue, and Firefox wouldn't read the *.jsonlz4 files properly, so I coded a little script to extract the URLS stored inside *.jsonlz4 files:
https://github.com/matthieuheitz/recover-firefox-session
Some people use this tool: https://www.jeffersonscher.com/ffu/scrounger.html, but it didn't work for me as the *.jsonlz4 files were very large (> 50MB), and the website just lags forever.
Recent Firefox version (version 96 this time, or at least the Linux one) doesn't have sessionstore.jsonlz4 in the root of the profile, so the other advices does not seem to work.
Firefox nightly upgrades a lot, so I have a very good chance to have FF restarted and lose all the session with no "restore session" available at all.
The solution (for me at least) was
stop Firefox
go to session backup directory at ~/.mozilla/firefox/<session_name>/sessionstore-backups/
copy any old file over recovery.jsonlz4 (say, cp upgrade.jsonlz4-20211112213406 upgrade.jsonlz4-20211112213406)
start firefox, and let it automagically restore th old session
It seems firefox only stores only the last previous.jsonlz4 there apart from upgrades, so it may be useful to ask cron to make periodical backups of recovery.jsonlz4 or similar.
All of the sudden the method by apps open the "select a file" dialog stopped working. For instance if I go to https://uploadfiles.io/, clicking on it does nothing, but the drag and drop works.
This is happening for apps as well, for example I just needed to resync my Google Drive and change the folder location, clicking in "browse" to select a folder does nothing. However, going to Notepad and file > open file works.
I've been searching for a while for the method, .dll, or something that is responsible for this without success. Anyone with a similar issue or more knowledge than what I have can point me in the right direction?
I'm not a naive English speaker so I am not sure if I'm not finding anything because I am not using the right names to search for it.
Windows 10 64b INSIDER PREVIEW FAST RING
I have exactly the same issue. It started somewhere between Friday and today. (Computer was shutdown for two weeks until friday night and before shutting down the problem did not exist.) I suspect some update. In addition to the mentioned issue I have trouble downloading files through Chrome. Edge and IE are downloading fine. Firefox will be installed to test this. It is consistent which apps are (not) allowed to spawn new windows. Apps in 'Program Files' seem OK while those in 'Program Files(x86)' differ. Of those in the (x86) folder OpenOffice is allowed to open a browse window, Adobe Reader is not. KeePass is allowed to open files, EventGhost is not. (changing install folder does not make a difference).
Since it is not clear how long this issue has been around I am hesitant to do a system restore. Also I believe that is a bandaid, not a solution. I am on the Fast Ring of updates.
If an add-on changes a preference outside its own preference branch, then it should revert them back to their previous state (not necessarily the default state) on uninstalling the add-on.
I imagine, the current preferences have to be saved and then at uninstall used to revert back.
Running AddonManager.addAddonListener() seems to be an option (but running a process continuously!). Is there any other option?
In a bootstrapped addon, there is a function uninstall() {}, but how is it done in an overlay add-on?
Other useful topics on the subject (but not fully answering this question):
Firefox Addon: how to remove preferences when addon is being uninstalled?
Set preferences in the user branch and unset them on uninstall
Update
By running a process continuously I meant, running a listener/process for example for an event that may happen once a year. I have already thought of another way which could be more efficient but since that was a hypothetical situation, I don't have the anything to test it on.
Using AddonManager.addAddonListener() is the correct path to take when using an old school overlay add-on.
I'm not sure what you mean when you say but running a process continuously! the listener is just added to an array of listeners, and there is no new process running.
No, you should not run a process continually, nor have a listener on any preferences you changed. There is no reason for it. For the application that you described, you have no need to know when a preference changes. You only need to know what the preference is:
Prior to you changing it
What you changed it to
What it is at the time you uninstall
You have no need to keep track of intermediate changes. Thus, no listener.
When you uninstall, if the preference is the value to which you changed it, change it back to the value which it was prior to you changing it. If it is some value you did not set, then either the user, or another extension, changed it and you should not change it back to the value it was prior to you installing your extension (i.e. you should not undo something the user has hand set, or was set via another extension).
However, if you are an overlay extension, you should add a AddonListener with AddonManager in order to detect when your add-on has been (or will be) disabled/uninstalled. This is so you can know when you should be changing the preferences back.
Bootstrapped (restartless) extensions have their own uninstall notification.
Add-on SDK extensions also have their own way.
It would probably be a good idea to read Appendix B: Install and Uninstall Scripts.
This question has some good information: Firefox Addon: how to remove preferences when addon is being uninstalled?
I have written an application suite on Windows which amongst other things installs a Firefox add-on which once run modifies the Firefox network preferences by interfacing with nsIPrefService.
The extension itself resides in a folder under Program Files along with other parts of the application which work together with each other.
Since the application consists of a number of components, the correct way to uninstall it is via the Control Panel or via an uninstall shortcut I provide for the users.
I have no control over whether Firefox will be running or not when the user chooses to uninstall (possibly I could try to detect if it's running in the uninstaller and request the user close it to continue).
Since the purposes of the uninstaller is to remove all traces of the program from the end-users system i.e:
all the files under the Program Files folder, including the extension components
remove the add-on from Firefox (by removing the registry key under HKEY_CURRENT_USER\Software\Mozilla\Firefox\Extensions, causing the add-on to unregister on next Firefox restart)
remove application specific registry keys
Then after uninstall there isn't any of my code left on the users system capable of restoring the network preferences to what they were before the component was installed. This results in end-users not being able to browse the web and being very frustrated!
The only way I can figure out how to do this at the moment is to have my component write to the window's registry the location of the users profile folder - which I can do with my add-on:
Components.classes["#mozilla.org/file/directory_service;1"]
.getService(Components.interfaces.nsIProperties).get("ProfD",
Components.interfaces.nsIFile).path
And then have my uninstaller modify the prefs.js file in that location directly. But this will only work if I can guarantee Firefox isn't running during uninstall (since prefs.js is re-written on FF close)
To me this is not an elegant solution:
It seems not to be future proof since it is dependent on the format and symbols used prefs.js which may change in future FF releases.
Firefox has a nasty habbit of not always closing properlly (sometimes other installed add-ons prevent it from completely unloading from memory. This would break my uninstaller).
This wouldn't work (without elaborate modification) if the user has multiple FF profiles setup all using my add-on.
Is there a better or "standard" way to achieve this simple task?
Did you try to package defaults files (defaults/preferences/myprefs.js) in your extension? I didn't check if it works for overriding Firefox-wide defaults, but it should.
Can't the uninstaller "insist" that Firefox be closed? eg,
check if FireFox is open
if open, inform user "FF must be closed, or cancel uninstall" ok/cancel
loop
I've had several installers do this to me. Not unistallers, though, that I can remember.
Also, this doesn't future-proof the solution, nor deal with profiles.
This problem crops up every now and then at work. Our build machine can have it's files accessed via a normal windows file share. If someone browses a folder remotely on the machine, and leaves the window open overnight, then the build fails (as it has done now). The explorer window left opened points at one of the sub folders in the source tree. The build deletes the source, and does a clean checkout before building. The delete is failing.
Right now, I'd like to get the build to work. I'm logged in from home, and I'd rather not reboot the build machine. I'm unable to get hold of the person whose machine is looking and the files, and I can't remotely reboot their machine.
When a windows share has a lock, the locking process is System, so I don't think I can kill it, as with normal locks.
Does anyone know a way to release the lock on a shared folder without having to reboot the machine?
If you are admin on the server sharing the file over the network, you can use the Windows in-built feature:
Start → My Computer → Right-click → Manage gets you to the Computer
Management console
In the left nav, navigate to Systems Tools → Shared Folders
You can view Shares, Sessions & Open Files here. This allows you to find out who has opened which files from which workstations.
Right-click on an item in the list to be able to remove the file lock.
Hope this helps.
Found a solution.
Find the process using Process Explorer:
Download and extract procexp.exe
In Process Explorer use the "Find Handle or DLL..." command from the "Find" menu
Enter in the name of the directory which is having trouble deleting
A list of open files which match that name should be shown. Take some guesses and find which one is failing to be deleted. If the file is locked by a windows share, the process holding the file will be System
Note down the directory which was left open
Download and install the Unlocker (Warning: Link removed, as it contains malware)
Install Unlocker, disabling the option for Explorer extensions and other junk
Unlock the directory
Open up a cmd window, and navigate to C:\Program Files\Unlocker
From the cmd window, run Unlocker.exe "the-path-to-the-locked-folder"
A dialog will pop up confirming the lock release. Use the unlock button to unlock the file
Now the directory should be unlocked, and can now be deleted.
Try Process Hacker:
https://wj32.org/processhacker/
Process hacker is like Process Explorer on steroids.
To find the offending process, press CTRL+F or click the "Find Handles of DLLs" button and search for the file name.
Once you find the file in the find handles dialog, you can simply right click the file there and choose "close". (at least for v2.39.124)
Older versions had a "terminator" option in the context menu of the process.
Right click on the offending process --> Miscellaneous --> Terminator --> Select termination techniques. Note that some are possibly dangerous and may have unintended consequences.
I've had similar problems, and none of these suggestions I've seen above look suitable for automated overnight builds (as the original poster implied) because they all require manual effort to hunt down and kill the locks.
The only method I've tried that seems to work reliably is to remove the share itself, make the build, then add the share back. Here's one way of removing the share automatically:
D:\Projects>net share Projects /DELETE /Y
Users have open files on Projects. Continuing the operation will force the files closed.
Projects was deleted successfully.
(NOTE: Creating the share again automatically can be a pain if the privilege groups you need to give it are messy.)
The way i do it is by using both OpenFiles.exe and Handle.exe
You can run them in any order and you will have your resource fully unlocked.
OpenFiles: to disconnect File Sharing sessions
Handle.exe: to release any open handles (don't try to close handles belonging to pid4, since that's the system process)
You can automate this by using powershell, batch, or any language of your choice.
Another option is, starting from Windows Vista, to use the Windows tool built into the system:
monitor resources: perfmon.exe /res
Extracted from: Http://www.sysadmit.com/2017/06/windows-how-to-know-that-process-has-open-a-file.html