Запись "place.history.expiration.transient_current_max_pages" в Firefox на странице about:config должна указывать количество времени, которое Firefox запоминает страницы в своей истории. Тем не менее, текущий номер по умолчанию, который я вижу здесь, 84175. Что на земле это может представлять ??? Это не могут быть дни, которые выйдут на 230 лет! Если это часы, то это еще 9,6 года, а если это минуты, то это 58 дней, и это кажется разумным, но это по-прежнему странный выбор для длины по умолчанию. Если секунд, то только 23 часа, и я ЗНАЮ, что это не может быть правдой.
3 ответа
1
Аааа, я нашел ответ. Число не представляет количество времени, оно представляет максимальное количество страниц, которые Firefox хранит в своей истории. В этом есть смысл.
1
Из документов: https://developer.mozilla.org/en-US/docs/Mozilla/Tech/Places/Places_Expiration
place.history.expiration.max_pages: максимальное количество страниц, которые могут быть сохранены в базе данных до начала срока действия. Значение по умолчанию рассчитывается при запуске и помещается в предпочтение мест.history.expiration.transient_current_max_pages . Эта временная версия предпочтения просто отражает текущее значение, используемое по истечении срока, установив, что это не будет иметь никакого эффекта.
0
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
«:max_uris» в запросах sql заменяется на значение places.history.expiration.max_pages
Мы видим, что "обычные" страницы удаляются только в том случае, если количество moz_places превышает places.history.expiration.max_pages . (найдите файл place.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 спасет большинство мест, но у меня есть куча мест с "null last_visit_date", которые я наверняка посетил.
В заключение:
Firefox удалит историю, даже если places.history.expiration.max_pages не превышено ...
В частности, URL-адреса длиннее 255 символов и ссылки для скачивания. (URL этой страницы длиной 119 символов)
Обновление: я проверил на основе предыдущей резервной копии place.sqlite, что моя установка Firefox (100k мест, max_pages установлено на 500k) удалила 325 мест за последние три месяца.
Большинство пропущенных записей - мусор. например. «URL-адреса трекера», которые в конечном итоге перенаправляют на сохраненный более короткий URL-адрес (Facebook, Google и т. д. являются основными "нарушителями")
Проблема не в том, что эти URL-адреса трекера пропали, но их посещения также пропали, разрывая цепь.
Пример:
A: URL, когда я нажал на URL трекера: google.com/search?д = дать-мне-новости
B: удален URL-адрес трекера: https://www.google.com/url?sa=t&rct=j&q=&esrc=s&so......
C: Фактический URL: some-newspaper.com/articleX
Когда я нажал на B, было создано два посещения, A -> B и B -> C
Это позволяет мне позже узнать, что я прочитал статью X, потому что я искал "дай мне новости"
Firefox удаляет посещение A -> B, потому что URL-адрес B является мусором и не представляет интереса для хранения, и внезапно его становится намного сложнее отследить до источника. Все еще возможно сделать правильное предположение, но это больше не простой запрос SQL.
Если firefox настаивает на удалении таких URL-адресов (что вполне может быть правильным решением, было бы хорошо, если бы они могли либо покинуть посещение, либо изменить посещение с целью изменения). То есть. измените B -> C, чтобы быть A -> C, возможно сохраняя запись, что ссылка в цепочке была удалена.
Последнее: почему они настаивают на удалении загрузок, которые я не получаю - у многих моих загрузок есть значимые имена файлов в URL-адресе, и иногда было бы полезно получить рекомендации в омнибар. (например, квартальные отчеты)
Резервное копирование каждые 60 дней кажется достаточным для сохранения всей истории. sqlite не использует старые идентификаторы (я думаю?) поэтому объединение резервных копий не должно быть слишком сложным.