Let me know if you have a reason to believe this to be a bug in our code, this definitely shouldn’t be happening!
Have you considered just setting the equivalent environment variables? It might be the simpler way to go here 
1 Like
I don’t have any direct reason to believe so, but no indication of something else either. I’ve run maybe a couple of hundred times with MockVault, and have never seen that happen before. But it was the first time I had a file of 50Mb size (I had let it insert all night and day). As I have looked at the code I haven’t seen anything that could cause it. But I could try again and build a big file and see if I might trigger it to happen again.
Couldn’t get it working that way either 
The SAFE_MOCK_UNLIMITED_MUTATIONS was already there, but adding SAFE_MOCK_IN_MEMORY_STORAGE with value true made no difference. I wonder what that might be about.
hey @oetyng, I tried using mock_in_memory_storage option in the config file and also used SAFE_MOCK_IN_MEMORY_STORAGE environment variable, and both methods are working fine.
1 Like
Have you confirmed that the variables are set properly (i.e. by running env | grep SAFE)? What OS are you on, by the way?
About the config file, it seems that it doesn’t even load the file.
And the environment variable seems to have no effect. I have no idea what it’s about.
I’m on Win10. The variables are there, not sure how more to confirm them: doesn’t seem to be any trailing white space or anything like that.
A thought: Wouldn’t it be much easier if the API just took a config object (and naturally not require it, whereby default values used), and any users of the API can handle the config in anyway they need to.
Seems that there would be less strange things in the API, simplifying what it needs to do under the hood (looking for ExeFileStem, dealing with environment variables, setting search paths and trying to find the config etc.).
I think it is a little bit odd way to handle the config. Most API:s I use regularly just take some stuff as a ctor parameter, or use some fluent API with a builder (if they want to be fancy).
2 Likes
Can you please try one more thing: please print out the contents of the configPath file in the code you posted above:
to make sure that what your application sees it is actually the same as what’s on the filesystem.
And for the environment variables, I’m suspecting the variables are not accessible to the application for some reason (due to some quirk with Windows or .NET, I haven’t worked with these in a while but i remember that env vars are not commonly used for configuration in this ecosystem). Can you try printing out the values of the env vars from within your application? Reference
I agree. We use config files throughout the backend – Crust and Routing both use them, allowing changing settings without recompiling. But it’s certainly possible to also support passing a config object to the SAFE App API – app_unregistered already accepts a crust config object as an optional parameter, and we could extend this to the safe_core config.
I believe that doing so would make things cleaner and would allow us to deprecate the environment variables. I was part of the design and implementation of the env vars but I have to admit that they are technically lacking: any app can change them and thus change the behavior of other apps. We also run into possible issues with multithreading: one thread can write to a var while another reads it – there is no concurrency guard on env vars, which is they are known to be a bad solution in these cases. We actually ran into this problem while writing tests because cargo test runs each test in a separate thread, so using env vars to test for certain things was tricky and we (well, I) ended up putting some dirty hacks in place.
Of course, we only use the config for the mock network, so the security points are moot. But passing the config in through the API would just be better, easier, and allow us to remove the hacks we use for testing.
3 Likes
I agree with @marcin on that. @oetyng can you try setting env variable using Environment.SetEnvironmentVariable(string variable, string value) in you app/test. I used used the same.
2 Likes
finally! That works
I don’t know what is wrong with the other approach or execution, I did it through system settings.
Anyway this will be plenty good for now for creating larger test data sets.
Thanks @ravinderjangra and @marcin.
I’ll try remember leaving the computer on for a night and a day while building on the MockVault file as well, just to see if that file overwrite can be reproduced.
4 Likes
Unfortunately, it seems I cannot manage to go back to mock vault file now.
I have set it (Machine, Process, User) through code, through system settings, can see it when fetching both through code and console. Also made sure there is no config file there. But it still uses in-memory store. It’s as if there’s some cache somewhere. 
EDIT: Holy smokes, and my MockVault files that I had (one named MockVault_1 as it was copied it to keep it) disappeared 
I had the folder open, I debugged one of the tests I always run, I tabbed back to the folder, and before I let go of it I could see the two files (as it had shown them there before), and when I released the keys they were gone (view got refreshed as window came into focus). Both at around 11 Mb. I don’t understand how the MockVault_1 can have disappeared. It should be unrecognizable as it has a different filename.
I’ve searched the entire disk for “MockVault”, nothing found. And they are not in the trashbin (older ones I deleted myself before are there).
Okay, that’s weird. I’m running out of ideas. Could it be that some other process deleted the files, like an Antivirus? What path were the MockVault files in?
The setting must be coming from either a config file or an environment variable (is this what you mean by “system settings”?). Are you sure these aren’t set?
I think it would be helpful for us to add more logging in the code (e.g. “config found at path X with settings: […]”). That in combination with removing the environment variables (I wrote up an issue here by the way) should make these situations must easier to debug 
1 Like
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:
And the third and last check is via Control Panel\System and Security\System => Advanced system settings => Environment variables
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.
1 Like
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
3 Likes
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 
4 Likes
Did you see this (I assume you googled the problem)
They suggest some reasons
- disk cleanup
- antivirus
- cc cleaner
If I had a swear jar, it would have been filled so many times over in my career due to things like this 
3 Likes
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.
Maybe instead of having “true” you could have “Remove_env_var_to_disable”
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.
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.
1 Like
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