Avatar for Username

Search Support

Avoid support scams. We will never ask you to call or text a phone number or share personal information. Please report suspicious activity using the “Report Abuse” option.

Learn More

This thread was archived. Please ask a new question if you need help.

Extensions can't access sync storage when using a profile on a RAMdisk

  • No replies
  • 1 has this problem
  • 1 view
pg_78
pg_78
more options

Some time ago I moved my Firefox profile to a RAMdisk using IMDisk Virtual Disk Driver on Windows 10. Nearly everything worked fine, apart from certain extensions (e.g. Google Container), which either didn't work at all, or wouldn't allow options to be saved.

The common factor seemed to be that these extensions needed "sync storage" and weren't able to access it when the profile was on the RAMdisk, even though it had worked fine when it was on the C drive. (Note, it made no difference whether I had Firefox Sync configured to sync addon data or not - the relevant thing is that the extensions were using "sync storage" as their way of storing information locally.)

The workaround I eventually found was to move storage.sqlite and storage-sync-v2.sqlite back to my C drive, and create symlinks in my profile folder on the RAMDisk pointing back to them.

This isn't too bad: the size of the data is small and writes are fairly infrequent, and I can certainly live with the workaround.

However, it still seems like a bug, so I'm posting this (1) in case it's useful to anyone else who finds it, (2) to ask whether I should raise it on Bugzilla?

Some questions you might ask:

  • Was this specific profile corrupt?

That wasn't the problem: I could replicate the issue by creating a brand new clean profile on the RAMdisk.

  • Is this a problem with Firefox SQLite databases on the RAMdisk generally?

No: places.sqlite, cookies.sqlite and all the rest of them can be written and read just fine. I wonder if the sync storage code is using different Windows APIs to access files than the rest of Firefox is?

  • Is this a problem with having the profile somewhere other than the C drive, rather than being RAMdisk-specific?

No: you can even put the profile on a USB flash drive and it works fine (well, slowly, but without the problem I described).

  • What if you create a directory junction so that the profile appears to be on the C drive, when it's on the RAMdisk?

That didn't work either - only moving the files physically back to the C drive fixed it.

Some time ago I moved my Firefox profile to a RAMdisk using IMDisk Virtual Disk Driver on Windows 10. Nearly everything worked fine, apart from certain extensions (e.g. Google Container), which either didn't work at all, or wouldn't allow options to be saved. The common factor seemed to be that these extensions needed "sync storage" and weren't able to access it when the profile was on the RAMdisk, even though it had worked fine when it was on the C drive. (Note, it made no difference whether I had Firefox Sync configured to sync addon data or not - the relevant thing is that the extensions were using "sync storage" as their way of storing information locally.) The workaround I eventually found was to move '''storage.sqlite''' and '''storage-sync-v2.sqlite''' back to my C drive, and create symlinks in my profile folder on the RAMDisk pointing back to them. This isn't too bad: the size of the data is small and writes are fairly infrequent, and I can certainly live with the workaround. However, it still seems like a bug, so I'm posting this (1) in case it's useful to anyone else who finds it, (2) to ask whether I should raise it on Bugzilla? Some questions you might ask: * Was this specific profile corrupt? That wasn't the problem: I could replicate the issue by creating a brand new clean profile on the RAMdisk. * Is this a problem with Firefox SQLite databases on the RAMdisk generally? No: places.sqlite, cookies.sqlite and all the rest of them can be written and read just fine. I wonder if the sync storage code is using different Windows APIs to access files than the rest of Firefox is? * Is this a problem with having the profile somewhere other than the C drive, rather than being RAMdisk-specific? No: you can even put the profile on a USB flash drive and it works fine (well, slowly, but without the problem I described). * What if you create a directory junction so that the profile appears to be on the C drive, when it's on the RAMdisk? That didn't work either - only moving the files physically back to the C drive fixed it.