“places.history.expiration.transient_current_max_pages”下列出的数字到底代表什么？

Firefox about：config页面中的条目“places.history.expiration.transient_current_max_pages”应该设置Firefox记住其历史记录中页面的时间。但是，我在这里看到的当前默认号码是84175.这究竟是什么意思？它不可能是几天，那将是230年！如果它是几个小时，那么它仍然是9。6年，如果它是几分钟，那么它是58天，这似乎是合理的，但它仍然是默认长度的奇怪选择。如果它是秒，它只有23个小时，我知道这是不对的。

啊，我找到了答案。该数字不代表一段时间，它代表Firefox在其历史记录中保留的最大页数。那讲得通。

来自文档：https：//developer.mozilla.org/en-US/docs/Mozilla/Tech/Places/Places_Expiration

places.history.expiration.max_pages：在开始过期之前可以在数据库中保留的最大页数。默认值在启动时计算并放入places.history.expiration.transient_current_max_pages首选项。此偏好的瞬态版本只是镜像到期时使用的当前值，设置它将不会产生任何影响。

https://developer.mozilla.org/en-US/docs/Mozilla/Tech/Places/Places_Expiration

指向实际的源代码。

有趣的部分在这里：https：//dxr.mozilla.org/mozilla-central/source/toolkit/components/places/nsPlacesExpiration.js#143

sql查询中的“：max_uris”将替换为值 places.history.expiration.max_pages

我们看到只有moz_places超过的数量才会删除“常规”页面places.history.expiration.max_pages。（如果要检查当前值，请搜索places.sqlite文件）

但是这个查询似乎也是活跃的：

 // Some visits can be expired more often than others, cause they are less
  // useful to the user and can pollute awesomebar results:
  // 1. urls over 255 chars
  // 2. redirect sources and downloads
  // Note: due to the REPLACE option, this should be executed before
  // QUERY_FIND_VISITS_TO_EXPIRE, that has a more complete result.
  QUERY_FIND_EXOTIC_VISITS_TO_EXPIRE: {
    sql: `INSERT INTO expiration_notify (v_id, url, guid, visit_date, reason)
          SELECT v.id, h.url, h.guid, v.visit_date, "exotic"
          FROM moz_historyvisits v
          JOIN moz_places h ON h.id = v.place_id
          WHERE visit_date < strftime('%s','now','localtime','start of day','-60 days','utc') * 1000000
          AND ( LENGTH(h.url) > 255 OR v.visit_type = 7 )
          ORDER BY v.visit_date ASC
          LIMIT :limit_visits`,
    actions: ACTION.TIMED_OVERLIMIT | ACTION.IDLE_DIRTY | ACTION.IDLE_DAILY |
             ACTION.DEBUG,
  },

动作列表表明每天都会运行。

它不依赖于expiration.max_pages，如果我正确读取的代码它删除访问（而不是实际的URL，但网址是如何访问记录）是重定向或属于以上255个字符的URL的网页。

还有这个：

  // Finds orphan URIs in the database.
  // Notice we won't notify single removed URIs on History.clear(), so we don't
  // run this query in such a case, but just delete URIs.
  // This could run in the middle of adding a visit or bookmark to a new page.
  // In such a case since it is async, could end up expiring the orphan page
  // before it actually gets the new visit or bookmark.
  // Thus, since new pages get frecency -1, we filter on that.
  QUERY_FIND_URIS_TO_EXPIRE: {
    sql: `INSERT INTO expiration_notify (p_id, url, guid, visit_date)
          SELECT h.id, h.url, h.guid, h.last_visit_date
          FROM moz_places h
          LEFT JOIN moz_historyvisits v ON h.id = v.place_id
          WHERE h.last_visit_date IS NULL
            AND h.foreign_count = 0
            AND v.id IS NULL
            AND frecency <> -1
          LIMIT :limit_uris`,
    actions: ACTION.TIMED | ACTION.TIMED_OVERLIMIT | ACTION.SHUTDOWN_DIRTY |
             ACTION.IDLE_DIRTY | ACTION.IDLE_DAILY | ACTION.DEBUG,
  },

表示网址（又名“地点”）专属于此类访问将被稍后清除..（不确定h.foreign_count是什么）

这h.last_visit_date IS NULL似乎可以拯救大多数地方，但我有一堆“null last_visit_date”的地方，我肯定会去过。

结论：

即使places.history.expiration.max_pages未超过，Firefox也会删除历史记录...

特别是长于255个字符的网址和下载网址。（此页面的网址为119个字符长）

更新：我已根据之前的places.sqlite备份验证我的firefox安装（100k位置，max_pages设置为500k）在过去三个月内删除了325个位置。

大多数缺失的条目都是垃圾。例如。“跟踪器网址”最终会重定向到保留的较短网址（Facebook，谷歌等是主要的“违规者”）

问题不在于这些跟踪器网址已经消失，但他们的访问也消失了，打破了链条。

例：

答：点击跟踪器网址时的网址：google.com/search?q=give-me-news

B：删除了跟踪器网址：https：//www.google.com/url？ sa = t＆rct = j＆q =＆ esrc = s ＆so ......

C：实际网址：some-newspaper.com/articleX

当我点击B时，创建了两个访问，A - > B和B - > C.

这使我后来发现我读了articleX因为我搜索了“给我新闻”

Firefox删除了访问A - > B，因为B的url是垃圾而且没有意义，并且突然变得更难以追溯到源。仍然可以做出好的猜测，但它不再是一个简单的SQL查询。

如果firefox坚持要删除这些网址（这可能是正确的做法，如果他们可以离开访问或修改影响访问将会很好。即修改B - > C为A - > C，可能记录链中的链接已被删除。

上一篇：为什么他们坚持要删除我没有得到的下载 - 我的很多下载在网址中都有有意义的文件名，有时候会有助于在omnibar中获得建议。（例如，季度报告）

每60天进行一次备份似乎足以保留所有历史记录。sqlite不重用旧的ID（我认为？）所以合并备份不应该太难。