New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MEMFS: issue running FirefoxPortable #103

Closed
JohnOberschelp opened this Issue Sep 6, 2017 · 12 comments

Comments

2 participants
@JohnOberschelp
Contributor

JohnOberschelp commented Sep 6, 2017

FirefoxPortable runs under memfs, but with a hiccup.

I have winfsp installed from winfsp-1.1.17164.msi.

First, I run a batch file that does...

cd C:\Program Files (x86)\WinFsp\bin
memfs-x64 -u \memfs64\share2 -i -s 500111000 -m *
pause

To recreate...

  • Open a Z: window.
  • Copy in portable firefox, "FirefoxPortable_55.0.3_English.paf.exe".
  • Double-click it. It installs!
  • Double-click the new "FirefoxPortable" folder.
  • Double-click the "FirefoxPortable.exe" file.

I get an "ERROR: firefox.exe could not be found" dialog box.
But then...

  • Double-click the "App" folder.
  • Double-click the "Firefox64" folder.
  • Double-click the "firefox.exe".

... and it works great. I can browse, watch videos, download files, etc.

Running FirefoxPortable on NTFS works as expected:

  • Copy portable firefox, "FirefoxPortable_55.0.3_English.paf.exe", to a new folder.
  • Double-click it. Get an "Open File - Security Warning" dialog. Select "Run". It installs.
  • Double-click the new "FirefoxPortable" folder.
  • Double-click the "FirefoxPortable.exe" file.

Runs fine.

This was performed on a Windows 10 Pro laptop, 64-bit, with 8GB RAM, no VM.
I am happy to run any tests suggested, but, as neither you nor I wrote this app, this might be a good problem to ignore? I ran it again with full memfs debugging, and I got an 8 MB log with no weird status codes.

@billziss-gh

This comment has been minimized.

Owner

billziss-gh commented Sep 6, 2017

My first thought was that FirefoxPortable requires a case-insensitive file system, but you are running MEMFS with the -i switch. So this cannot be it.

Does this problem also happen if you run MEMFS without the -u switch?

@billziss-gh

This comment has been minimized.

Owner

billziss-gh commented Sep 6, 2017

It just occurred to me that this may have to do with drive namespaces.

When you run MEMFS from the command line you run it under the credentials of the account that created the command prompt. Drives created under a user account are entered into a drive namespace that is only accessible to that user account. Furthermore if a user is elevated to Administrator, that user gets a drive namespace that is different from the one the user sees when they are not elevated!

The full details are described in the following link: https://msdn.microsoft.com/en-us/library/windows/desktop/aa363908(v=vs.85).aspx

I am wondering if what happened is the following (or similar) scenario:

  • You ran MEMFS under an account that was not elevated. MEMFS created a drive in your account's namespace that could be seen by Explorer, but not by other accounts including yours when elevated.

  • FirefoxPortable requires admin privileges in order to run (please note -- I do not actually know if this is the case, but installers often do). After being elevated FirefoxPortable no longer is able to access the drive (because the elevated account sees a different drive namespace).

  • FirefoxPortable complains and fails.

Try launching the drive from the Explorer using the "Map network drive" functionality (or net use) and see if the problem persists. Such drives are created under the SYSTEM account, which places drives in the global drive namespace (accessible to all accounts).

@JohnOberschelp

This comment has been minimized.

Contributor

JohnOberschelp commented Sep 8, 2017

I apologize for my slow response; I am traveling about with my family.

Removing -u \memfs64\share2 had no effect.

Both Map network drive of \\memfs64\share to Z:
and net use Z: \\memfs64\share
map fine, but both will not allow me to copy FirefoxPortable to Z: with a "Copy Item - There is not enough space" dialog; I suspect this is because these mappings are using the default MaxFileSize of 16MB as I received this error before I upped MaxFileSize on my command line, like:
memfs-x64 -u \memfs64\share2 -i -s 500111000 -m *

Assuming this is true, how do I alter the MaxFileSize? I did not see a way to pass parameters with net use and I did not see anything obvious under [HKLM\SYSTEM\CurrentControlSet\Services\WinFsp]

@billziss-gh

This comment has been minimized.

Owner

billziss-gh commented Sep 8, 2017

I apologize for my slow response; I am traveling about with my family.

No problem, of course!

Assuming this is true, how do I alter the MaxFileSize? I did not see a way to pass parameters with net use and I did not see anything obvious under [HKLM\SYSTEM\CurrentControlSet\Services\WinFsp]

You can alter the command line passed to MEMFS under this registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\WinFsp\Services\memfs64

[These values are stored in the 32-bit portion of the HKEY_LOCAL_MACHINE\SOFTWARE\WinFsp\Services registry key.]

@billziss-gh

This comment has been minimized.

Owner

billziss-gh commented Sep 20, 2017

@JohnOberschelp just wondering if you have any update on this?

@JohnOberschelp

This comment has been minimized.

Contributor

JohnOberschelp commented Sep 22, 2017

Back from vacation. :-) :-( :-)

Different ways of establishing memfs seem unrelated to the problem.

I updated HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\WinFsp\Services\memfs64
CommandLine with -s 500111000
and now...
Map network drive of \\memfs64\share to Z:
net use Z: \\memfs64\share
... and...
memfs-x64 -u \memfs64\share2 -i -s 500111000 -m *
... both from a bat file and typed on the command line, all produce the same result:
Installing FirefoxPortable_55.0.3_English.paf.exe works perfectly.
Running it from Z:\ForefoxPortable\FirefoxPortable.exe fails with "ERROR: firefox.exe could not be found".
Running it from Z:\ForefoxPortable\App\Firefox64\firefox.exe works perfectly.

But while looking at this, I found something that sure seems related.

When I install on C:, I have...
90 items in the folder C:\ForefoxPortable\App\Firefox64
91 items in the folder C:\ForefoxPortable\App\Firefox

But when I install under memfs, on Z:, I have...
90 items in the folder Z:\ForefoxPortable\App\Firefox64
0 items in the folder Z:\ForefoxPortable\App\Firefox

So I opened a Command Prompt and...

C:\Users\John>cd Z:\FirefoxPortable\App\Firefox

C:\Users\John>z:

Z:\FirefoxPortable\App\Firefox>dir
Volume in drive Z is MEMFS
Volume Serial Number is 0FD5-F1D0

Directory of Z:\FirefoxPortable\App\Firefox

09/22/2017 02:37 PM

.
09/22/2017 02:14 PM ..
0 File(s) 0 bytes
2 Dir(s) 359,079,956,480 bytes free

Z:\FirefoxPortable\App\Firefox>cd fonts

Z:\FirefoxPortable\App\Firefox\fonts>dir
Volume in drive Z is MEMFS
Volume Serial Number is 0FD5-F1D0

Directory of Z:\FirefoxPortable\App\Firefox\fonts

09/22/2017 02:14 PM

.
09/22/2017 02:37 PM ..
08/24/2017 07:40 AM 1,227,260 EmojiOneMozilla.ttf
1 File(s) 1,227,260 bytes
2 Dir(s) 359,079,956,480 bytes free

Z:\FirefoxPortable\App\Firefox\fonts>

... so the folder "fonts" is and isn't there.
I also copied a "helloworld.exe" into Z:\FirefoxPortable\App\Firefox and tried to rename it "firefox.exe", and Windows complained that firefox.exe already existed.
... so the file "firefox.exe" is and isn't there.

@billziss-gh

This comment has been minimized.

Owner

billziss-gh commented Sep 22, 2017

Back from vacation. :-) :-( :-)

Welcome back :)

But while looking at this, I found something that sure seems related.

Ok, all this does sound very weird. I will try to replicate your result and better understand this issue.

@billziss-gh

This comment has been minimized.

Owner

billziss-gh commented Sep 22, 2017

I am able to reproduce. Investigating.

@billziss-gh

This comment has been minimized.

Owner

billziss-gh commented Sep 25, 2017

I believe I have identified the issue.

The good news: it is not a core WinFsp issue. It is rather an issue with MEMFS and how it maps FileName's to FileNode's in a single namespace.

The bad news: I have no idea how a bug as obvious as this escaped into the wild. In any case I am working on a fix.

billziss-gh added a commit that referenced this issue Sep 25, 2017

@billziss-gh

This comment has been minimized.

Owner

billziss-gh commented Sep 25, 2017

I believe commit 5194536 fixes this issue. It passes all AppVeyor tests and my own tests against FirefoxPortable.

Are you able to rebuild MEMFS with this patch and test it? If yes, I would appreciate a report.

@billziss-gh billziss-gh changed the title from Interesting issue running FirefoxPortable under memfs to MEMFS: issue running FirefoxPortable Sep 25, 2017

@JohnOberschelp

This comment has been minimized.

Contributor

JohnOberschelp commented Sep 26, 2017

FirefoxPortable starts correctly after install using my MEMFS sln after that commit.
If bugs can be cute, that was a cute one.

@billziss-gh

This comment has been minimized.

Owner

billziss-gh commented Sep 26, 2017

Fantastic :) Closing this as resolved then.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment