Figure out what storage can be moved to 'Local' path on Windows and what can remain in 'Roaming'
Categories
(Core :: Storage: Quota Manager, enhancement, P3)
Tracking
()
People
(Reporter: rainer.meier, Unassigned)
References
Details
(Whiteboard: dom-lws-bugdash-triage)
|
||
Comment 1•8 years ago
|
||
|
||
Comment 2•8 years ago
|
||
|
||
Comment 3•8 years ago
|
||
|
||
Comment 4•8 years ago
|
||
|
|
||
Updated•8 years ago
|
|
|
||
Comment 5•8 years ago
|
||
|
Reporter | |
Comment 7•8 years ago
|
||
|
|
||
Comment 8•8 years ago
|
||
|
||
Comment 9•7 years ago
|
||
|
||
Updated•7 years ago
|
|
||
Comment 12•6 years ago
|
||
:mconca, needinfo-ing you for product/feature processing of this request.
As I understand the problem, there are 2 use-cases that would like the storage moved to other places:
- Simplifying backups. Bug 1339696 primarily seems to be requesting a workaround for a backup program, but in general I understand that historically backup programs frequently do not have a fun time dealing with SQLite databases unless they have low-level file-system access so that they only need to record page-level deltas to databases.
- For actually roaming profiles, there can be a lot of storage usage in the profile.
I understand the concern on this bug to be primarily about the latter, which I think is likely considered a (Windows) enterprise-style feature.
I understand the current scenario to be that we do store HTTP cache data as local, non-roamed storage. However, our content-visible storage (cookies, LocalStorage, IndexedDB, Cache API, ServiceWorkers, etc.) is stored in roaming storage.
From a product perspective, I think the key questions are how/whether to suppose this use-case. The primary engineering concerns are that this is about content-visible storage, not a best-effort cache. This means that if using a page that uses storage APIs to store data, like to store a draft of an email message locally, then that user data won't roam between machines. This is most similar to separate Firefox installations synchronized via sync. This also has privacy implications as all of our mechanisms for clearing/forgetting site data are strictly local. (And indeed, synchronizing a "delete the data for example.com" is potentially contrary to existing privacy goals, as a tombstone to explicitly clear a site is a record of that site.)
It's possible that there's another alternative to help improve the use-case for this scenario beyond moving storage entirely from roaming to non-roaming. Assuming the roaming profile mechanism doesn't copy all of the data all of the time, but only (potentially naive) deltas, we might be able to re-architect so that Firefox profiles cause smaller deltas to be observed by the roaming mechanism.
It's also possible that we could tune and/or help tune eviction heuristics for the QuotaManager-managed storage so that there is less data persistently kept around in general. Currently QuotaManager limits site storage based on free disk space by default, evicting data only when we QM-managed storage crosses a free-space related threshold. Other heuristics could trigger eviction more aggressively.
|
||
Comment 13•6 years ago
|
||
Copying a bit from https://bugzilla.mozilla.org/show_bug.cgi?id=1554460: https://snag.gy/7Ri52b.jpg
:mconca On my local machine, personal install of Firefox it appears that the roaming data is predominantly cache and temp files, at least according to the file/folder names. Digging a bit in to the storage folder (see screenshot above), I see default and temporary. Right off the bat temporary should not be roaming. Glancing through default, it appears to be a folder for each site, with a large cache folder inside each. cache files should all be in %LOCALAPPDATA%, as they don't need to roam across a network. I also see extensions and backups in there, which are similarly not user-config, and thus not appropriate for %APPDATA%, as well as Crash Reports, which are definitely not something that should roam/be backed up.
After spending a few minutes digging through the profile folder, everything I see that is of significant size is not appropriate for roaming storage. I suspect somewhere in there are config files that are appropriate for roaming (like bookmarks, preferences, etc.) but those files are likely measured in kilobytes.
If you are going to be storing browser local storage in roaming, then I think there needs to be a much more aggressive eviction policy. Just because computer A has 750GB of free space doesn't mean that computer B that it is roaming to has 750GB of free space, not to mention that roaming GBs of data is incredibly destructive to a network or backup system, even if it is doing delta syncs.
My recommendation would be to either move everything to %LOCALAPPDATA% if splitting up the data appropriately is too hard or not possible, or extracting out everything except small config type data like bookmarks and preferences (not browsing history, cookies, local storage, caches, temp files, etc.) into %LOCALAPPDATA%.
While the idea of roaming/backing up all of the user's various transient data sounds cool, I don't think it is reasonable for most of the world (data caps, limited bandwidth, etc.). I think the question that should be asked is, "Would we be willing to provide cloud storage for this data and/or would users be willing to pay for cloud storage for this data?" If not, then it probably doesn't belong in the roaming profile and instead should be stored on local disk only. As a user, I can assert with confidence that I would not be willing to pay for cloud storage of Browser Local Storage, unbounded history, caches, etc. I would be willing to pay for cloud storage of bookmarks, browser settings, current tabs (and maybe very recently closed tabs) extension manifests (but not extension data, I can re-download that).
|
|
||
Comment 14•6 years ago
|
||
(In reply to Micah Zoltu from comment #13)
:mconca On my local machine, personal install of Firefox it appears that the roaming data is predominantly cache and temp files, at least according to the file/folder names. Digging a bit in to the
storagefolder (see screenshot above), I seedefaultandtemporary. Right off the battemporaryshould not be roaming. Glancing throughdefault, it appears to be a folder for each site, with a largecachefolder inside each.cachefiles should all be in%LOCALAPPDATA%, as they don't need to roam across a network. I also see extensions and backups in there, which are similarly not user-config, and thus not appropriate for%APPDATA%, as well asCrash Reports, which are definitely not something that should roam/be backed up.
To clarify:
- "storage/temporary/" is only used by the asm.js cache and that's going away. (Previously we also allowed IndexedDB to specify explicit storage levels, but that functionality has been fully deprecated.)
- storage/default/ORIGIN/cache/ is the Cache API (https://w3c.github.io/ServiceWorker/#cache-objects) that is exposed to content, as well as the underlying storage mechanism for ServiceWorkers. Per spec and practical considerations, it needs to be coherent with IndexedDB state and all data hung off of ServiceWorker registrations. Ideally it's also consistent with LocalStorage.
- Although I think the point above about extensions is about the XPIs themselves, note that extension origins stored under storage/default do include extension configuration data (especially since bug 1474562 but even before that they could use normal storage APIs). That said, WebExtensions does have a concept of local/synchronized data and Firefox I believe is in the process of implementing support for that (or recently implemented it?)
|
||
Comment 15•6 years ago
|
||
(In reply to Andrew Sutherland [:asuth] (he/him) from comment #12)
From a product perspective, I think the key questions are how/whether to suppose this use-case. The primary engineering concerns are that this is about content-visible storage, not a best-effort cache. This means that if using a page that uses storage APIs to store data, like to store a draft of an email message locally, then that user data won't roam between machines. This is most similar to separate Firefox installations synchronized via sync. This also has privacy implications as all of our mechanisms for clearing/forgetting site data are strictly local. (And indeed, synchronizing a "delete the data for example.com" is potentially contrary to existing privacy goals, as a tombstone to explicitly clear a site is a record of that site.)
I think there are multiple reasons to pursue the idea of storing most, perhaps all, content-visible data locally in the non-roamed storage area.
- Privacy - As mentioned, having local site data automatically migrated between machines by the OS probably isn't ideal from a data privacy point-of-view, particularly in the "delete all of my data" use case. Limiting content-visible data to the local machine only, where the browser can confidently manage/remove that data, seems more in-line with Mozilla's mission to protect user data.
- Fx Accounts - Mozilla is encouraging more and more users to create a Firefox account, which allows the browser to synchronize data via cloud storage and is more in line with what Chrome does. Already, having an account synchronizes bookmarks and extension data (for those extensions that use the storage.sync API), and it is easy to imagine the service being able to sync other types of data. It also forces the privacy question - if Firefox isn't comfortable sync'ing certain data via Accounts, it probably shouldn't be occuring via roaming, either.
- Platform Consistency - Only Windows users are seeing the "benefit" of a roamed profile. While that represents the majority of Firefox users, particularly for enterprise, it creates an inconsistent experience across operating systems. Using Fx Accounts as the synchronization mechanism, however, benefits all platform, regardless of OS, and is inclusive of mobile.
- Performance - While this was the original reason this bug was filed, I actually think it is the least important from a strategic point-of-view. Protecting user privacy via Fx Accounts is the leading motivation, with platform consistency and performance benefits making the case for doing this even stronger.
It's possible that there's another alternative to help improve the use-case for this scenario beyond moving storage entirely from roaming to non-roaming. Assuming the roaming profile mechanism doesn't copy all of the data all of the time, but only (potentially naive) deltas, we might be able to re-architect so that Firefox profiles cause smaller deltas to be observed by the roaming mechanism.
Sounds challenging, and doesn't address any of the above-mentioned issues except performance. ROI is low.
It's also possible that we could tune and/or help tune eviction heuristics for the QuotaManager-managed storage so that there is less data persistently kept around in general. Currently QuotaManager limits site storage based on free disk space by default, evicting data only when we QM-managed storage crosses a free-space related threshold. Other heuristics could trigger eviction more aggressively.
Also only addresses performance, and as pointed out in comment 13, different computers will have different amounts of free disk space.
|
|
||
Comment 16•6 years ago
|
||
Thank you for the detailed and quick feedback!
(In reply to Mike Conca [:mconca] from comment #15)
I think there are multiple reasons to pursue the idea of storing most, perhaps all, content-visible data locally in the non-roamed storage area.
I'm not sure I parsed this right. I understand there to be a few levels here you might mean:
- A. Each computer has its own non-roamed profile. Any information sharing happens via Fx Account.
- B. The profile roams, but the roaming data is only history / passwords, just like Fx Account would sync. Cookies and sessionstore data doesn't roam, so ex: gmail logins are logically distinct as far as google is concerned.
- C. Option B plus cookies and sessionstore roam so that the user sees their session do a best-effort migration. This might cause some weirdness for sites where ServiceWorkers are involved and their behavior differs from hitting the URL without the seviceworker installed.
- Privacy - As mentioned, having local site data automatically migrated between machines by the OS probably isn't ideal from a data privacy point-of-view, particularly in the "delete all of my data" use case. Limiting content-visible data to the local machine only, where the browser can confidently manage/remove that data, seems more in-line with Mozilla's mission to protect user data.
To be clear, my concern about user expectations for their data concerns the following situation if we're talking about option B or C above and we make only simple changes to our implementation:
- Users browses engagement-ring.example.com on computer A. This creates a roamed history entry and non-roamed site data stored under storage/default/http+++example.com. Let's assume the site uses IndexedDB to offline products the user looked at.
- User browses engagement-ring.example.com on computer B via history entry, which also creates non-roamed site data.
- Still on computer B, user realizes they don't want that in their history popping up, so they use "forget about this site" to clear both the roamed history entry for engagement-ring.example.com and the non-roamed site data. As far as they can see, they cleared all that data.
- User goes back to computer A. If they go to about:preferences, they see there is still site data for engagement-ring.example.com. And/or if they go back to the site, they can see it clearly has remembered data about the user.
In my mental model of user expectations, I think they would find step 4 surprising.
Having said that, there are ways to make it so that at step 4 when the user starts up firefox on computer A so that:
- The data for engagement-ring.example.com is stored in such a way that there's no data directly in the clear on disk.
- The data is automatically purged in the background.
While that would involve some engineering effort, we are potentially already going to be doing things related to this in our work for SessionStorage and IndexedDB-on-PrivateBrowsing, so it's a direction we can head in if we know that's where we want to go with the product.
(In short, the idea would be that the data in storage/default/ORIGIN would instead be storage/by-uuid/UUID where the mapping from origin-to-uuid happens in a database that is roamed. The data on disk would also be encrypted using information found in the database. So when we startup on computer A, we would no longer have the mapping for engagement-ring.example.com and would discard it.)
|
|
||
Comment 17•6 years ago
|
||
(In reply to Andrew Sutherland [:asuth] (he/him) from comment #16)
Thank you for the detailed and quick feedback!
(In reply to Mike Conca [:mconca] from comment #15)
I think there are multiple reasons to pursue the idea of storing most, perhaps all, content-visible data locally in the non-roamed storage area.
I'm not sure I parsed this right. I understand there to be a few levels here you might mean:
- A. Each computer has its own non-roamed profile. Any information sharing happens via Fx Account.
This is basically where I would like Firefox to head, primarily for all of the odd use-case reasons and exceptions you outlined for options B and C. Option A is simple, straight-forward, privacy-protecting and performant. To be clear, though, I'm not saying this should be our highest priority. I'd just like to see the browser head this direction.
|
||
Comment 18•4 years ago
|
||
I am disappointed to see that the Storage is still being included in Roaming and not Local. I have a user with a slack folder that alone has more than 2gb of storage, and we have a profile quota limit which this user keeps hitting.
My advise to the user will have to be to use chrome, since this was last discussed 3 years ago and Mozilla are clearly not interested in fixing it.
Thanks.
|
|
||
Comment 19•3 years ago
|
||
I am hitting this problem more and more.
Please could you let us know if this is actively being considered?
Alternatively, could you let me know if a way of fixing the profile string, as we can only exclude this (which is what we do for other things like Teams/Signal/Zoom/Skype). So I'd like to exclude c:\users\username\appdata\roaming\mozilla\Firefox\Profiles\fixed-profile-esr\storage
Unfortunately we cannot use a wildcard in place of the profile string, so the only options available are for us to wait for you to fix it, or for you to enable us to fix the string for everybody.
Thanks
John Peachey
Senior Windows Systems Administrator
Department of Computer Science
Oxford University.
|
|
Reporter | |
Comment 20•3 years ago
|
||
I do not have a real solution for this. But if you really want to continue using Firefox in it's current state I might have a workaround for you which might work at least in some cases.
You can use the following power shell script to exclude unwanted profile folders of Firefox and Thunderbird (excludeMozillaFolders.ps1):
# This script is used to exclude Mozilla storage folder from roaming profiles.
# The storage folder can be re-created by Mozilla products like
# Firefox/Thunderbird on startup.
# There is no need for this data to move across machines.
# Some cached data of some extensions and offline page caches are lost on
# roaming but they are considered to be re-creatable.
#
# Since the path is dynamic they can't be excluded via GPO as no wildcards are
# supported. But HKCU\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
# containing a user-specified exclude list (ExcludeProfileDirs) attribute which
# is merged to the GPO-excluded list.
#
# This script can be included as logoff script and applied via GPO to add those
# profile storage folders dynamically on logoff.
#
# Note: Depending on execution policy you might have to run a CMD script and
# execute this powershell script as follows:
# powershell -ExecutionPolicy RemoteSigned -File "%~dp0updateProfileExcludes.ps1"
$profilePaths = (Get-ItemProperty -Path "HKCU:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon").ExcludeProfileDirs.Split(";")
# Remove previous listings of Mozilla (Firefox/Thunderbird) profiles.
$profilePaths = @($profilePaths) -inotmatch "^AppData\\.*\\Profiles\\.*\\.*$"
# Path to Mozilla profiles.
$profileLocationFirefox = $env:APPDATA + "\Mozilla\Firefox\Profiles\*\storage"
$profileLocationTHunderbird = $env:APPDATA + "\Thunderbird\Profiles\*\storage"
# Get a list of profile paths.
Set-Location "$env:USERPROFILE"
# Firefox storage.
$profiles = @()
# Firefox.
$profiles += @(Get-Item -Path "$env:APPDATA\Mozilla\Firefox\Profiles\*\bookmarkbackups" -ErrorAction Ignore)
$profiles += @(Get-Item -Path "$env:APPDATA\Mozilla\Firefox\Profiles\*\crashes" -ErrorAction Ignore)
$profiles += @(Get-Item -Path "$env:APPDATA\Mozilla\Firefox\Profiles\*\datareporting" -ErrorAction Ignore)
$profiles += @(Get-Item -Path "$env:APPDATA\Mozilla\Firefox\Profiles\*\gmp*" -ErrorAction Ignore)
$profiles += @(Get-Item -Path "$env:APPDATA\Mozilla\Firefox\Profiles\*\minidumps" -ErrorAction Ignore)
$profiles += @(Get-Item -Path "$env:APPDATA\Mozilla\Firefox\Profiles\*\sessionstore-backups" -ErrorAction Ignore)
$profiles += @(Get-Item -Path "$env:APPDATA\Mozilla\Firefox\Profiles\*\shader-cache" -ErrorAction Ignore)
$profiles += @(Get-Item -Path "$env:APPDATA\Mozilla\Firefox\Profiles\*\storage" -ErrorAction Ignore)
# Files are not supported, but the following files would not be
# needed tool.
# $profiles += @(Get-Item -Path "$env:APPDATA\Mozilla\Firefox\Profiles\*\favicons.sqlite*")
# $profiles += @(Get-Item -Path "$env:APPDATA\Mozilla\Firefox\Profiles\*\storage-sync-v2.sqlite*")
# $profiles += @(Get-Item -Path "$env:APPDATA\Mozilla\Firefox\Profiles\*\webappsstore.sqlite*")
# Thunderbird.
$profiles += @(Get-Item -Path "$env:APPDATA\Thunderbird\Profiles\*\crashes" -ErrorAction Ignore)
$profiles += @(Get-Item -Path "$env:APPDATA\Thunderbird\Profiles\*\datareporting" -ErrorAction Ignore)
$profiles += @(Get-Item -Path "$env:APPDATA\Thunderbird\Profiles\*\gmp" -ErrorAction Ignore)
$profiles += @(Get-Item -Path "$env:APPDATA\Thunderbird\Profiles\*\ImapMail" -ErrorAction Ignore)
$profiles += @(Get-Item -Path "$env:APPDATA\Thunderbird\Profiles\*\shader-cache" -ErrorAction Ignore)
$profiles += @(Get-Item -Path "$env:APPDATA\Thunderbird\Profiles\*\storage" -ErrorAction Ignore)
# $profilePaths = Get-Item -Path $profileLocationFirefox
$profilePaths += $profiles | ForEach-Object {($_.FullName | Resolve-Path -Relative).TrimStart(".\")}
$excludeProfileDirs = $profilePaths -join ";"
# Write-Host "Exclude: $excludeProfileDirs"
Set-ItemProperty -Path "HKCU:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" -Name "ExcludeProfileDirs" -Value "$excludeProfileDirs"
This script will exclude all "bookmarkbackups", "crashes", "datareporting", "gmp", "minidumps", sessionstore-backups", "shader-cache" and "storage" folders from roaming profiles. Unfortunately you can't exclude volatile plain files like favicons.sqlite or webappsstore.sqlite with this method as you can exclude only complete folders.
The script can be assigned in GPO to the user to run at logof (standard logoff script for users). The script is written so it will first clear all previous folders from the user-specific exclude list to avoid the list to grow indefinitely in case the profile folder is changed (ie. a new profile is created by the user) or the profile folder is renamed. Also this avoids the directories to be added multiple times so the exclude list would grow indefinitely. So the script will also take into account if the user has multiple profiles. As long as they are located in the default Profiles folder.
Note: You should perhaps consider NOT to wipe the local profiles early or during logoff. If the profile remains on the client the excluded folders remain on the client and all data is kept. If the profile is deleted (via expiry, or policy to clean it at logoff or when the user logs on to a different machine) then those folders are sipmply missing and Firefox is re-creating them. This results in losing the store (temporary) data. For exmample for Whatsapp web and presumably for applications like slack you might lose the synchronized history and Firefox needs to sync again with the servers to re-download this data. However this is expected and in my tests not causing any issues rather than a slightly slower page load on first use after profile re-build.
I still hope Mozilla is fixing this in the future and moving such temporary data directly to the %LocalAppData% tree as it is essentially temporary data which can be re-created any time. If the user is always using the same machine (most used use-case I believe) then either using my script or a permanent fix moving the data to %LocalAppData% would still preserve this data unless either manually cleared or moving to another machine.
|
|
||
Comment 21•3 years ago
|
||
Thanks a lot Rainer
I've tested that out and it seems to be doing the job very well.
I hope Mozilla take note of this and someone there cares about fixing this issue, but for anyone else reading this then Rainer has indeed done a fine job of making this problem go away for me.
Thanks again.
John.
|
||
Updated•3 years ago
|
|
|
Reporter | |
Comment 22•3 years ago
|
||
Thank you. This might also give an indication which folders (potentially) can be moved to %LocalAppData% safely.
John has set the needinfo flag for me but I do not see an additional question. So I am clearing it.
|
|
||
Comment 23•3 years ago
|
||
My apologies for the incorrect flag -- I'm a bugzilla newbie and appreciate your help ;)
|
|
Reporter | |
Comment 24•3 years ago
|
||
No worries. Thanks for the feedback and for participating. The more people are showing interest in bug reports the more likely it gets for them to get fixed.
|
||
Comment 25•3 years ago
|
||
Huge space taken up by Firefox in Roaming Profiles (roughly 200 MB) was the reason why we stopped using Firefox on our high school.
|
|
||
Comment 26•3 years ago
|
||
(In reply to Franta Hanzlik from comment #25)
Huge space taken up by Firefox in Roaming Profiles (roughly 200 MB) was the reason why we stopped using Firefox on our high school.
Hi Franta
Rainer's powershell script solution from 11 months ago which we apply at logoff has completely solved our issue. While this is a workaround compared to the amount of effort I have to spend with other problems you put this in place once and that solves your problem. I highly recommend you implement this - feel free to reach out to me if you have any issues in doing so.
All the best, John.
|
||
Comment 27•2 years ago
|
||
Nothing new from my side to help that topic get solved but we had the same problems in a 3000 windows client company with roaming user profiles enabled. Storage folder is too huge, resulting in long log on & off times. Please move the location of it to %localappdata% the sooner the better or give us admins a tool to set it via GPO
|
|
||
Comment 28•2 years ago
|
||
(In reply to s.osdoba from comment #27)
Nothing new from my side to help that topic get solved but we had the same problems in a 3000 windows client company with roaming user profiles enabled. Storage folder is too huge, resulting in long log on & off times. Please move the location of it to %localappdata% the sooner the better or give us admins a tool to set it via GPO
If you look at this comment https://bugzilla.mozilla.org/show_bug.cgi?id=1395705#c20 it has a powershell script that we have been using very successfully to solve the issue. While this is a workaround it has 100% solved my problem. Frustrating as it is that Mozilla haven't fixed it - there is a pretty good solution there...
|
|
||
Comment 29•2 years ago
|
||
(In reply to John Peachey from comment #28)
(In reply to s.osdoba from comment #27)
If you look at this comment https://bugzilla.mozilla.org/show_bug.cgi?id=1395705#c20 it has a powershell script that we have been using very successfully to solve the issue. While this is a workaround it has 100% solved my problem. Frustrating as it is that Mozilla haven't fixed it - there is a pretty good solution there...
I saw it and will try to implement it but i still have the hope that Mozilla will solve it so we dont have to apply workarounds. Yes i still believe in Santa Claus :)
|
|
||
Comment 30•2 years ago
|
||
(In reply to s.osdoba from comment #29)
(In reply to John Peachey from comment #28)
(In reply to s.osdoba from comment #27)
If you look at this comment https://bugzilla.mozilla.org/show_bug.cgi?id=1395705#c20 it has a powershell script that we have been using very successfully to solve the issue. While this is a workaround it has 100% solved my problem. Frustrating as it is that Mozilla haven't fixed it - there is a pretty good solution there...I saw it and will try to implement it but i still have the hope that Mozilla will solve it so we dont have to apply workarounds. Yes i still believe in Santa Claus :)
You mean he's not real?!! :(
To implement is so simple - the script doesn't need any edits. Make sure you apply it as a user policy to run the script on logoff...
Any problems we're all here to help :)
|
||
Comment 31•2 years ago
|
||
Just for the record: favicons.sqlite is tied to places.sqlite (bookmarks, history); if they get out of step, your bookmarks will look ugly.
|
|
||
Comment 33•1 year ago
|
||
FYI, for chrome and edge roaming (https://support.google.com/chrome/a/answer/7349337?hl=en)
A user’s roaming profile contains bookmarks, autofill data, passwords, some browsing history, browser preferences, and installed extensions. It doesn’t contain information about cookies, browsing sessions, cached or downloaded files, local browser instance data, or other transient data.
I'm guessing they decided that data was simply too large for roaming.
|
|
||
Comment 34•1 year ago
|
||
(In reply to Mike Kaply [:mkaply] from comment #33)
FYI, for chrome and edge roaming (https://support.google.com/chrome/a/answer/7349337?hl=en)
A user’s roaming profile contains bookmarks, autofill data, passwords, some browsing history, browser preferences, and installed extensions. It doesn’t contain information about cookies, browsing sessions, cached or downloaded files, local browser instance data, or other transient data.
I'm guessing they decided that data was simply too large for roaming.
We use Edge too but default browser is Firefox. Microsoft had done it the bad way. You need to configure a GPO to get bookmarks redirected to roaming profile folder but a lot of other important data is not redirectable so please dont copy their idea how it should work. I guess their idea is to sync all settings to cloud account.
Firefox should decide to split the data: unnecessary data to local\appdata and important data to roaming\appdata and then combine both locations to THE profile but it should accept and work even if no data is in local\appdata
|
|
||
Updated•4 days ago
|
Description
•