Does anyone have any ideas.
All was fine until the update on 19 Jan 2013 to 18.0.1 and now I have no bookmarks, no history and the backups will not load. No new bookmarks can be made and no history is remembered.
I downloaded a new version of firefox portable but to no avail.
You are here
Update to 18.0.1 lost my bookmarks and history function
January 20, 2013 - 9:59pm
#1
Update to 18.0.1 lost my bookmarks and history function
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on Facebook
Follow us on LinkedIn
Follow us on Twitter
Follow us on Mastodon
Follow us on BlueSky
Hi,
I just noticed that problem too:
- Win7 64bit
- using PA on my PC (ie. on the installed HD)
- when I started Firefox portable the *second* time after updating, it seemed to have stalled during start-up - shutting it down and re-starting gave the problem the original poster described (Could it be that the new version has a problem recreating a clean state to start up from when shutting down?)
- Firefox portable doesn't seem to find the portable profile and uses the default profile instead, portable profile seems to be unchanged (no files with newer timestamp than yesterday's last close, Windows tells me the profile folder is write protected(?))
- I am using "Firefox portable, 2nd profile". I got same problem when I started it instead of the original Firefox portable.
A somewhat weird additional note:
I am using several Windows users on my PC. I noted the problem as user A. After user A logout and user B login to Windows, that same Firefox portable "installation" seems to work fine (sorry, don't want to close and restart it to confirm whether it will lose the profile too).
I hope that info helps a bit identifying the problem.
... and while I am at it: Thank you for putting all the work into PortableApps!
The reason for the problem seems to be some interaction between Firefox portable and the system it is used on.
Finding that another user on the same machine has no problem using the same Firefox portable instance (see my earlier message) is one hint into that direction, seeing that Firefox works as wonderfully as before after a HD change (and Windows re-setup) hints at the same. At least that's my take on it... and I seem to be the only person speaking with myself here, anyway (but maybe some reader found it helpful, including the OP).
I too lost all my bookmarks after the latest Firefox upgrade. I run under Linux/Wine mostly, so this is NOT a systems related issue. IMHO someone has really dropped the ball on this, Apparently there is no adequate regression testing going on before a release is made available to users, otherwise this bug would have been caught. I am speaking as a LONG time software engineer and this bug has all the earmarks of a very poor release process occurring. User data should NEVER be lost and the first thing any upgrade/re-installation process should be doing is to BACK UP ALL PRIOR USER DATA! PERIOD. NO EXCUSE is possible for losing user data and a rapid recovery procedure should be made available to restore things back to the way they were prior to an upgrade failure. This is just plain careless engineering, probably being done by developers with little experience in software management.
There's nothing different about the new Firefox Portable 18.0.1 release. It specifically doesn't touch the Data directory where your profile is.
If you let Firefox update itself, there is a small chance the update could restart Firefox in local mode. That would use the local Firefox profile on the machine or create a blank one (even under Wine). Once you close Firefox and start FirefoxPortable.exe again, though, you'll be using your portable profile same as before.
Sometimes, the impossible can become possible, if you're awesome!
I am sorry John, but I have to disagree with you based on what I found and my experience. I do have a local version of Firefox installed and running out of my home directory and the bookmarks for it were both just fine and had additional bookmarks beyond what is seen as the initial default set.. And no the bookmarks that were in place for the local version of Firefox DID NOT show up in the PortableApps version of Firefox. The bookmarks for the PortableApps version of Firefox, in the Data directory, on my external drive where I installed the portable version of Firefox, was RESET to the default starting point for bookmarks. I checked the bookmarks.html file I found and it showed only the default stuff, and NONE of my previously saved bookmarks. So I submit that I flat out LOST the bookmarks that were in place for the PortableApps version of Firefox and I was only able to recover some of them from a backup that I had made.and the ONLY thing I had done was to upgrade the PortableApps version of Firefox.
So despite your claim, the PortableApps version of the Firefox update DID touch and destroy the bookmarks file on my external Passport drive.And that is inexcusable and it shows a lack of care in handling user data. Again, an upgrade should automatically perform a backup FIRST of ALL user data, before making any changes, and Firefox should provide a path for EASILY regressing back to the original working version, in case the update fails for any reason.
And NO, closing Firefox and restarting it DID NOT recover my bookmarks either, I had actually done that several times before I discovered the bookmarks were gone! I dunno or really care who is actually at fault here, Firefox or Portable Firefox, This is a serious issue that needs to be resolved between the two teams. I do NOT want to get in the middle of a finger pointing exercise, all I will say is that I discovered it after doing an upgrade on the Portable version of Firefox. I have NOT seen this problem on upgrades to the system versions yet.
I'm sorry for the loss of your files. That said, I know for a fact that the upgrade code in the installer doesn't touch anything in your data directory. I wrote every line of it. And I reviewed every line of it when you reported your issue. Installers specifically don't mess with Data as your data lives in Data.
The only time I've ever seen an issue similar to this is when a drive has logical errors on it, in which case files are being corrupted outside of our control or the app's control due to issues between the host OS and the bits stored on the drive.
Incidentally, bookmarks.html isn't used by Firefox and hasn't been used in years now, so it should only contain defaults. Bookmarks are now kept in the places.sqlite database file (along with history). This can sometimes compound logical errors on a drive as the database can become corrupted (in which case you will wind up with the defaults or blank bookmarks). When this happens you will sometimes, but not always, find a places.sqlite.bak and a places.sqlite.bak-rebuild file present in your profile directory.
I had it happen recently to my local non-portable Firefox install on a crash when the cookies.sqlite file became corrupted. I lost all my saved login information (via cookies not password manager) for all my websites. The best bet is to *always* have a recent backup.
Sometimes, the impossible can become possible, if you're awesome!
Even although I am delighted to see some life in this topic, there's no reason for finger-pointing.
Please also do not jump to conclusions: The bookmarks (and other profile data) was in fact still there, although Firefox didn't use it. As I pointed out: When started from a different user on the same machine, the exact same Firefox portable "installation" ran fine. All I can conclude is that there was indeed a problem with Firefox portable in combination with that Windows user - which ultimately makes/made it non-portable.
are you telling us that normal local installed Firefox does a backup of all user variables before it runs an update?
Are you sure that MS office does backup all user data before it makes any kind of update?
Are you really sure that windows does back up all users data before it makes any updates?
Are you sure that linux does backup all user data before any updates are made?
Otto Sykora
Basel, Switzerland
If you are implying that just because others are using lousy engineering practices, that makes it OK for PortableApps engineers to follow suit, you are dead wrong! As a computer scientist myself, way back in my own graduate days, I was taught to regard user data with respect and to preserve it as best as one can. Many many programs have practiced this philosophy over the years I have been doing software engineering, such as word processors that periodically back up users work, software updates that create a restore point, etc. I have also observed many programmers become callous about writing good software, and not backing up data before modifying it. I don't understand engineering attitudes that think this is ENTIRELY the users responsibility either, i.e. saying it is entirely up to the users to keep their data backed up. IT IS NOT! IT IS ALSO THE ENGINEERS RESPONSIBILITY to make computers as safe, and as reliable as possible, and to help users as best as they can to overcome the shortcomings of computers, Users SHOULD NOT be required to be software engineers and SHOULD NOT be required to understand the risks involved from doing updates. They trust the engineers to write code that does the updates safely, to protect their data from loss, and to provide a way to recover (if it is reasonably possible) in case something goes wrong. Update processes should, at a minimum guide users to follow safe procedures and practices, far better yet do the safe procedures/practices for them, especially when it can be done with just a bit more care and effort on the engineers part.
I don't want to hijack portableM's thread either, he may be seeing a different problem. I simply wanted to add my own observations that seemed to parallel his experience with the loss of the bookmark data. I DID lose mine for some unknown reason, John T Haller claims that the update process does not touch the user data, I observed differently and reported it. John thinks the problem I experienced might be due to disk drive failure or file corruption, I check my drive and found no problems with it. And the drive is working fine for all the other applications running off of it. So we are at an impasse and I am not going to argue any further with him. If he choose to pursue this issue any further, I am willing to help and offer any additional information I can. If not, that is his choice, so be it and I will regard future updates to Firefox as dangerous and take preventative steps before applying them. I am an expert on computers and know how to protect myself, that is why I was able to recover most of my bookmark data, But many if not most users are not computer experts and they have my sympathies. I try to be an advocate for them, not for poor software engineering practices that are harmful.
I have verified both the underlying code and the actual install of a Firefox Portable upgrade using the versions you said were affected. The only file within Data that the installer will ever touch is the FirefoxPortable\Data\settings\FirefoxPortableSettings.ini file. And even then, only under rare circumstances. I am 100% sure of this.
Did you verify that Data was somehow altered after the install of the upgrade but before you ran Firefox Portable? If not, it is likely that Firefox found corruption in some of your files and reset them. As already stated above, Firefox will do this within a local or portable install whenever the SQLite database is corrupt. It will attempt to repair the database if it can.
In the end, you as the user are responsible for your data. None of the browsers we distribute automatically backup your bookmarks for you. None of the major browsers do in a local install either. These are companies that spend tens of millions of dollars developing their products and they are still vulnerable to the usual issues that can occur from a single corrupt file (since all your bookmarks are contained in a single file). You can back them up manually or sync them to the cloud using one of the built in services to do. But the apps themselves will not do it.
Nearly all software works this way. We try to make it easy on users by providing an easy to use backup solution integrated into the PortableApps.com Platform that will even just backup your data (skipping the apps themselves) for faster backups. But, in the end, it is up to the user to back it up.
I understand you lost data and I am sympathetic. As mentioned, I lost all my cookies a couple months back when Firefox's cookies SQLite database on my local machine was corrupt. Nothing had crashed, not the app or the PC. Firefox is running on a solid Windows 7 box from an internal hard drive, but the file wound up corrupt anyway. These things will happen. We can't magically prevent drives from occasionally corrupting data. They always have. And likely always will until we implement full error correction into the file systems. But NTFS, FAT32 and exFAT do not support that. Until then, it's up to us to make backups to ensure we don't lose our data.
Sometimes, the impossible can become possible, if you're awesome!
John - I think we may simply have to agree to disagree with each other. I am fundamentally opposed to your attitude that the onus is all on the user to back up their data and find it incredibly cavalier of you and other developers who say such things. I would NOT hire you as a programmer if you came to me with such an attitude. My mother, and probably yours, (i.e. typical users) WILL NOT UNDERSTAND either the need for or the procedure of doing backups, let alone have any idea about what needs to be backed up and how to restore data from a backup. Asking users to do backups should only be a second level of defense against data loss, NOT the primary defense. USERS ARE NOT COMPUTER EXPERTS AND CANNOT BE ASKED TO OVERCOME WEAKNESSES OF COMPUTER DESIGNS, BY THEMSELVES. That is like asking a car driver to be an expert on engine and transmission design, and know how to repair them if a mechanic screws things up. It is NOT going to happen, at least not on this planet!
PLEASE do not consider me an idiot either! I FULLY understand the dangers of disk failures and file corruption issues. And I KNOW that such a catastrophic failure is difficult to guard against. But that is NOT the only danger to data files, software errors can also lead to data losses. I agree with you that it may have been a coincidence that a data file corruption error may have occurred at the same time I was doing an update, and I cannot prove otherwise. I also will accept your claim that the code doing an update does not touch any of the files in the DATA directory and appreciate your taking the time to double check your code. BUT when I go into such a directory, that is chock full of files containing user data, AND NOT ONE OF THOSE FILES IS MIRRORED WITH A BACKUP VERSION OF ITSELF I also know that the software designers are being reckless (and highly arrogant if they believe for one second that their software is bug free) by not even taking some simple steps, such as doing automatic backups, to help protect the users against data losses.
When I use xemacs, for example, a file editor which runs under Linux (has been around for many years now) WHAT IS THE FIRST THING IT DOES WHEN ASKED TO EDIT A FILE? IT CREATES A BACKUP VERSION OF THAT FILE!!! WHY??? SO THE USER CAN RECOVER AT LEAST THAT MUCH OF HIS DATA IF A SUBSEQUENT PROBLEM OCCURS!!! The user doesn't have to back up his file before updating it, THE APP DOES IT and if the user also is savoy enough to do a backup once in awhile, that gives 2 levels of a backup from which a user has a good chance of recovering most of any lost data.
What is so hard to understand about the idea, that each and every time a user modifies his bookmarks, that BEFORE any changes are made to the underlying .sqlite file, (or whatever file type is being used) that a backup of that .sqlite file is first (or even just periodically) automatically made. DITTO for all other kinds of data files! Just having 1 level of a backup, made automatically, will enormously increase the odds that a user can recover most of his/her data should something go wrong when making the changes. And YES the app should also do a comparison between the backup and the original before proceeding with updating the original. If this is not your responsibility, then push back on those who do have the responsibility, you probably have a better idea of who is responsible, we users do not. This IS a BAD design issue, any decent computer scientist will tell you so, and it needs to be repaired.
This same process can also be applied to doing software updates. FIRST BACK UP ALL knowable user data files and any other files/directories being changed, check to be sure that the backups are the same as the original, then make the update changes. If anything goes wrong, (file corruption, data format changes, or simply bugs which got in to the code) then you can provide the user with an easy means by which he/she can revert back to the versions that were in place before the upgrade occurred. Doing upgrades, or making changes is risky, so all I am asking is that developers take simple and reasonable steps to prevent data losses, and doing backups automatically, for the user, will be a HUGH step towards achieving this goal.
In the end, it doesn't matter what you or I think. The software apps themselves do not do what you want. Not Google Chrome, not Mozilla Firefox, not Iron, not Opera, not QupZilla, none of them. None of them back up your data automatically.
So, it is up to you how you want to respond to that fact. You can either take precautions or not. Yelling at me or calling me names or saying you'd never hire me does nothing to change the way these base apps work nor does anything to change the facts about how these apps work. You need to talk to Google, Mozilla, Opera, etc and ask them to add in backups. I have no ability to "push back" and put any pressure on them.
Unfortunately, I can tell you that the likely answer will be no. The reason is that browsers are judged on one thing above all else: speed. Building in a database backup or mirror of each change will slow a browser down. These are database files that are updated every time you click a link, load a page, switch a tab, etc. It will slow it down dramatically when run on an average USB drive (likely to the point of being unusable on many standard retail drives).
Again, these are not my decisions to make. Nor anyone else who is reading your posts here. Essentially, you're yelling at and calling people names who have zero say in the way all of this works. You need to go talk to all the app makers and somehow convince them to do make backups. Or to learn to code and write it yourself or pay for it to be written and hope they accept the patch.
Sometimes, the impossible can become possible, if you're awesome!
John - Please, lets stop using cheap debate tactics, such as misdirection, just to simply win an argument, and lets stay focused on the issue at hand. My understanding is that you (and perhaps others) are the ones responsible for the code and processes which handle updates for PortableApp's Firefox. Is that not correct? If so, then I have pointed out to you that there is a weakness in this process, in that neither a backup, nor a restore process is implemented which could be of valuable assistance to users who need to recover from a bad update experience. Trying to pass the buck back to users who do not understand backup procedures, or to blame the developers of the underlying product for its weaknesses shows poor engineering skills on your part. Instead, as a good engineer you should be asking the question, how can I help make the users experience a better one. Yes, you can find LOTS of examples of poor engineering practices going on in the world, but no matter how many you find, it does not justify using poor practices yourself nor should it keep you from finding solutions that are better answers.
As I have tried to explain, there are LOTS of potential reasons why a software update can lead to failures and loss of hard earned user data. Disk drive corruption is but one, newly introduce software bugs is another, user mistakes is a third, etc. Every computer engineering class I have attended or taught, every book on good software engineering practices will tell you that backing up data, before modifying it, or modifying software that may in turn modify the data, is extremely important. I have also explained, that most users are NOT competent enough to do backups before they go and run your updaters. I strongly recommend that you incorporate into your update processes, steps which INSURE that both user data and modified application files are backed up before you modify anything. Simply doing a directory copy, if the directory is self-contained, is an excellent start. It offers a good restore point as well, it mitigates against poor engineering of the base Firefox application, and it helps protect users against their own mistakes. You have not given me, or your readers, one good reason why the software, which updates the Firefox app, cannot/does not back up the app and its data before doing the update. One final point I might also make, IF your updater had been doing backups prior to doing the actual update itself, and IF a disk drive is corrupted, or data files were corrupted, THEN there is a very good chance that your backup step would have discovered the problem and could then have reported it to the user. That is a far better solution than to proceed blindly with the update which in turn lead to the needless loss of valuable data.
We have gotten sidetracked by more granular backup issues, (t.e.x. backing up individual files as they are changed) which yes also need to be addressed. If you don't care whether the software application you are helping with, gets improved, you can take a chance and push back on the user(s), who are reporting the problem, and tell them to go report the problem to someone else. OR you can take ownership of the issue yourself, and see to it that the problem gets forwarded appropriately to the right people. All depends on how much you care whether Firefox is improved o not... Since you have shown reluctance, I will try to bring this issue to the base Firefox developers myself, particularly since I disagree with your assessment that appropriate backup steps has to come at the expense of browser speed.
darkstar, let's start with the facts:
1. Firefox Portable's update process does not touch or modify your data or your profile in any way. This can be verified by looking at its code, all of which is available.
2. The only thing that modifies your bookmarks file is Firefox itself. Not our installer, not our launcher. Never has, even going back to Portable Firefox 0.9. Only Firefox itself modifies your bookmarks. And only Firefox itself could reset your places.sqlite due to corruption or another issue.
3. Firefox will change your bookmarks file hundreds of times during every use as it is altered whenever you add a bookmark, remove a bookmark, edit a bookmark, visit a bookmark, visit a web page, type a URL, open a tab, etc. It is a single database used for history and bookmarks.
4. Firefox does not backup your bookmarks during use. This is not a portable issue as we have no control over it. It is part of Firefox's code.
5. Firefox does not backup your bookmarks on upgrades. The local app does not do this, thus the portable one does not either.
Those are all facts that can easily be verified and are the way things are handled today. You are welcome to petition Mozilla for changes of any of the above. If you would like it, you can take ownership and file an enhancement request.
All that said, there are things we could do on our end. These include:
1. Having a backup tool in our platform to make it easier for end users to make backups of their data
2. Have the platform prompt users to automatically backup on a regular basis
3. Back up the profile after each use
4. Back up the profile on each upgrade
1 is already implemented. 2 is coming soon in our platform.
3 will likely not be done because backing up a profile with hundreds of files totaling 100MB (my current Firefox profile as an example) takes quite a bit of time and will increase the install size of Firefox Portable by 50%. This would cause Firefox Portable to take an additional 30 seconds to launch on some flash drives which is simply unacceptable. Additionally, as we are not the app itself, we couldn't necessarily determine if a backed up profile was 'good' or 'bad', only if it was bit accurate with what we are backing up. So, as soon as you run Firefox Portable, you'd be wiping out your last backup and replacing it, possibly with the one with a corrupted bookmarks database.
As for 4, this is something we will be adding to the platform itself as an option that will be handled by the platform's updater. It will be off by default because it will slow down the upgrade process significantly. Users can elect to turn it on if they want.
Sometimes, the impossible can become possible, if you're awesome!
John - Your step #4 is what I have been mainly focused on, in this forum. And I am finally glad to hear that this issue is already being thought about! The other 3 issues, that you listed, I have already agreed are not within the domain of the PortableApps developers and rightfully need to be address by the main Firefox developers. (I disagree with your assessment of #3 and we could get into another dissertation about it, but backups do not have to be an all or none affair. They can be prioritized, with the most valuable things being backed up more frequently and the less valuable things less often.)
As for your approach to backing up the profile, most architects would feel you have your priorities backwards. The default should be to back things up, as safety should take priority over speed and convenience. Beginning users will not understand when and why backups should be turned on or off, advance users will. Therefore the onus should be on advance users to decide if/when the risk of not doing a backup outweighs the cost of a slower install.
4 has been on the 'coming later' list for a while now. It's fairly easy to implement in the updater code (just before updating each app: delete the existing backup of the Data directory if there is one and then backup the current Data directory) but it slows things down a lot and winds up taking up a lot more space on your drive. Some apps store 100s of MBs of data within Data (think apps that download stuff like torrent apps and podcast receivers). At first, it will be all or nothing (backup Data from all apps before upgrades or none) and then later some more fine grained control.
Most of the profile is 'important'. The places.sqlite file with my bookmarks and history is 50MB in my profile right now. That's a good % to back up if we're only backing up important stuff (and we haven't even counted saved passwords or cookies yet). A long time ago, Firefox used to automatically backup your bookmarks.html file on each launch and store a handful of copies. It did this because it was relatively small, changed relatively infrequently and was susceptible to corruption. That's simply not feasible now due to the size of the places.sqlite database. The likely reason history and bookmarks are in the same database is due to the awesome bar in Firefox that automatically prefills what you are typing based on whether you have it bookmarked, when you last visited, how many times you visit, etc. That can't be accomplished as efficiently if they are in separate databases. I'm not saying whether this is a good or a bad decision, just that this is the way it is structured and the reason why they chose to do so.
The bottom line is that most of this is outside of your or my control. And that users value speed and functionality much more highly because they see and feel that on a regular basis. A user won't put up with a browser that takes over a minute to launch. Or a platform that takes an hour to backup your data as it updates apps by default. You're actually the only user I can recall that's ever gotten upset about this, if that helps show you the overall priorities of most users.
Sometimes, the impossible can become possible, if you're awesome!
Bookmarks are still backed up into a JSON file inside X:\PortableApps\FirefoxPortable\Data\profile\bookmarkbackups. THe file is only 100 kb so its most likely only bookmarks and no history.
"What about Love?" - "Overrated. Biochemically no different than eating large quantities of chocolate." - Al Pacino in The Devils Advocate
On someinstalls I have some backup file, but those are from old times there. ( prove that updates do not delete anything
)
In new install, nothing like this can be found unless: you do a manual backup of your bookmarks or use one of those many bookmark handling extensions which will do this for you.
Firefox does not do it automatically, you have to do it by hand.
Otto Sykora
Basel, Switzerland
Default is browser.bookmarks.max_backups=10 (as mine is) and I have ten files in my profile \bookmarkbackups folder named:
bookmarks-2013-02-06.json to bookmarks-2013-02-15.json.
Since this is a user-configuration setting, different installations may be set differently.
neutron1132 (at) usa (dot) com
I ahve 10 too and they are from february 2013, thus not old copies. Unfortunately I cant remember touching that about:config-key, so I will try with a clean copy and post back.
"What about Love?" - "Overrated. Biochemically no different than eating large quantities of chocolate." - Al Pacino in The Devils Advocate
My point is that the default setting is to make 10 backups. When you get to 11, the oldest one is deleted.
This is the default setting for standard Firefox and is the default setting for FirefoxPortable. I just did a virgin installation just to be sure that the default for the portable version is 10, the same as standard version.
So, if there are any less than 10 backups (say for instance "zero") then the user must have modified the default setting, expecting that they would either provide for their own backups or that nothing would ever go wrong with their system and trusting that backups are unnecessary.
As an experienced IT person (and I know there are plenty of people around here who claim to have such knowledge) I have several layers of backups for my data. There is nothing worse than losing data, and the smart money is on redundant backups. Bad things can and do happen. Being prepared for them is smart.
neutron1132 (at) usa (dot) com
Does xemacs backup your settings?
Regarding who is responsible, please open a bug report on the right place.
Finally, please stop writing "computer scientist". It makes me feel like we were talking of deterministic stuff.
Previously known as kAlug.
Yes, xemacs does back up my settings, each and every time I make changes to them. And that is not a high overhead on the editor, since such settings are not changed all that often. Same can be said about Firefox, users do not change bookmarks and browser settings all that often either so there wouldn't be much overhead in backing up those data files either. For as many software examples as can be found that do not do adequate backups, I can find many that do.
But this is all really besides my main point. I am/was focused on the software update process for PortableApps Firefox, not on the daily usage of it, before we got sidetracked on these other backup issues. My main point is that before doing a software update of any kind, steps should be taken to insure that user data, and application files are backed up, prior to the update itself. I believe this IS the appropriate forum to address this issue, not the bug report repository of the base Firefox application. But feel free to correct me if I am wrong, though I do not see how the base Firefox developers will care about what PortableApp developers are doing....
I am sorry you find my description of myself as a computer scientist distasteful. It is what I was trained as and do, I study software architectures, design and development processes, engineering practices, testing and implementation methodologies, and yes even release/update processes as well. Been doing it for over 40 years now, so I kinda know a thing or two about software.
And no, computer science is not deterministic, but good software engineering practices requires far more rigorous techniques and discipline, such as focusing on and improving the entire broad range of user experiences and evaluating what works and what does not. Using proven methodologies is far more deterministic than what simple software hacking provides.
As mentioned in my earlier comment, your bookmarks are stored in a sqlite database along with your history and last visited times for all your bookmarks. This file changes every time you do just about everything in your browser. So, while you may only think of it changing when you add a bookmark, edit a bookmark, or delete a bookmark, which you may not do that often. It is also changing every time you use a bookmark, click a link, manually a type in a URL, visit any web page, etc. It is constantly changing, which is why backing it up on changes would be difficult (and slow down Firefox) and why it is prone to corruption from disk issues. I have included a complete explanation of the other issues in my later comment:
https://portableapps.com/node/36128#comment-205081
Sometimes, the impossible can become possible, if you're awesome!
>If you are implying that just because others are using lousy engineering practices, that makes it OK for PortableApps engineers to follow suit, you are dead wrong!
Otto Sykora
Basel, Switzerland