Evolving MockVault

oetyng · February 23, 2019, 2:18pm

This is a good suggestion. I have previously had Avast move executables under my nose when I started debugging. But two things: First of all I’ve never seen it happen with a regular file, just executables. Second this VM doesn’t have it, just Windows Defender (it is a little bit less aggressive with such things), and there’s nothing in quarantine history there.
Could still be something else, but I have no idea what it could be. It is a minimal environment, used only for development so there’s not much running on it.

The files were in AppData/Local/Temp. That’s where they end up.

There is no config file there. And I’ve checked Environment variables in 3 different ways, and I don’t know how to confirm it more. It’s almost the same as when I couldn’t set it to in-memory the first time. But then it worked with using Environment.SetEnvironmentVariable("SAFE_MOCK_IN_MEMORY_STORAGE", "true");
This time I’ve been trying setting it back to “false” and then use Environment.GetEnvironmentVariable("SAFE_MOCK_IN_MEMORY_STORAGE"); to check if it is set. And it is “false”, but it has still used in memory storage.
So, turns out when I pass in the bool variable.ToString(), it was setting it to “False”. Shouldn’t matter at all, but I tried adding .ToLowerInvariant(); as to make it “false”. Just tweaking whatever I see tweakable.
Also, there are 3 overloads, and so I made sure to set them all, i.e.:

Environment.SetEnvironmentVariable("SAFE_MOCK_IN_MEMORY_STORAGE", $"{inMem}".ToLowerInvariant(), EnvironmentVariableTarget.Machine);
Environment.SetEnvironmentVariable("SAFE_MOCK_IN_MEMORY_STORAGE", $"{inMem}".ToLowerInvariant(), EnvironmentVariableTarget.Process);
Environment.SetEnvironmentVariable("SAFE_MOCK_IN_MEMORY_STORAGE", $"{inMem}".ToLowerInvariant(), EnvironmentVariableTarget.User);

Then, controlling the value of them all:

var env_0 = Environment.GetEnvironmentVariable("SAFE_MOCK_IN_MEMORY_STORAGE", EnvironmentVariableTarget.Machine);
var env_1 = Environment.GetEnvironmentVariable("SAFE_MOCK_IN_MEMORY_STORAGE", EnvironmentVariableTarget.Process);
var env_2 = Environment.GetEnvironmentVariable("SAFE_MOCK_IN_MEMORY_STORAGE", EnvironmentVariableTarget.User);

And they are all “false”.

Additionally in cmd prompt, enter SET, and it gives this:
safe_env_vars

And the third and last check is via Control Panel\System and Security\System => Advanced system settings => Environment variables safe_env_vars_2

And it shows the same.

So, this is what led me to think that there is maybe something cached somewhere? Well, I have no other guesses.

I did all of this the other day, made sure to check it one more time now before posting this. Same results.

marcin · February 23, 2019, 2:39pm

Ah, “true” and “false” are just strings, they both indicate that the env vars are set (which is all safe_core checks, it doesn’t care about the value). You have to actually delete the env vars (unset on Unix, no idea about Windows).

Sorry for the confusion, just another reason to deprecate these pesky env vars

oetyng · February 23, 2019, 3:06pm

Aaah… I see. Now it all makes sense.
I could remove Machine and User, but Process was still “false”, so then I had to do Environment.SetEnvironmentVariable("SAFE_MOCK_IN_MEMORY_STORAGE", null, EnvironmentVariableTarget.Process);
i.e. set the value to “null”, and then it worked, MockVault file created!

So, now I can let it run and see if I can find the source of this file disappearing…

Thanks @marcin and don’t worry, there’s always stuff to get confused about and people to get confused about them

rob · February 23, 2019, 10:12pm

Did you see this (I assume you googled the problem)

They suggest some reasons

disk cleanup
antivirus
cc cleaner

rob · February 23, 2019, 10:14pm

If I had a swear jar, it would have been filled so many times over in my career due to things like this

marcin · February 24, 2019, 11:08am

Sorry for adding to the swear jar

I can definitely see how it’s confusing that we use true and false in the config files, but a different scheme for the env vars. I don’t know when I’ll get around to reworking/removing the env vars, but I plan to move the documentation to the new wiki this week – so I’ll at least fix that to make things more clear.

rob · February 24, 2019, 11:50am

Maybe instead of having “true” you could have “Remove_env_var_to_disable”

happybeing · February 24, 2019, 1:31pm

I’m not sure about removing env vars completely - unless we can achieve the same convenience, by for example having apps learn from SAFE Browser whether we’re using ‘dev’ or not (ie settings accessed through the API).

So any desktop or Web app can tell whether the Browser is Dev Browser or not, and also if experimental features are turned on.

You could still give control via an app supplied object if you want to, but that would not be required. If I understand that idea correctly.

oetyng · February 25, 2019, 12:41am

It’s not that.
I don’t have CC Cleaner installed. In fact I barely have anything installed, except for the IDE. There’s no disk cleanup running. The MockVault files (nothing else) disappeared as I started debugging.
There’s no reason for random files in Temp folder to be deleted automatically by the system, since there’s no knowing what and for how long other applications will use what ever they store there.

The most likely IMO would be antivirus moving a file to quarantine, but I’m running a very “gentle” AV which hasn’t made itself known in any way (with other machines with more aggressive AV, I’ve had problems, since it interferes in all sorts of ways with the IDE and picks up executables and places them in quarantine), and there is nothing in quarantine history.

Other possibilities would maybe be that the IDE is buggy, since I’m running a preview. But I’m just guessing.

rob · February 25, 2019, 1:19am

Now usually previews/trials have limitations and could this be one of them? I am clutching at straws but it seems you are at that stage now as well

marcin · February 25, 2019, 9:44am

I’m a bit confused, what env vars are you referring to? The ones I want to get rid of are these: https://docs.rs/safe_core/0.32.0/safe_core/. This topic and @oetyng’s experiences have convinced me that they need to be deprecated.

Environment variables aren’t really a good way to get information about the Browser, anyway. Any app can change or unset them and they’re not guaranteed to be set in the first place.

marcin · February 25, 2019, 9:53am

@oetyng Have you run any Client Libs tests? I want to confirm that Client Libs isn’t responsible for deleting the file. The only place in the code where we remove the MockVault file is in a test, here. However, this test (serialisation_write_data) is ignored by default, so you would have to explicitly be running it, or you would have to run scripts/test-binary, so I don’t think this is the issue.

marcin · February 25, 2019, 10:18am

I moved the environment variable documentation to the wiki. I hope it is more clear this time around, let me know if not!

happybeing · February 25, 2019, 11:31am

Apologies @marcin, I wasn’t paying attention. As you were! [in the military idiom sense]

oetyng · February 27, 2019, 1:10pm

Sorry, a bit late: I did not run any Client Libs tests. Have only referenced the SafeApp nuget pkg, and performed operations through that.