When creating a new profile (on first launch or with "firefox -P"),
Firefox fails to create the "~/.mozilla/firefox/<profile>/storage/permanent" folder. I have observed this behavior with Firefox 85, 86, and 78esr, although more versions are likely affected. This behavior was observed on a machine running -current. The two most obvious symptoms of this failure are the browser's Web Developer tools showing no page source in the Inspector tab (non-esr) and various error messages in the Browser Console relating to IndexedDB. This failure is caused by unveil. When creating a profile, Firefox begins checking each directory in the path "/home/<user>/.mozilla/firefox/<profile>/storage/permanent" for existence (i.e., "/home" then "/home/<user>" then ...). If any directory in this chain does not exist, Firefox gives up on creating the "permanent" folder. This is easily observed in a ktrace. (I did "ktrace -id firefox -P". Search for "permanent".) Since Firefox has no access to "/home" (despite having access to the profile folder), the "permanent" folder is never created. The easiest way to fix this issue, for profiles both new and old, is to manually create the "permanent" folder after Firefox creates the profile for you. Once this folder exists, Firefox seems to have no more issues. It only has trouble creating this folder initially. There are two other possible "fixes" involving unveil which I include for completeness only. Both of these changes can be reverted after running Firefox once with them applied. The first is to disable "unveil.main". The second is to add: /home r ~ r to "unveil.main". This allows the directory existence checks to pass, and Firefox happily creates the "permanent" folder. |
On Thu, Mar 04, 2021 at 07:30:18AM +0000, RJ Johnson wrote:
> When creating a new profile (on first launch or with "firefox -P"), > Firefox fails to create the > "~/.mozilla/firefox/<profile>/storage/permanent" folder. > > I have observed this behavior with Firefox 85, 86, and 78esr, although > more versions are likely affected. This behavior was observed on a > machine running -current. > > The two most obvious symptoms of this failure are the browser's Web > Developer tools showing no page source in the Inspector tab (non-esr) > and various error messages in the Browser Console relating to IndexedDB. > > This failure is caused by unveil. When creating a profile, Firefox > begins checking each directory in the path > "/home/<user>/.mozilla/firefox/<profile>/storage/permanent" for > existence (i.e., "/home" then "/home/<user>" then ...). If any directory > in this chain does not exist, Firefox gives up on creating the > "permanent" folder. This is easily observed in a ktrace. (I did > "ktrace -id firefox -P". Search for "permanent".) Since Firefox has no > access to "/home" (despite having access to the profile folder), the > "permanent" folder is never created. > > The easiest way to fix this issue, for profiles both new and old, is to > manually create the "permanent" folder after Firefox creates the profile > for you. Once this folder exists, Firefox seems to have no more issues. > It only has trouble creating this folder initially. That's a good finding. Someone (tm) (not me) with enough motivation should look into fixing that in the code. Looking for 'PERMANENT' on searchfox.org, the corresponding codepath seems to be around https://searchfox.org/mozilla-central/source/dom/quota/ActorsParent.cpp#3548 im not 100% sure at all, but *maybe* the method creating the dir hierarchy is https://searchfox.org/mozilla-central/source/xpcom/io/nsLocalFileUnix.cpp#360 . Or somewhere else. That's a 'nice' maze.. Good luck ! Landry |
In reply to this post by RJ Johnson
> im not 100% sure at all, but *maybe* the method creating the dir
> hierarchy is > https://searchfox.org/mozilla-central/source/xpcom/io/nsLocalFileUnix.cpp#360 . You were right. I've created a bug on Bugzilla at https://bugzilla.mozilla.org/show_bug.cgi?id=1697721 about this issue. If you are interested, a patch-compatible version is below. Index: xpcom/io/nsLocalFileUnix.cpp --- xpcom/io/nsLocalFileUnix.cpp.orig +++ xpcom/io/nsLocalFileUnix.cpp @@ -365,6 +365,8 @@ nsLocalFile::CreateAllAncestors(uint32_t aPermissions) // <jband> I promise to play nice char* buffer = mPath.BeginWriting(); char* slashp = buffer; + int mkdir_result = 0; + int mkdir_errno; #ifdef DEBUG_NSIFILE fprintf(stderr, "nsIFile: before: %s\n", buffer); @@ -393,9 +395,9 @@ nsLocalFile::CreateAllAncestors(uint32_t aPermissions) #ifdef DEBUG_NSIFILE fprintf(stderr, "nsIFile: mkdir(\"%s\")\n", buffer); #endif - int mkdir_result = mkdir(buffer, aPermissions); - int mkdir_errno = errno; + mkdir_result = mkdir(buffer, aPermissions); if (mkdir_result == -1) { + mkdir_errno = errno; /* * Always set |errno| to EEXIST if the dir already exists * (we have to do this here since the errno value is not consistent @@ -408,23 +410,22 @@ nsLocalFile::CreateAllAncestors(uint32_t aPermissions) } } - /* Put the / back before we (maybe) return */ + /* Put the / back */ *slashp = '/'; - - /* - * We could get EEXIST for an existing file -- not directory -- - * with the name of one of our ancestors, but that's OK: we'll get - * ENOTDIR when we try to make the next component in the path, - * either here on back in Create, and error out appropriately. - */ - if (mkdir_result == -1 && mkdir_errno != EEXIST) { - return nsresultForErrno(mkdir_errno); - } } #ifdef DEBUG_NSIFILE fprintf(stderr, "nsIFile: after: %s\n", buffer); #endif + + /* + * We could get EEXIST for an existing file -- not directory -- + * but that's OK: we'll get ENOTDIR when we try to make the final + * component of the path back in Create and error out appropriately. + */ + if (mkdir_result == -1 && mkdir_errno != EEXIST) { + return NS_ERROR_FAILURE; + } return NS_OK; } |
On Thu, Mar 11, 2021 at 09:03:13AM +0000, RJ Johnson wrote:
> > im not 100% sure at all, but *maybe* the method creating the dir > > hierarchy is > > https://searchfox.org/mozilla-central/source/xpcom/io/nsLocalFileUnix.cpp#360 . > > You were right. I've created a bug on Bugzilla at > https://bugzilla.mozilla.org/show_bug.cgi?id=1697721 about this issue. > > If you are interested, a patch-compatible version is below. well, thanks for that ! I'll make sure this is properly tracked. note that in the upcoming 87.0, there's another issue with unveil and downloads, being tracked in https://bugzilla.mozilla.org/show_bug.cgi?id=1696958 - i dunno if those issues can be more or less linked with each other.. Landry |
Free forum by Nabble | Edit this page |