4

Запись "place.history.expiration.transient_current_max_pages" в Firefox на странице about:config должна указывать количество времени, которое Firefox запоминает страницы в своей истории. Тем не менее, текущий номер по умолчанию, который я вижу здесь, 84175. Что на земле это может представлять ??? Это не могут быть дни, которые выйдут на 230 лет! Если это часы, то это еще 9,6 года, а если это минуты, то это 58 дней, и это кажется разумным, но это по-прежнему странный выбор для длины по умолчанию. Если секунд, то только 23 часа, и я ЗНАЮ, что это не может быть правдой.

3 ответа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 не использует старые идентификаторы (я думаю?) поэтому объединение резервных копий не должно быть слишком сложным.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .