Default Save Location in Windows

[mattgrimley]

Hi, i'm new to Mu, so apologies if i'm re-opening a can of worms! I can see some discussion of this topic historically, but I am using the latest Mu 1.0.2 and I'm still seeing an issue.

I am running Mu on Windows 10 clients (have tested on Build 1909 and 1803) connected to a large Windows 2016 AD network. Our users connect to mapped home directories and as with most large academic networks, roaming profiles are not used (i.e. local profiles are used for temp files, but no data is stored in them).

Now, when i launch Mu, the default Open / Save location is the local profile (C:\Users\Username\mu_code) instead of the mapped home folder (n:\mu_code or \server\share\mu_code) which means that code will be saved the local computer and unavailable for the user from any other client computer.

I actually had the same issue with a tool called GDevelop and the issue was overcome by changing the variable used to identify the save location. https://github.com/4ian/GDevelop/issues/1102

I don't know if you use the same API's that GDevelop uses, but in effect it appears that the "HOME" variable actually mirrors "USERPROFILE" rather than "HOMESHARE" which is returned by the "My Documents" variable. In the GDevelop case, using "My Documents" instead of "Home" seemed to result in the correct directory being selected in both stand-alone, roaming and local profile configurations.

Thanks in advance, Matt

[tjguk]

@mattgrimley thanks for bringing this up; as you realise, the question does arise from time to time. We actually lean on a cross-platform library called appdirs for our paths. Just at the moment I don't have the time to dive into our/their code to see how the interaction works and how it results in USERPROFILE. Youre' very welcome to peruse the code and see what we're doing in more detail.

In short, I'm happy to consider a concrete proposal but with the obvious caveat that I don't want to end up making things niver for one sort of setup only to pull the duvet off an existing setup which was working perfectly well before and now has problems... IYSWIM

[tjguk]

BTW somewhere in one of those existing discussions was an unfleshed out proposal to allow switches passed in to Mu via a shortcut to override the default directory. The idea would be that, even if we didn't want to change our code, a particular installation could override consistently. As I say I know it was suggested (probably by me) but it'd not achieved any traction yet. Feel free to comment on that or any other proposal.

[mattgrimley]

Hey @tjguk I'm afraid i'm just a beleaguered network manager, rather than a coder. Default save locations comes up now and again even with the biggest software. It used to be covered by the "Start In" variable on the Window Shortcut, which appears to be set to %HOMEDRIVE%\%HOMEPATH% in Mu, though the program doesn't use it. I was naively hoping you might be using the same library that GDevelop used and we could benefit from their experience, but clearly not (i think their library was electron).

Perhaps someone will find themselves in that area of code at some point having read this overview and a solution will present itself!

Appreciate the reply. Matt

[tjguk]

@mattgrimley I'm happy to revisit what we're doing there when I get a moment. (I'm speaking as the Windows "subject matter expert" on the Mu team although my view might ultimately be overriden by wider considerations).

[mattgrimley]

Well, for my part, if it does come up and I can test any changes out, i have large network at my disposal and experience of software testing using different scenarios (to avoid the fix for one, break for many scenario). But more importantly, i understand this is open source and fundamentally, i just appreciate the work that goes in and the tone of the "support"! :)

[tjguk]

Ok; depending on what shows up when I start to look it might be fruitful for us to have a more one-to-one session to thrash out possibilities. Would you be up for that (whenever and however)? If not, we can certainly continue via the Github issue.

[tjguk]

Well I've had a quick look. And I was wrong (sort of). For the "home directory" where the mu_code folder is located, we're not using appdirs: we're simply using the built-in os.path.expanduser function. Since it was first implemented, that function has given priority (on Windows) to the not-usually-defined HOME env var, since that's the most common approach on *nix. I recall having discussions years ago over whether that was or wasn't a good thing on Windows. But between 3.7 and 3.8, the use of the HOME env var has been dropped.

From Python 3.8 onwards it tries (in order of a non-empty env var):

• USERPROFILE
• HOMEDRIVE + HOMEPATH [defaulting HOMEDRIVE to current]

It doesn't try HOMESHARE at all (and, if I'm right, that will only be defined if the AD "Home" element is a UNC?). IIUC what you'd like is have it prefer HOMESHARE (or possibly HOMEDRIVE/PATH if those apply).

I've just pinged @ntoll to ask which version of Python the alpha builds are using, but it looks like this doesn't help your case because even 3.8 will prefer USERPROFILE over a network path. Before I start to think about solutions or workarounds, have I understood your situation correctly?

I had a look at the GDevelop codebase (and the electron codebase it's leaning on here). I can see that they switched to using "Documents" after the discussion you referred to above. But it looks as though that's only in the template (so defaults) section which is a little less drastic than our "home" selection which basically affects every save you make with the editor.

The trouble is that, since forever, Windows hasn't had a single solid "this is home" story: it's had several. And that's even before you factor in roaming profiles and home shares on NT/AD networks. That's not helped by the fact that the shell folders (such as My Documents, Pictures, Videos etc.) can be redirected via the Windows shell functionality independently of any roaming profile / home share stuff which you may have going on.

All this is to say: I don't think there's a clear case for changing our default. Certainly I don't think we can change it to "My Documents" at this stage, even if I felt that that was the best place. However, speaking for myself, I might consider different search order from Python's built-in: look first at HOME shares and then at USERPROFILE. On my (corporate AD) laptop, HOMEDRIVE + HOMEPATH = USERPROFILE.

[ntoll]

Hi folks,

The current alpha uses Python 3.6, the next alpha will be on Python 3.7, and (assuming things mature and bugs are ironed out), the final release may be on Python 3.8.

Does that help..?

From the sounds of it, this is a Windows-heuristics type problem, and since I'm a Linux user I have no experience to be able to make a call on this. I'm all ears for a sensible, pragmatic and flexible approach to this.

N.

[tjg-global]

Thanks @ntoll. As it works out it just means that the "HOME" variable would be honoured (which isn't usually set on Windows anyway) but only until we bump to 3.8 at which point it won't be honoured.

I can think of possible approaches & workarounds here but I'd like to hear back from @mattgrimley to see what might work for him

[mattgrimley]

Hi guys, I'm not back in the office until tomorrow, but I'll have a read through then and try to come back to you with what variables look like what on my system. I'll also rig a stand-alone windows 10 VM as a control.

On Mon, 2 Dec 2019 at 14:42, tjg-global notifications@github.com wrote:

Thanks @ntoll https://github.com/ntoll. As it works out it just means that the "HOME" variable would be honoured (which isn't usually set on Windows anyway) but only until we bump to 3.8 at which point it won't be honoured.

I can think of possible approaches & workarounds here but I'd like to hear back from @mattgrimley https://github.com/mattgrimley to see what might work for him

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/mu-editor/mu/issues/965?email_source=notifications&email_token=ABFK76XOTC7K4E3YX26DR5LQWUNG3A5CNFSM4JTTAWMKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFTWVWA#issuecomment-560425688, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABFK76WHY76APHD6KP3I44TQWUNG3ANCNFSM4JTTAWMA .