Closed Bug 241438 Opened 21 years ago Closed 19 years ago

please make history.dat easier to parse (i.e., not Mork)

Categories

(Core Graveyard :: History: Global, defect)

Product:
Core Graveyard
Component:
History: Global
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: jwz, Unassigned)

Details

(Whiteboard: WFM by Places for Firefox 3.0 (uses SQLite), WONTFIX for SeaMonkey)

Attachments

(3 files)

Bookmarklet to export history to RDF/XML
1.23 KB, text/plain
Details
Python script to convert mork to valid XML
12.51 KB, text/plain
Details
Utility (Win32) to export the HISTORY.DAT file to a tab delimited text file.
225.35 KB, application/octet-stream
Details
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040116 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040116 It is impossible for non-Mozilla programs to extract data from ~/.mozilla/*/*.slt/history.dat because it uses Mork, which is -- and I do not use these words lightly -- the single most braindamaged file format that I have ever seen in my nineteen year career. Please make history.dat contain something sane, like tab-delimited fields, or XML. I have tried to write a parser for Mork in Perl, and it will never work right. The depths of depravity to which this format sinks are too great. You can see it here: http://www.jwz.org/hacks/mork.pl Safari does the following. It is sane and beautiful. <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>WebHistoryDates</key> <array> <dict> <key></key> <string>http://www.livejournal.com/users/jwz/312657.html</string> <key>lastVisitedDate</key> <string>104399495.8</string> <key>title</key> <string>jwz - when the database worms eat into your brain</string> <key>visitCount</key> <integer>1</integer> </dict> <dict> <key></key> <string>http://www.jwz.org/hacks/mork.pl</string> <key>lastVisitedDate</key> <string>104399393.0</string> <key>title</key> <string>mork.pl</string> <key>visitCount</key> <integer>1</integer> </dict> ...etc. Reproducible: Always Steps to Reproduce:
I'm with jwz on this one, mork is just plain goofy. Make it rdf, or xml, or something trivial to parse like most of the other files Mozilla stores data in.
Agreed, you got my vote
Is there even documentation on mork?
> Is there even documentation on mork? Extremely little, and nearly incomprehensible: http://www.mozilla.org/mailnews/arch/mork/primer.txt http://www.mozilla.org/mailnews/arch/mork/grammar.txt As I said above, I tried to reverse-engineer it in Perl; my analysis of it, from http://www.jwz.org/hacks/mork.pl -- # In Netscape Navigator 1.0 through 4.0, the history.db file was just a # Berkeley DBM file. You could trivially bind to it from Perl, and # pull out the URLs and last-access time. In Mozilla, this has been # replaced with a "Mork" database for which no tools exist. In brief, # let's count its sins: # # - Two different numerical namespaces that overlap. # # - It can't decide what kind of character-quoting syntax to use: # Backslash? Hex encoding with dollar-sign? # # - C++ line comments are allowed sometimes, but sometimes // is just # a pair of characters in a URL. # # - It goes to all this serious compression effort (two different # string-interning hash tables) and then writes out Unicode strings # without using UTF-8: writes out the unpacked wchar_t characters! # # - Worse, it hex-encodes each wchar_t with a 3-byte encoding, # meaning the file size will be 3x or 6x (depending on whether # whchar_t is 2 bytes or 4 bytes.) # # - It masquerades as a "textual" file format when in fact it's just # another binary-blob file, except that it represents all its magic # numbers in ASCII. It's not human-readable, it's not hand-editable, # so the only benefit there is to the fact that it uses short lines # and doesn't use binary characters is that it makes the file bigger. # Oh wait, my mistake, that isn't actually a benefit at all. For comedic value: http://www.livejournal.com/users/jwz/312657.html
Summary: please make history.dat be machine-parsable (i.e., not Mork) → please make history.dat easier to parse (i.e., not Mork)
Bug 245745 is to replace history mork database with sqlite.
I note from >http://www.treedragon.com/ged/map/ti/newJun02.htm#30jun02-mork-grammar> that the original author not only hasn't worked on it in a long while, but doesn't care about it. He also admits that it is undocumented, and that he was never asked for such. Is anyone actually maintaining it in a real way, or is it in the "don't touch it, and it won't explode category?" I note that someone has suggested that sqlite be used. How does this affect the on disk format of the file? I was under the impression that the history file contains the URL, and access count, and the time of last access. How about this as a file format?: <properly escaped URL>,<access count>,<time of last access> While I'll agree that the XML encoded version is clear, it's also stupidly verbose. A more complicated database might need such markup for efficiency, but a three field, nothing null, no relations database? It's like using a 24 foot diesel truck to pick up a six pack of beer. Now, I'd be happy to see a well thought out and standard database access method be used for all the various databases inside this beast. Certainly the addressbooks could benefit from such a move. And I'd even say that it's storage format should be XML or maybe LDIF. But where leave the simple things simple. CSV is your friend.
History will, along with other things, most likely end up in a SQLite database. It won't be parsable "by hand", but through the command line sqlite3 client, DBD::SQLite or a million other wrappers, it should solve a lot of these problems. Stay tuned. Mork my words, mork-no-more!
(In reply to vladimir, comment #8) > .... Mork my words, mork-no-more! I hope that nobody will answer: MORK´S FOR ME (not).
Yes, please get rid of mork ASAP!!! It looks like old data is just left there unreferenced, yeah even the cell with the pointers to the data is left in place and there is just a new cell with the same index appended to the end... I couldn't believe what I was seeing, and I still can't believe this "format" made it that far into the project. I would like to synchronize my address book remotely over a narrow bandwidth connection, and with mozilla's built-in roaming support mork becomes more absurd than ever.
Here is a simple javascript to get the history data in a format easier to read. Be sure that you need to run it from a trusted context to enable UniversalXPConnect privilege. Good things about storing history data in RDF/XML, 1. Easier to read. 2. We can possibly do without mork code. (we cannot do this yet because formhistory.dat also uses mdb:mork.) Bad things... 1. Exported history.rdf.txt is always larger than history.dat. 2. RDF/XML Serializer is very slow and memory-consuming. It takes more than one minute if the history is large. (Bug 259119 will be fixed soon)
By the way, another monstruosity written in Mork is Mozilla / Thunderbird addressbook. If it was *anything* else, we could parse it and e.g. have it print a booklet through TeX. With Mork we are stuck in the dark exactly the way Outlook Express does!
(In reply to comment #8) > History will, along with other things, most likely end up in a SQLite database. Not Another DB! A more general solution would be something like a JDBC or ODBC interface, so Moz etc can use the local DBMS for which tools are already familiar & set up, thereby reducing the already-steep learning curve slope.
(In reply to comment #13) > A more general solution would be something like a JDBC or ODBC interface Now *that* would be bloat. Not only would it be bloat, it would actually require an entire *database* *server* just to store a freaking history log. (SQLite would be fine. If you don't know about it, educate yourself before you make such comments.)
(In reply to comment #14) >> A more general solution would be something like a JDBC or ODBC interface > Now *that* would be bloat. Not only would it be bloat, it would actually require > an entire *database* *server* just to store a freaking history log. > > (SQLite would be fine. If you don't know about it, educate yourself before you > make such comments.) You missed my point. I said: "***Not Another DB!*** A more general solution would be something like a JDBC or ODBC ***interface***, so Moz etc can use the ***local*** DBMS". Please refer to *** highlighting above. I HAVE a DBMS. I don't need or want another one. I want all my relevant data in one consistent system, not scattered about in a plethora of weird formats. I would like ALL the Moz data in one accessable system.
(In reply to comment #15) > I HAVE a DBMS. That's great. Do the majority of end users have a DB server installed? Do you expect them to install and manage one? > I don't need or want another one. Regard SQLite as a kind of souped up BerkeleyDB that happens to understand SQL. There's no server. Nor should there be one. Actually forget the fact that you saw the letters "SQL" anywhere. The day Mozilla requires a DB server just to run is the day I switch to another browser. Thankfully, I believe the people who are actually doing the work (as opposed to just mouthing off, like, say, you or I) have more clue than that.
(In reply to comment #16) > (In reply to comment #15) > > I HAVE a DBMS. > That's great. Do the majority of end users have a DB server installed? No, that I have seen. Although Debian Linux seems to install MySQL by default. > Regard SQLite as a kind of souped up BerkeleyDB that happens to understand SQL. And can be accessed via, say, JDBC ? > There's no server. Nor should there be one. > The day Mozilla requires a DB server just to run is the day I switch to another browser. I agree. Any type of server should not be a requirement to run Moz. My response was an oversimplification that did not include other options. I would like the option of saving all Moz data to MY data system where I can deal with it in a consistent manner, not having to translate from yet another format. See Mozilla2:Unified Storage in MozillaWiki for another alternative.
> And can be accessed via, say, JDBC ? Yes, and ODBC, libdbi, ADO.NET (including Mono), Perl-DBI, PHP PEAR DB, Python DBAPI, Tcl/Tk, and many others too: http://www.ch-werner.de/javasqlite/ http://www.ch-werner.de/sqliteodbc/ http://www.itwriting.com/sqlitenotes.php http://www.sqlite.org/cvstrac/wiki?p=SqliteWrappers I hope the above links help to show that this is a non-issue, and I would kindly ask you to stop spamming this bug's comments.
This python script (based on a "mork-mindy converter" originally written by a fellow at Stanford, butchered by mhoye@off.net) converts mork files to something reasonably XMLish. I hope that it's useful for bridging the gap between Mork and a sane non-Mork future.
Comment on attachment 175024 [details] Python script to convert mork to valid XML #!/usr/bin/env python #========================================================================== # Original "Mindy.py" copyright: Kumaran Santhanam # <kumaran@alumni.stanford.org> # # Subsequent butchery, demork.py: Mike Hoye # <mhoye@off.net> # # Just to be crystal clear about this, Santhanam did all the heavy lifting # (i.e. Mork-scraping) here, but apparently the strain of working on mork # broke him; the "mindy" output was _another_ bizzare home-rolled database # format, except this one had lots of "@" symbols in it. # # This is a straight-up pattern-recognition hack; I've never worked with # Python or XML before, but not only does this spit out valid XML, if you # drink a big glass of water while you're using it you might cure your # hiccups. # #-------------------------------------------------------------------------- # Project : demork - takes in Mork files, spits out XML # File : demork.py # Version : 0.3 #-------------------------------------------------------------------------- # This program is free software; you can redistribute it and/or # modify it under the terms of the GNU General Public License # Version 2 (1991) as published by the Free Software Foundation. # # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU General Public License for more details. # # For the full text of the GNU General Public License, refer to: # http://www.fsf.org/licenses/gpl.txt # # For alternative licensing terms, please contact the author. #-------------------------------------------------------------------------- # # This widget has hardcoded XML entity tags in places that make it pretty # much specifically meant for the Mozilla history.db file. They're tagged # with a "#HDBXML" comment nearby, for easy searching and replacing if # you intend to do anything else with this and want semantics that make # some kind of sense. # # Version 0.1 was the first run at this, which was (as advertised) # only xml-ish. # # Version 0.3 now includes a DTD in the XML output, and escapes the # ampersands in long URLs, making for valid XML. # # "If it breaks, feel free to keep both parts." - JWZ # #========================================================================== #========================================================================== # IMPORTS #========================================================================== import sys import re import getopt from sys import stdin, stdout, stderr #========================================================================== # GLOBALS #========================================================================== VERSION = "0.3" #========================================================================== # FUNCTIONS #========================================================================== def usage (): print print "demork - A Mork -> XML converter" print print "Version %s, (c) Mike Hoye, 2005." % VERSION print "Based on a Mork/Mindy converter, (c) 2005 Kumaran Santhanam." print print "usage: demork MORKFILE" print print "The converted output is dumped to STDOUT." print "A filename of '-' will take input from STDIN." print #========================================================================== # DATABASE #========================================================================== class Database: def __init__ (self): self.cdict = { } self.adict = { } self.tables = { } class Table: def __init__ (self): self.id = None self.scope = None self.kind = None self.rows = { } class Row: def __init__ (self): self.id = None self.scope = None self.cells = [ ] class Cell: def __init__ (self): self.column = None self.atom = None #========================================================================== # UTILITIES #========================================================================== def invertDict (dict): idict = { } for key in dict.keys(): idict[dict[key]] = key return idict def hexcmp (x, y): try: a = int(x, 16) b = int(y, 16) if a < b: return -1 if a > b: return 1 return 0 except: return cmp(x, y) #========================================================================== # MORK INPUT #========================================================================== def escapeData (match): return match.group() \ .replace('\\\\n', '$0A') \ .replace('\\)', '$29') \ .replace('>', '$3E') \ .replace('}', '$7D') \ .replace(']', '$5D') pCellText = re.compile(r'\^(.+?)=(.*)') pCellOid = re.compile(r'\^(.+?)\^(.+)') pCellEscape = re.compile(r'((?:\\[\$\0abtnvfr])|(?:\$..))') backslash = { '\\\\' : '\\', '\\$' : '$', '\\0' : chr(0), '\\a' : chr(7), '\\b' : chr(8), '\\t' : chr(9), '\\n' : chr(10), '\\v' : chr(11), '\\f' : chr(12), '\\r' : chr(13) } def unescapeMork (match): s = match.group() if s[0] == '\\': return backslash[s] else: return chr(int(s[1:], 16)) def decodeMorkValue (value): global pCellEscape return pCellEscape.sub(unescapeMork, value) def addToDict (dict, cells): for cell in cells: eq = cell.find('=') key = cell[1:eq] val = cell[eq+1:-1] dict[key] = decodeMorkValue(val) def getRowIdScope (rowid, cdict): idx = rowid.find(':') if idx > 0: return (rowid[:idx], cdict[rowid[idx+2:]]) else: return (rowid, None) def delRow (db, table, rowid): (rowid, scope) = getRowIdScope(rowid, db.cdict) if scope: rowkey = rowid + "/" + scope else: rowkey = rowid + "/" + table.scope if table.rows.has_key(rowkey): del table.rows[rowkey] def addRow (db, table, rowid, cells): global pCellText global pCellOid row = Row() (row.id, row.scope) = getRowIdScope(rowid, db.cdict) for cell in cells: obj = Cell() cell = cell[1:-1] match = pCellText.match(cell) if match: obj.column = db.cdict[match.group(1)] obj.atom = decodeMorkValue(match.group(2)) else: match = pCellOid.match(cell) if match: obj.column = db.cdict[match.group(1)] obj.atom = db.adict[match.group(2)] if obj.column and obj.atom: row.cells.append(obj) if row.scope: rowkey = row.id + "/" + row.scope else: rowkey = row.id + "/" + table.scope if table.rows.has_key(rowkey): print >>stderr, "ERROR: duplicate rowid/scope %s" % rowkey print >>stderr, cells table.rows[rowkey] = row def inputMork (data): # Remove beginning comment pComment = re.compile('//.*') data = pComment.sub('', data, 1) # Remove line continuation backslashes pContinue = re.compile(r'(\\(?:\r|\n))') data = pContinue.sub('', data) # Remove line termination pLine = re.compile(r'(\n\s*)|(\r\s*)|(\r\n\s*)') data = pLine.sub('', data) # Create a database object db = Database() # Compile the appropriate regular expressions pCell = re.compile(r'(\(.+?\))') pSpace = re.compile(r'\s+') pColumnDict = re.compile(r'<\s*<\(a=c\)>\s*(?:\/\/)?\s*(\(.+?\))\s*>') pAtomDict = re.compile(r'<\s*(\(.+?\))\s*>') pTable = re.compile(r'\{-?(\d+):\^(..)\s*\{\(k\^(..):c\)\(s=9u?\)\s*(.*?)\}\s*(.+?)\}') pRow = re.compile(r'(-?)\s*\[(.+?)((\(.+?\)\s*)*)\]') pTranBegin = re.compile(r'@\$\$\{.+?\{\@') pTranEnd = re.compile(r'@\$\$\}.+?\}\@') # Escape all '%)>}]' characters within () cells data = pCell.sub(escapeData, data) # Iterate through the data index = 0 length = len(data) match = None tran = 0 while 1: if match: index += match.span()[1] if index >= length: break sub = data[index:] # Skip whitespace match = pSpace.match(sub) if match: index += match.span()[1] continue # Parse a column dictionary match = pColumnDict.match(sub) if match: m = pCell.findall(match.group()) # Remove extraneous '(f=iso-8859-1)' if len(m) >= 2 and m[1].find('(f=') == 0: m = m[1:] addToDict(db.cdict, m[1:]) continue # Parse an atom dictionary match = pAtomDict.match(sub) if match: cells = pCell.findall(match.group()) addToDict(db.adict, cells) continue # Parse a table match = pTable.match(sub) if match: id = match.group(1) + ':' + match.group(2) try: table = db.tables[id] except KeyError: table = Table() table.id = match.group(1) table.scope = db.cdict[match.group(2)] table.kind = db.cdict[match.group(3)] db.tables[id] = table rows = pRow.findall(match.group()) for row in rows: cells = pCell.findall(row[2]) rowid = row[1] if tran and rowid[0] == '-': rowid = rowid[1:] delRow(db, db.tables[id], rowid) if tran and row[0] == '-': pass else: addRow(db, db.tables[id], rowid, cells) continue # Transaction support match = pTranBegin.match(sub) if match: tran = 1 continue match = pTranEnd.match(sub) if match: tran = 0 continue match = pRow.match(sub) if match and tran: print >>stderr, "WARNING: using table '1:^80' for dangling row: %s" % match.group() rowid = match.group(2) if rowid[0] == '-': rowid = rowid[1:] cells = pCell.findall(match.group(3)) delRow(db, db.tables['1:80'], rowid) if row[0] != '-': addRow(db, db.tables['1:80'], rowid, cells) continue # Syntax error print >>stderr, "ERROR: syntax error while parsing MORK file" print >>stderr, "context[%d]: %s" % (index, sub[:40]) index += 1 # Return the database return db #========================================================================== # XML out # # All these "mindy" references are holdovers from this program's previous # life. Like I said, I don't speak python, and it's not broke... -mhoye #========================================================================== pMindyEscape = re.compile('([\x00-\x1f\x80-\xff\\\\])') def escapeMindy (match): s = match.group() if s == '\\': return '\\\\' if s == '\0': return '\\0' if s == '\r': return '\\r' if s == '\n': return '\\n' return "\\x%02x" % ord(s) def encodeMindyValue (value): global pMindyEscape return pMindyEscape.sub(escapeMindy, value) def outputMindy (db): #HDBXML columns = db.cdict.keys() columns.sort(hexcmp) tables = db.tables.keys() tables.sort(hexcmp) print '<?xml version="1.0" standalone="yes"?>' #I need to put a DTD right.... here! print '<!DOCTYPE history [' print '<!ELEMENT history ANY>' for column in columns: name = db.cdict[column] if name.find('ns:') != 0: print ' <!ELEMENT %s ANY>' % name print ' <!ELEMENT entry ANY>' print ' ]>' print '<history>' for table in [ db.tables[k] for k in tables ]: rows = table.rows.keys() rows.sort(hexcmp) for row in [ table.rows[k] for k in rows ]: print ' <entry>' # print ' <entry table="%s" row="%s">' % (table.id, row.id) for cell in row.cells: print ' <%s>%s</%s>' % (cell.column, re.search('s/&/&amp;/', encodeMindyValue(cell.atom)), cell.column) print ' </entry>' print '</history>' #========================================================================== # MAIN PROGRAM #========================================================================== def main (argv=None): if argv is None: argv = sys.argv # Parse the command line arguments try: opts, args = getopt.getopt(argv[1:], "ht") except: print "Invalid command-line argument" usage() return 1 # Process the switches optTest = 0 for o, a in opts: if o in ("-h"): usage() return 0 elif o in ("-t"): optTest = 1 # Read the filename if (len(args) != 1): usage() return 1 filename = args[0] # Read the file into memory if (filename != '-'): file = open(filename, "rt") else: file = stdin data = file.read() file.close() # Determine the file type and process accordingly if (data.find('<mdb:mork') >= 0): db = inputMork(data) outputMindy(db) else: print "unknown file format: %s (I only deal with Mork, sorry)" % filename return 1 # Return success return 0 if (__name__ == "__main__"): result = main() # Comment the next line to use the debugger sys.exit(result)
Attachment #175024 - Attachment description: Python script to convert mork to XML(ish) → Python script to convert mork to valid XML
mhoye AT neon.polkaroo.net: Please don't use Edit Attachment As Comment when you don't want to comment on parts of the attachment :) (you just pasted the whole attachment as comment). Or did you want to attach a new version of it? Then use Create a New Attachment again.
(In reply to comment #21) > Please don't use Edit Attachment As Comment when you > don't want to comment on parts of the attachment :) I'm sorry, I had no idea it would do that. I should add here that I'm rewriting that python thing in javascript, in the hopes that it can become part of some migration mechanism. When I'm done I'll make a note here so that it can be tested, and maybe somebody smarter than me can wedge it into the install process.
The mork format is baroque and unreadable. Please remove this blight from the project and utilize an established, open standard format like valid XML for the history file and other places which are using mork. It is not acceptable to require the use of a perl/python script to parse the history.dat file into a usable format.
Blocks: majorbugs
No longer blocks: majorbugs
The solution is being formed. http://wiki.mozilla.org/Mozilla2:Unified_Storage
Also the address book should not be on this format, it's impossible to write any automated scripts to migrate from other e-mail clients to Mozilla because of this.
Here's some more info on the (terrible) Mork format: http://www.erys.org/resume/netscape/mork/what.html
Regarding Comment #19 (version 0.3 of the demork.py script): To get it to work, I had to replace the re.search() call with re.sub(). I also added entity substitution of <. I still get a lot of "using table --- for dangling row: ---" warnings when I run it, but the output looks useful. Here is my demork.py patch: --- demork-0.3.py 2005-11-21 11:28:33.000000000 -0500 +++ demork-0.3+hacked.py 2005-11-21 14:18:22.817678608 -0500 @@ -403,17 +403,17 @@ for table in [ db.tables[k] for k in tables ]: rows = table.rows.keys() rows.sort(hexcmp) for row in [ table.rows[k] for k in rows ]: print ' <entry>' # print ' <entry table="%s" row="%s">' % (table.id, row.id) for cell in row.cells: - print ' <%s>%s</%s>' % (cell.column, re.search('s/&/&amp;/', encodeMindyValue(cell.atom)), cell.column) + print ' <%s>%s</%s>' % (cell.column, re.sub('<', '&lt;', re.sub('&', '&amp;', encodeMindyValue(cell.atom))), cell.column) print ' </entry>' print '</history>' #========================================================================== # MAIN PROGRAM #========================================================================== def main (argv=None):
(In reply to comment #0) Someone could explain me how firefox does the parse of the history.dat? I know there is a parser included in the mozilla source code (mozilla/db/mork/), but I'm developing my own mozilla based browser and wanna use it. I've googled and just found some scripts in perl, but nothing about the mozilla parser.
To add to the fun i converted the python script I nicked from here to Java. Get it here: http://www.semikolon.co.uk/blog/index.php?entry=entry060309-160008 - Gunnar
A quickly-written utility to export the HISTORY.DAT file to a tab-delimited text file. (Win32)
What is the impact of Places on this?
I think places resolves this by replacing Mork.
I guess the future of this bug would be for Seamonkey. Is there a more appropriate product now?
This is a waste of our limited developer resources, in my opinion.
In that case...
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
(In reply to comment #35) > In that case... > So. What exactly is the "fix"? Reading the last few comments, I have the impression that since "This is a waste of our limited developer resources" it has been decided to do nothing. But then it shouldn't be marked "fixed". Maybe the fix relates to "places", whatever that is. Could comeone please add a comment telling what the fix was and how we will (in some future unspecified release) be able to parse bookmarks? Thanks.
REOPEN to re-resolve.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
-> WFM by Places for Firefox 2.0 -> WONTFIX for SeaMonkey
Status: REOPENED → RESOLVED
Closed: 19 years ago → 19 years ago
Resolution: --- → WONTFIX
(In reply to comment #36) > So. What exactly is the "fix"? The new "Places" functionality in Firefox 2.0 has moved the storage of history to sqlLite instead of history.dat (mork format). So now if you know industry standard sql, you should be able to easily query history data from Firefox. At least that is my understanding.
(In reply to comment #39) > (In reply to comment #36) > > So. What exactly is the "fix"? > > The new "Places" functionality in Firefox 2.0 has moved the storage of history > to sqlLite instead of history.dat (mork format). So now if you know industry > standard sql, you should be able to easily query history data from Firefox. At > least that is my understanding. Any chance of an example to verify/test this bug?
Whiteboard: WFM by Places for Firefox 3.0 (uses SQLite), WONTFIX for SeaMonkey
I tried to follow the thread above, but got lost. Has "history.dat" been cracked? I would very much be interested in a utility that allows me to read/view the contents of the history.dat file. I'm not a techy and wasn't able to follow the email thread and code above. Is there any easy to run utility that i could use solve this problem?
Use http://www.jwz.org/hacks/mork.pl , which is mentioned in the original submission, usually works. This is a perl program; you'll need perl to run it. If you don't know what that means, you can start here: http://www.perl.com/download.csp
The ultimate solution to this bug is a complete reimplementation: in 3.0, History and bookmarks are implemented using a database: http://developer.mozilla.org/en/docs/Places:History_Service From previous comments, there is no fix scheduled for the current release branch.
RESOLVED WORKSFORME? or FIXED?
Now that Firefox3 is saving history using SQLite (Bug 242207) it may be time to close this bug. Do you have any plans to purge the piece of **** of Mork from Mozilla codebase?
If mork is still used for Address books in Thunderbird it might still be needed for that. And if it is still used in TB then it needs be expunged with prejudice ASAP.
Which first public release of seamonkey will use the core with the sqlite? Is that a seamonkey 1.2, 2.0? What's going on? Can't kill that beauty, can'ya? Thanks!
If any of you know the bug # to port Address books in Thunderbird from Mork to SQLite, please attach it here. Or should we open a general "Purge Mork" that depends on these bugs? I would like to see Thunderbird Mork free so I can test it again if it would meet my needs and even start recommending it.
(In reply to comment #48) > If any of you know the bug # to port Address books in Thunderbird from Mork to > SQLite, please attach it here. Bug 382876.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: