places.history.expiration.transient_current_max_pages
Firefox 页面中的条目about:config
应该设置 Firefox 在其历史记录中记住页面的时间。
但是,我在这里看到的当前默认数字是 84175。这到底代表什么?它不可能是几天,那将是 230 年!
如果是小时,那么它仍然是 9.6 年,如果是分钟,那么它就是 58 天,这似乎是合理的,但对于默认长度来说,这仍然是一个奇怪的选择。如果是秒,它只有 23 小时,我知道这肯定是不对的。
答案1
这官方文档不再可用(也无法找到新位置)。
places.history.expiration.max_pages:在开始过期之前,数据库中可以保留的最大页面数。默认值在启动时计算并放入 places.history.expiration.transient_current_max_pages 首选项中。此首选项的临时版本只是反映过期使用的当前值,设置它不会产生任何效果。
transient_current_max_pages
在源代码中不再提及。
“地点数据库”部分关于:支持可以用来获取有用的信息。(注意:运行似乎会运行清理 - 请先备份数据库)
指向实际的源代码。
有趣的部分如下:https://searchfox.org/mozilla-central/source/toolkit/components/places/PlacesExpiration.sys.mjs#120
:max_uris
在 SQL 查询中被替换为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,而是 URL 访问方式的记录)是重定向或属于 URL 长度超过 255 个字符的页面。
和这个:
// 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,
},
表示专属于此类访问的 URL(又名“地点”)稍后将被清除。(不确定 h.foreign_count 是什么)
这h.last_visit_date IS NULL
似乎可以保存大多数地方,但我有很多地方的 last_visit_date 都是“null”,而我肯定去过这些地方。
综上所述:
即使places.history.expiration.max_pages
没有超过... Firefox 也会删除历史记录...
特别是长度超过 255 个字符的 URL 和下载 URL。(此页面的 URL 长度为 119 个字符)
更新:
我已经根据 places.sqlite 的先前备份验证了我的 Firefox 安装(100k 个地方,max_pages
设置为 500k)在过去三个月内删除了 325 个地方。
大多数缺失的条目都是垃圾。例如,“跟踪器网址”最终会重定向到保留的较短网址(Facebook、Google 等是主要的“罪犯”)
问题不在于这些跟踪器 URL 消失了,而是它们的访问量也消失了,从而断掉了链条。
例子:
- 我点击跟踪器网址时的网址:google.com/search?q=give-me-news
- 删除的跟踪器网址:https://www.google.com/url?sa=t&rct=j&q=&esrc=s&so.....。
- 实际网址:some-newspaper.com/articleX
当我点击 B 时,产生了两次访问,A -> B 和 B -> C
这样我以后就能发现我读了文章 X,因为我搜索了“give-me-news”
Firefox 删除了访问 A -> B,因为 B 的 URL 是垃圾,不值得保留,而且突然间追溯到源头变得更加困难。仍然可以做出正确的猜测,但它不再是一个简单的 SQL 查询。
如果 Firefox 坚持要删除此类 URL(这很可能是正确的做法,那么如果他们可以保留访问或修改影响访问,那就太好了。例如,将 B -> C 修改为 A -> C,可能保留链中链接已被删除的记录。
最后的:
为什么他们坚持删除我不明白的下载内容 - 我的许多下载内容在 URL 中都有有意义的文件名,有时将其作为多功能栏中的建议会很有帮助。(例如季度报告)
每 60 天进行一次备份似乎足以保留所有历史记录。sqlite 不会重复使用旧 ID(我想?)因此合并备份应该不会太难。
答案2
来自文档:https://developer.mozilla.org/en-US/docs/Mozilla/Tech/Places/Places_Expiration
地点.历史.过期.最大页数:在开始过期之前数据库中可以保留的最大页面数。默认值在启动时计算并放入places.history.expiration.transient_current_max_pages偏好。此临时版本的偏好只是反映到期使用的当前值,设置它不会产生任何效果。
答案3
啊哈,我找到答案了。这个数字并不代表时间,而是代表 Firefox 在其历史记录中保留的最大页面数。这很有道理。