Join the Mozilla’s Test Days event from 9–15 Jan to test the new Firefox address bar on Firefox Beta 135 and get a chance to win Mozilla swag vouchers! 🎁

ძიება მხარდაჭერაში

ნუ გაებმებით თაღლითების მახეში მხარდაჭერის საიტზე. აქ არასდროს მოგთხოვენ სატელეფონო ნომერზე დარეკვას, შეტყობინების გამოგზავნას ან პირადი მონაცემების გაზიარებას. გთხოვთ, გვაცნობოთ რამე საეჭვოს შემჩნევისას „დარღვევაზე მოხსენების“ მეშვეობით.

ვრცლად

folderCache.json and empty "Recent" folders

  • 2 პასუხი
  • 0 მომხმარებელი წააწყდა მსგავს სიძნელეს
  • ბოლოს გამოეხმაურა John Kaufmann

[Note: I characterized this question as an "Installation and updates" issue (even though it is not per se about initial installation or updates) because moving a profile involves installation issues.]

Recently I moved my TB profile, for the second time in the past few months. This time I paid closer attention, and noted several things of interest (that may touch on some questions that remain undiagnosed in this forum):

  1. TB took longer to start up, as it could find none of the folders cached in folderCache.json, so rebuilt the cache from the new profile location before starting. (I only learned about this from the next effect.)
  2. The "Move to" "Recent" folders list was empty; this cached list only gets rebuilt from use (that is, from moving messages manually (not via filter) to destination folders). This effect led me to folderCache.json- and also may suggest why the OP in that question could not get resolution of his problem.
  3. The newly cached folderCache.json was 528 KB, compared to 365 KB at the old location -- and that, in turn, was 170 KB larger than the 195 KB size of folderCache.json at the original location. So each time the cache is rebuilt it grows perhaps 150~200 KB (size depending on the many-times-repeated path length).

What causes the file growth? Because each time it is rebuilt, TB checks through all of the cached folder paths, apparently guided by the mailboxes listed in folderTree.json (see image below). [I think TB just checks each path to see whether it is compatible with the current profile location. If yes, the path is cached for runtime; if no, the path is repopulated from the current profile location (which takes most of the startup time).] But TB never deletes the no-longer-valid paths; it just appends to what was already in the file, so that the list of cached folder paths just grows (thereby increasing TB's startup time, every time). The best way to get rid of the old stuff is just to delete folderCache.json and let it rebuild on the next startup, to reduce the time needed for subsequent starts.

Finally, my questions: In addition to folderCache.json (different timestamp in each profile, of course), there are four files which are the same in all profiles: folderCache-x.json, x={1,2,3,4} (see screenshot). These are apparently from actions prior to the profile relocations, as they are simply copied from one profile to the next, unrelated to changes in folderCache.json. Can someone tell me:

  1. What actions cause the creation of folderCache-x.json files?
  2. Why folderCache.json merely appends new folder paths without deleting the old ones?
  3. Why folder paths are specified explicitly (fully qualified) rather than relative to the profile path?

Thanks for any pointers.

[Note: I characterized this question as an "Installation and updates" issue (even though it is not ''per se'' about initial installation or updates) because moving a profile involves installation issues.] Recently I moved my TB profile, for the second time in the past few months. This time I paid closer attention, and noted several things of interest (that may touch on some questions that remain undiagnosed in this forum): # TB took longer to start up, as it could find none of the folders cached in folderCache.json, so rebuilt the cache from the new profile location before starting. (I only learned about this from the next effect.) # The "Move to" "Recent" folders list was empty; this cached list only gets rebuilt from use (that is, from moving messages manually (not via filter) to destination folders). This effect led me to [https://support.mozilla.org/en-US/questions/1378700 folderCache.json]- and also may suggest why the OP in that question could not get resolution of his problem. # The newly cached folderCache.json was 528 KB, compared to 365 KB at the old location -- and that, in turn, was 170 KB larger than the 195 KB size of folderCache.json at the original location. So each time the cache is rebuilt it grows perhaps 150~200 KB (size depending on the many-times-repeated path length). What causes the file growth? Because each time it is rebuilt, TB checks through all of the cached folder paths, apparently guided by the mailboxes listed in folderTree.json (see image below). [I ''think'' TB just checks each path to see whether it is compatible with the current profile location. If yes, the path is cached for runtime; if no, the path is repopulated from the current profile location (which takes most of the startup time).] But ''TB never deletes the no-longer-valid paths''; it just appends to what was already in the file, so that '''''the list of cached folder paths just grows''''' (thereby increasing TB's startup time, every time). The best way to get rid of the old stuff is just to delete folderCache.json and let it rebuild on the next startup, to reduce the time needed for subsequent starts. Finally, my questions: In addition to folderCache.json (different timestamp in each profile, of course), there are four files which are the same in all profiles: folderCache-''x''.json, ''x''={1,2,3,4} (see screenshot). These are apparently from actions prior to the profile relocations, as they are simply copied from one profile to the next, unrelated to changes in folderCache.json. Can someone tell me: # What actions cause the creation of folderCache-''x''.json files? # Why folderCache.json merely appends new folder paths without deleting the old ones? # Why folder paths are specified explicitly (fully qualified) rather than relative to the profile path? Thanks for any pointers.
მიმაგრებული ეკრანის სურათები

ჩასწორების თარიღი: , ავტორი: John Kaufmann

გადაწყვეტა შერჩეულია

1. Thunderbird creates numbered version when access is not available, so anything that causes contention. Most often antivirus file scanners. But it can, at times, be Thunderbird itself as it is not a robust in its threading as it should be. They can be deleted, the software never looks at them. 2. I generally recommend deleting it. I can not answer why it appends. Personally I think it is a bug and should be filed as such https://bugzilla.mozilla.org

If you do file a bug, please link to it here as I would like to follow it. 3. I actually think there is a bug already for that as it is a known cause of issues on dual boot systems, but I can not find it at the moment.

პასუხის ნახვა სრულად 👍 0

ყველა პასუხი (2)

შერჩეული გადაწყვეტა

1. Thunderbird creates numbered version when access is not available, so anything that causes contention. Most often antivirus file scanners. But it can, at times, be Thunderbird itself as it is not a robust in its threading as it should be. They can be deleted, the software never looks at them. 2. I generally recommend deleting it. I can not answer why it appends. Personally I think it is a bug and should be filed as such https://bugzilla.mozilla.org

If you do file a bug, please link to it here as I would like to follow it. 3. I actually think there is a bug already for that as it is a known cause of issues on dual boot systems, but I can not find it at the moment.

გამოსადეგია?

1. I will delete all folderCache-x.json files. Thanks for the explanation.

2. Later today, I will file a bug about the rebuild behavior of folderCache.json, and refer it to this discussion. I appreciate that suggestion.

3. I will look for that bug about folder paths being fully qualified rather than relative to the profile (and yes, you are correct in your guess that dual-boot issues prompted this inquiry).

Thanks for wrapping this up so quickly and succinctly.

გამოსადეგია?

დასვით კითხვა

უნდა შეხვიდეთ ანგარიშზე პასუხის დასაწერად. გთხოვთ, დასვათ ახალი შეკითხვა, თუ ჯერ არ გაქვთ ანგარიში.