Re: bookmarks.html not updating - Mozilla

This is a discussion on Re: bookmarks.html not updating - Mozilla ; On Mar 31, 7:19*pm, Miles wrote: > The FX 3.0.8 bookmarks.html file dates read in Windows Explorer: > modified 3/16/09; created 3/13/09; accessed 3/31/09. > And I made a bookmarks.html.bak file on 1/4/09, which shows modified > 3/16 & accessed ...

+ Reply to Thread
Results 1 to 11 of 11

Thread: Re: bookmarks.html not updating

  1. Re: bookmarks.html not updating

    On Mar 31, 7:19*pm, Miles wrote:
    > The FX 3.0.8 bookmarks.html file dates read in Windows Explorer:
    > modified 3/16/09; created 3/13/09; accessed 3/31/09.
    > And I made a bookmarks.html.bak file on 1/4/09, which shows modified
    > 3/16 & accessed 3/18. *The size hasn't changed either, reading 1,303kb
    > and the .bak reading 1,307.
    >
    > About:config line: browser.bookmarks.autoExportHTML reads true. Today
    > changed it to false, restarted FX, changed it back to true, restarted,
    > and no change. *This has been further tested by adding a BM, re-opening
    > FX & Win Explorer and it doesn't appear in the bookmarks when double
    > click on bookmarks.html which opens the BM's on a new tab.
    >
    > Have Foxmarks, if that could be relative? *Any and all thoughts welcome!
    >
    > Miles


    I just tested it and it works fine for me (FF 3.0.8). Are you
    selecting the proper bookmarks.html file? It gets created in the
    user's profile folder. Do you have more than one profile by chance
    and are selecting the wrong one?

    JB

  2. Re: bookmarks.html not updating

    On Mar 31, 7:51*pm, Fox on the run wrote:
    > On Mar 31, 7:19*pm, Miles wrote:
    >
    > > The FX 3.0.8 bookmarks.html file dates read in Windows Explorer:
    > > modified 3/16/09; created 3/13/09; accessed 3/31/09.
    > > And I made a bookmarks.html.bak file on 1/4/09, which shows modified
    > > 3/16 & accessed 3/18. *The size hasn't changed either, reading 1,303kb
    > > and the .bak reading 1,307.

    >
    > > About:config line: browser.bookmarks.autoExportHTML reads true. Today
    > > changed it to false, restarted FX, changed it back to true, restarted,
    > > and no change. *This has been further tested by adding a BM, re-opening
    > > FX & Win Explorer and it doesn't appear in the bookmarks when double
    > > click on bookmarks.html which opens the BM's on a new tab.

    >
    > > Have Foxmarks, if that could be relative? *Any and all thoughts welcome!

    >
    > > Miles

    >
    > I just tested it and it works fine for me (FF 3.0.8). *Are you
    > selecting the proper bookmarks.html file? *It gets created in the
    > user's profile folder. *Do you have more than one profile by chance
    > and are selecting the wrong one?
    >
    > JB


    Upon further testing I set bookmarks.html to read-only. When I did
    that, it did not work. I could see that it tried to write to it but
    couldn't (using a tool to monitor what was happening in the background
    - same one that confirmed it worked previously). So make sure that
    you have sufficient access rights to the file.

    JB

  3. Re: bookmarks.html not updating

    On Apr 12, 5:52*pm, Miles wrote:

    > At this stage I'm at whit's end having tried everything that comes to
    > mind. Any suggestions would be appreciated -- perhaps there's another
    > setting in about:config that was changed by an extension?
    >
    > Miles


    Try creating a new profile and see if you get the expected behaviour
    in it. If so, clearly there is something in the existing profile
    (whether some quirky configuration/add-on or permission issue) that is
    causing the problem.

    JB

  4. Re: bookmarks.html not updating


    > 3) *Discovered places.sqlite-journal disappears when FX is exited and
    > rebuilds upon restart.


    This is a journaling file used by sqlite to attempt to protect the
    integrity of the database when executing transactions on it (adding,
    changing, removing). It is not required when Firefox shuts down.


    > A few idiosyncrasies perhaps someone can explain:
    > 1) *Why isn't the option line in the start menu as it was in prior
    > nuances so that one could readily open Profile Mgr without having to
    > go into Command Run when Profile Mgr is checked "don't ask at
    > startup." *Perhaps there's a way to add a shortcut to Start????


    You could certainly create a shortcut in your start menu that starts
    Firefox.exe with -p, and then call that shortcut Firefox Profile
    Manager if you wish.

    >
    > 2) Why not an option to turn BM.html on and off instead of going into
    > * about:config. *It seems to me that most users would want this on --
    > I certainly do!


    I have no need for it. I'm not so sure that "most users" would
    either. A number of them do and that is evident from some of the
    postings we've seen. But I would be hesitant to qualify that as "most
    users". I'm not suggesting there shouldn't be an option via a menu to
    do that. That might be an appropriate option to include either under
    the bookmark menu or in advanced options. This way a user wouldn't
    have to know to go in about:config, it would be done for them via the
    menu option. But I'm not convinced that "most users" have a need for
    this in the meantime.


    > 3) * After deleting over 100 BM's BM.html changed size, but
    > places.sqlite did not. Does this suggest that it is keeping all this
    > garbage and will eventually grow into a dinosaur?


    No. The space previously occupied by those bookmarks is \x00'ed out
    in the sqlite file and eventually re-used. To remove it from the file
    each time something is deleted would require compacting the database
    each time - a negative performance hit.

    >
    > 4) *Is there a way to recover History from the old profile?


    There may be an add-on to do it. I'd avoid trying to do it with
    something like sqlite manager because of the dependencies between the
    various tables in the database and the requirement for the id's to be
    unique in the various tables.

    >
    > 5) *The original/default profile is named kay0dh7v.default. *The new
    > one was not assigned these spurious characters and merely accepted
    > what I offered. *Can FX now create such a list of spurious characters,
    > or would that be deemed unnecessary? *Profile.ini now contains the old
    > profile name, kay0dh7v.default, however, the new one is the default,
    > which is misleading.
    >
    > Remaining to be done and I'm not certain how, is to delete the old
    > "default" profile and change the name of the new one to simply
    > "Firefox3.0 Profile" or such. *Perhaps best change the name and keep
    > the first profile for safety since there's sufficient space on the
    > drive, but change the name of the new one to xxxxx.default? *(I seem
    > to recall a few years back, doing such in the .ini and WindExplorer
    > didn't change the name in profile mgr.
    > Miles


    Be cautious when playing with profiles. I had an experience not that
    long ago where I pointed Firefox to an existing folder that had other
    data in it to use as a profile folder (was showing someone something
    and was too lazy to create a new folder for it so pointed to an
    existing one). Firefox deleted the contents of that folder to use it
    as a profile folder. Don't know if that's been fixed to at least warn
    a user and provide them with the option to cancel the operation. You
    can rename a profile from within the profile manager, as well as
    delete a profile (and either retain the files or delete them as
    well). Unless you have a need to use more than one profile, just as
    well leave the profile name alone to avoid any possible issues. If
    you need multiple profiles then hopefully you understand it enough to
    play with that feature safely (overall it's safe, but it's not
    impossible to mess things up).

    Regards your initial problem, there is a possibility that the old
    places.sqlite was messed up (could have been an add-on, manually
    messing with it using something like sqlite manager, problem with the
    hard drive at one point, aliens taking over your computer). Creating
    a new profile creates a new places.sqlite hence why that problem would
    not persist.

    JB

  5. Re: bookmarks.html not updating

    On Apr 19, 2:35*am, Dave Symes wrote:
    > In article ,
    > * *Miles wrote:
    >
    > > Forgot to mention that the obvious culprit was places.sqlite.
    > > Miles

    >
    > Unfortunately that place contains meaningless drivel to the Human eye,
    > HTML is at least human readable.
    > Dave
    >
    > --


    No question it has caused challenges for some who were used to
    manually editing bookmarks.html. There are benefits that were
    achieved with the database approach which has been discussed in the
    past. Not everybody agrees that it was an improvement for the end
    user (and for some, it was certainly not an improvement because it
    caused them some headaches because they were using bookmarks.html).
    But I'm going to go out on a limb and say that the larger percentage
    don't even know that things changed in the background because they are
    not power users. When I say the larger percentage, I mean 50.0001% or
    more. Consider how many people have downloaded FF vs how many are on
    this list. A very small fraction (less than 1%) are on this list and
    of those only a small percentage of them expressed frustration with
    this change. If it was a bone of contention for several million users
    which still would account for less than 5% of the total users there
    would have been a lot more noise on this list about it. The average
    user could add, remove, edit bookmarks from the GUI before and still
    can now. So they see no change in that aspect. They likely didn't
    even know about bookmarks.html before and don't know about
    places.sqlite now. As long as they can still do the same thing via
    the GUI, nothing has changed for them.

    JB

  6. Re: bookmarks.html not updating

    On Apr 19, 6:44*pm, "Terry R." wrote:
    > The date and time was Sunday, April 19, 2009 11:28:44 AM, and on a whim,
    > Fox on the run pounded out on the keyboard:


    > > No. *The space previously occupied by those bookmarks is \x00'ed out
    > > in the sqlite file and eventually re-used. *To remove it from the file
    > > each time something is deleted would require compacting the database
    > > each time - a negative performance hit.

    >
    > I have been having to remove FF on many networks due to the changes in
    > FF v3 using SQLite. *The constant journaling has a very negative impact
    > when workstations are using backup software such as Backup Exec DLO.
    > This constant (almost useless IMO) journaling is okay to impact the
    > performance of the workstations and the huge hit on servers where dozens
    > if not hundreds of workstations are constantly writing backup data when
    > it isn't needed, and yet you're suggesting that doing something useful,
    > like cleaning the database is a negative? *That doesn't make any sense.
    >


    Because each time a transaction was deleted from the database, it
    would have to be compacted. If the database is several megs, then the
    system has to write several megs of data to the hard drive each and
    every time something is deleted from the database (in order to compact
    it, or clean it as you say). This is why sqlite (not Firefox as far
    as I know) behaves in that fashion. That was my answer in response to
    the person who asked why places.sqlite didn't change in size when they
    deleted 100's of bookmarks.

    And in response to your posting, yes that would be a performance hit.

    As for journaling, I don't understand enough about it to comment on it
    beyond my understanding that it's used by sqlite to help maintain the
    integrity of the database. But where this is a file that only exists
    while FF is running, thus short lived and not important after it's
    done it's short lived job, can't you configure the backup software to
    exclude the journaling files? I don't know the software, but I
    Googled it and then searched their site for "Backup Exec DLO
    exceptions" and saw a mention of configuring it to exclude ntuser.dat
    for example. So it would see you can set exemptions. Excluding the
    FF 3.x journaling files would make perfect sense in my opinion and
    based on your description of the problem would likely eliminate that
    performance hit on the network.

    JB

  7. Re: bookmarks.html not updating

    On Apr 20, 12:11*pm, "Terry R." wrote:
    >
    > Many (if not most) have their browsers open all day, so the journaling
    > is a constant.
    >
    > Writing exceptions really isn't the point. *Most companies don't want to
    > take the time or resouces when software is an option to already
    > available working software (IE). *I had installed FF on most of the
    > workstations on the networks I admin, and now I'm spending my own time
    > (and wasted resources) on removing it because of the buzz regarding the
    > impact on servers.
    >
    > There isn't a need for that kind of constant journaling IMO, but when
    > has any user opinion mattered to the devs.
    >
    > Terry R.
    > --
    > Anti-spam measures are included in my email address.
    > Delete NOSPAM from the email address after clicking Reply.


    My understanding is that this is characteristic of sqlite. Therefore
    any application using sqlite will exhibit this behaviour. Skype uses
    it for call log, Google Chrome uses it for some of their browser files
    (i.e. similarly to Firefox). Seems to me it would have been less work
    to add an exception then uninstall FF 3.

    Journaling as I understand it is there to help protect the integrity
    of the database. If the system crashes, some recovery can be achieved
    with the help of journaling. The absence of journaling I guess would
    remove that safety blanket in this database environment.

    Other files that write frequently: NTUSER.DAT, $MFT and other system
    files. Although I imagine the software automatically excludes system
    and hidden files so that may be why those constant changes do not
    impact your backup system.

    Firefox developers chose sqlite, an open source database application,
    for whatever reason (we can guess, but I won't beyond the fact that
    migrating to a database has allowed them to introduce new
    functionality and using an open source one seems like a logical choice
    given FF is open source). The creator of sqlite I'm assuming is the
    one who created that journaling environment for obvious database
    integrity reasons. You seem to be of the opinion that this king of
    journaling is not necessary. Have you contacted the author of sqlite
    to express this and offer a solution that would afford the integrity
    journaling provides without the same issues you've identified? I
    don't know you, so don't know if you are simply expressing an educated
    guess that such journaling is not required, or if you possess greater
    knowledge in this field and are expressing a more informed/educated
    opinion.

    JB

  8. Re: bookmarks.html not updating

    On Apr 20, 6:05*pm, Fox on the run wrote:
    > On Apr 20, 12:11*pm, "Terry R." wrote:
    > > There isn't a need for that kind of constant journaling IMO, but when
    > > has any user opinion mattered to the devs.

    >
    > > Terry R.

    >
    > Journaling as I understand it is there to help protect the integrity
    > of the database. *If the system crashes, some recovery can be achieved
    > with the help of journaling. *The absence of journaling I guess would
    > remove that safety blanket in this database environment.
    >
    > JB


    Further to my above message, check out Rollback Journal at
    http://www.sqlite.org/tempfiles.html where it explains why sqlite uses
    this journal (which is the one that appears to be responsible for your
    network woes).

    So I re-iterate my question from earlier, do you have a better way for
    the author to implement this integrity in an sqlite database that
    won't cause you the hardships you are experiencing? If yes, have you
    shared that with him? If no, rather you are simply venting with no
    real understanding of the purpose of this file then follow the link I
    provided above and read and understand why it is used and perhaps your
    opinion that "There isn't a need for that kind of constant journaling
    IMO" may change. Whether or not you decide to enter an exception in
    your backup software or not is entirely up to you.

    JB

  9. Re: bookmarks.html not updating

    On Apr 21, 10:06*am, "Terry R." wrote:

    >
    > It's not only my "network woes". *Research it a bit and you will find a
    > lot of other IT complaints about it. *Even the bug I filed, someone
    > commented about the impact in the corporate environment.
    >
    > Terry R.
    > --
    > Anti-spam measures are included in my email address.
    > Delete NOSPAM from the email address after clicking Reply.


    So the issue is with sqlite specifically rather than Firefox 3 code,
    correct? Did you file the bug with sqlite, or with Firefox? Do you
    have a link to it and some of the other complaints so I can read up on
    it? I could Google it and sift through the hits to find some relevant
    ones, but time does not permit me to do that anytime in the near
    future.

    JB

  10. Re: bookmarks.html not updating

    On Apr 22, 11:07*am, "Terry R." wrote:
    > The date and time was Tuesday, April 21, 2009 5:54:59 PM, and on a whim,
    > Fox on the run pounded out on the keyboard:
    >
    >
    >
    > > On Apr 21, 10:06 am, "Terry R." wrote:
    > >
    > >> It's not only my "network woes". *Research it a bit and you will find a
    > >> lot of other IT complaints about it. *Even the bug I filed, someone
    > >> commented about the impact in the corporate environment.

    >
    > >> Terry R.

    >
    > > So the issue is with sqlite specifically rather than Firefox 3 code,
    > > correct? *Did you file the bug with sqlite, or with Firefox? *Do you
    > > have a link to it and some of the other complaints so I can read up on
    > > it? *I could Google it and sift through the hits to find some relevant
    > > ones, but time does not permit me to do that anytime in the near
    > > future.

    >
    > > JB

    >
    > Filed it w/FF, since it was the change from 2 to 3 using SQLite.
    >
    > https://bugzilla.mozilla.org/show_bug.cgi?id=455075
    >
    > Terry R.
    > --
    > Anti-spam measures are included in my email address.
    > Delete NOSPAM from the email address after clicking Reply.


    Even if you turned off journaling, There would still be quite a few
    writes to cookies.sqlilte. It's the nature of any database. It's
    transactional based therefore each transaction is a write to the
    database. In Firefox 2 it used the file cookies.txt rather than
    cookies.sqlite. In FF2 it meant making changes to a flat text file.
    In FF3 it involves a transaction in a database.

    Journaling is not only used for cookies, but for all the other sqlite
    files in FF3. If that is an option that can be turned off without
    having to add much code then I could see them doing it. But It
    appears to be something built into sqlite. So I'm not so sure that
    it's something that could be turned off by an application developer
    using sqlite for its database.

    If you did turn off journaling and had a system crash then all the
    databases used by Firefox (which includes history/bookmarks) would be
    at risk of being corrupted. If you could selectively turn it off for
    cookies only, a corrupted cookies database would still have negative
    impact on a user.

    Why is this a poor design by FF3 or sqlite and not a poor design by
    the shadowing feature or Norton protected storage? Playing devil's
    advocate you can argue that either way in my opinion.

    I'm not debating that your problem is real. I accept that it's real.
    I'm not sold on the fact that FF3 is the sole party in this problem.
    Journaling is necessary for the integrity of a sqlite database file in
    the event of a crash. I'm sure it's not the only database using this
    feature. Maybe the others that are part of this problem need to also
    be part of the solution?

    JB

  11. Re: bookmarks.html not updating

    On Apr 22, 6:29*pm, "Terry R." wrote:
    >
    > I had asked that there be a setting for the frequency of updating, maybe
    > in about:config. *That way the journaling could be set to hours instead
    > of seconds. *That would take a huge impact off of programs that track
    > file changes. *No response to that.


    In reading a bit more about journaling with sqlite I see that it can
    be turned off by the application. Apparently synching is another
    feature that has a performance impact that can be turned off (not sure
    what it does, just saw that in a discussion on the sqlite mailing
    list). So it looks as if it would be an easy thing to code - possibly
    only one line (PRAGMA journal_mode = OFF, well plus the logic to
    check prefs.js to see if it's on or off so more than one line to
    implement a user configurable setting, but still not difficult from
    the looks of it. And I'm now guessing that you could selectively turn
    off journaling on a per database setting (but maybe not, just guessing
    based on loosely what I quickly read).

    If that's all it takes, if they can't address the negative impact it
    apparently has in some specific environments as you have experienced
    then it would seem like a reasonable alternative to implement this
    option with the warning that doing so turns off that safety net.


    >
    > Maybe they should change the extension names to common extensions that
    > are excluded from a lot of programs that monitor/backup files, rather
    > than it being something new that those types of companies haven't
    > started paying attention to yet.
    >


    Not sure if that can be done by FF3. In reading the FAQ on
    sqlite.org, it talks about journaling and that the resulting file has -
    journal appended to the end of the file name (so .sqlite-journal in
    the case of FF3). I wonder if Google Chrome uses journaling. Haven't
    spent any time checking it out but would be easy to check with ProcMon
    and a filter for path contains "journal".

    > Shadowing's whole design is to keep versions and track files keeping
    > them updated. *SQLite is imposing constant writing to the profile do the
    > same thing. *This sort of updating by two (or more) programs at the same
    > time can impose a lot of unneeded CPU usage and disk writing. *Maybe
    > they could place the journaling files into the program folder instead,
    > and not in the data area. *Norton Protected Bin does what it does well,
    > until you have these journal files being written to hundreds of times a
    > day (if not thousands). *It's doing the job it was designed to do.
    >
    > And that doesn't stop AV software. *Most people I know don't have any
    > idea what is going on with their computer. *Say they install FF. Their
    > AV software now is constantly scanning those writes by SQLite. *They
    > don't know it's happening. *They only see their computer slowing down.
    > If they have backup software that monitors file changes, that would also
    > be doing the same thing. *Did the Mozilla devs not think of the impact
    > this has on a computer?
    >
    > Terry R.
    > --
    > Anti-spam measures are included in my email address.
    > Delete NOSPAM from the email address after clicking Reply.


    As with everything else in computers, there are always different ends
    of the spectrum. They can increase performance by turning off
    journaling. But the impact is in loss of fault tolerance. Just like
    you can increase security but typically at the expense of usability.
    It may not have crossed their mind when implementing that feature that
    it would have that impact on certain environments. Or they may have
    known but felt the benefits (fault tolerance) was worth the
    anticipated performance impact.

    JB

+ Reply to Thread