Openshot-qt: OpenShot Video Player will not open on Windows 10 64bit

[David263]

The bug was already reported but was closed without being fixed!

Describe the bug:
OpenShot Video Player will not open on Windows 10 64bit when clicking a link (icon)

Steps to reproduce the behavior:

1. Make link/shortcut containing "C:\Program Files\OpenShot Video Editor\launch.exe"
2. Click the link.
3. An error box pops up. The text cannot be copied but I will make a screenshot.

Expected behavior:
OpenShot should open.

System Details:

• OpenShot Version [e.g. 2.4.3]: unknown (latest)
• Operating System / Windows 10,

Log Files:
NO LOG FILES because .openshot_qt/ folder was not created.

Exception / Stacktrace: Screenshots:

Suddenly started happening.

Important: when I issue the same command as in the link ("C:\Program Files\OpenShot Video Editor\launch.exe") in an admin console, it works: it opens OpenShot.

Please fix, thanks.

[David263]

Until this bug is fixed (if ever), I found a workaround:

1. Right-click the link to OpenShot.
2. Select Context Menu > Properties.
3. Select Tabs > Compatibility.
4. Select Run this program as an administrator.
5. Click OK.

[ferdnyc]

I'll copy my comment from #1319 here, since that is a closed issue... but first, on the issue of running OpenShot as an administrator: That may succeed in getting OpenShot to run, but it is a dangerous workaround that I would _urge_ anyone to avoid trying. It's also a configuration we can't support, as OpenShot was not meant to be run with admin privileges.

When started like that, OpenShot has access to modify every file on the system, even protected system files. Which means that a bug in OpenShot could cause you to lose important data, or even prevent Windows from working at all.

For the security of your own system, _please_ uncheck that box.

And if you're willing to work with us to find the problem, we can hopefully fix this properly. (It's not something that most Windows users experience at all, which is why we still haven't ascertained the exact cause of the issue. We _believed_ that removing the settings directory should fix it, which is why that previous bug was closed. Clearly that's not sufficient in some cases.)

Some of the other developers may have better testing resources, but since I don't have access to a Windows 10 system, I rely on affected users to provide information that might help us solve it.

[ferdnyc]

From https://github.com/OpenShot/openshot-qt/issues/1319#issuecomment-561632609 :

@David263 The problem is that it's a permission problem on your local computer, which is not something we can easily fix. Completely deleting the .openshot_qt folder in your home directory _should_ fix it, because OpenShot will automatically re-create that folder on startup. The only way that would fail is if your user account doesn't have permission to create folders in your own home dir. The fact that running it as an admin succeeds would seem to confirm that, but it also may be making the problem worse: when run like that, OpenShot will create an .openshot_qt folder that's owned by Administrator, which will definitely prevent it from writing to that folder as a regular user.

If you could try one thing for me, it might help us get a better handle on this problem: Could you completely delete the .openshot_qt folder in your home directory, empty the trashcan to make sure it's been removed, and then CREATE that folder — right in your C:\Users\username\ folder and with the exact same name — before running OpenShot? All of this needs to be done from your regular account, WITHOUT admin privileges, and OpenShot needs to be completely stopped before you do it. (You may want to use the Task Manager to make sure, or restart the computer first.)

That _should_ fix the permissions issue starting OpenShot as a regular user, and if it does maybe we can add some tools to the Windows installer to optionally reset permissions. (We just have to figure out how to do it without creating the same problem, since the installer runs as Administrator.)

[David263]

Thank you for your reply. I've found the same problem on Windows 8.1 (which I also use).

I did your experiment:

1. I removed the "Run as administrator" compatibility property from the OpenShot shortcut/icon.

2. I deleted .openshot_qt from the C:\users\USER directory, using the Shift key to delete it permanently (which can't make a difference, by the way).

3. I clicked the OpenShot shortcut/icon.

4. I get the same error message (access denied to user profile folder).

I looked at C:\users\USER security properties, and it includes all operations for the USER. So OpenShot should have full access, since I am logged in as USER.

By the way, another bug I found in OpenShot was its undocumented use of the HOME environment variable, which overrides C:\users\USER and thus creates confusion by creating .openshot_qt in an unexpected folder. Another product (emacs) uses HOME. I deleted the HOME variable.

[ferdnyc]

Did you try manually creating a C:\Users\USER\.openshot_qt folder, as a regular user, before running OpenShot (as a regular user)?

2. I deleted .openshot_qt from the C:\users\USER directory, using the Shift key to delete it permanently (which can't make a difference, by the way).

I wouldn't imagine so, but when dealing with issues like this I find it's best to be extra-careful.

By the way, another bug I found in OpenShot was its undocumented use of the HOME environment variable, which overrides C:\users\USER and thus creates confusion by creating .openshot_qt in an unexpected folder. Another product (emacs) uses HOME. I deleted the HOME variable.

OpenShot doesn't actually use the environment variable HOME, at least not directly, and I certainly can't find any code that would _create_ that variable.

OpenShot finds the path to your user directory with the Python command os.path.expanduser("~"). ~ is a Unix shortcut for $HOME, so it is possible that it's unexpectedly influenced by the existence of a HOME environment variable. I have noticed that running OpenShot from a MinGW shell will cause OpenShot to use the MinGW home directory instead of C:\Users\username\, which may be due to MinGW setting $HOME.

I mention in https://github.com/OpenShot/openshot-qt/pull/2976#issuecomment-554612692 and its followup that there are Qt variables (QStandardPaths) for those things that, I agree, we should be using instead. (Though it probably wouldn't stop OpenShot using a different location when running under MinGW.)

Still, I'm confused, if there was a HOME set that was causing a directory to be created elsewhere, and you removed it, did that have any effect on the behavior of OpenShot?

[ferdnyc]

OpenShot finds the path to your user directory with the Python command os.path.expanduser("~"). ~ is a Unix shortcut for $HOME, so it is possible that it's unexpectedly influenced by the existence of a HOME environment variable.

I'm still sort of surprised by that, as I would've thought os.path.expanduser("~") would be equivalent to %USERPROFILE% in Windows Python. And from the error message Python is showing, it _seems_ like it is, at least in some situations.

[David263]

For completeness, I just manually created .openshot_qt in the C:\users\USER folder. Clicking an OpenShot link still gives an error message.

Out of curiosity, I clicked on C:\Program Files\OpenShot Video Editor\launch.exe directly. I got the error message. OpenShot requires Administrator access for some strange reason. And since it didn't at first, during a few days when I was first using it, something I did recently on my computer must have triggered the problem. I'm 73 years old and my memory isn't good enough to help.

"OpenShot doesn't actually use the environment variable HOME, at least not directly, and I certainly can't find any code that would create that variable."

I'm sure that's true, and as you said, OpenShot uses other libraries. Somewhere HOME is used and this should be documentated in OpenShot. OpenShot works fine without HOME. Probably a library uses %USERPROFILE%. But I believe that USERPROFILE is set correctly, and it looks like its security ACLs are correct. I need more suggestions.

"if there was a HOME set that was causing a directory to be created elsewhere, and you removed it, did that have any effect on the behavior of OpenShot?"

It seemed to make OpenShot work a little better, and stop storing video pieces in .openshot_qtassets. And for several days, links to OpenShot also worked.

[SuslikV]

I'm still sort of surprised by that, as I would've thought os.path.expanduser("~") would be equivalent to %USERPROFILE% in Windows Python. And from the error message Python is showing, it _seems_ like it is, at least in some situations.

Surely, the os.path.expanduser("~") equals to %HOME% in Windows only if the mentioned environment variable is present (no matter admin or not) and for newly running OpenShot the .openshot_qt is created in such dir then. Tested under the Win7. If there is no %HOME% variable set, then python expands the os.path.expanduser("~") to the %USERPROFILE% as I see.

The Python 3.8 seems to be no longer uses %HOME% on Windows for the os.path.expanduser() https://docs.python.org/3/library/os.path.html#os.path.expanduser
But all previous version (and OpenShot of course) is still affected.

[ferdnyc]

@SuslikV Huh, good find, thanks! So I guess I wasn't the only one surprised by the use of HOME on Windows.

It's kind of a moot point anyway, as the RIGHT solution is to stop using the user's home directory — _whatever_ it's called — to store OpenShot's application files. I'm about halfway through with an implementation of the QStandardPaths storage migration I mentioned. Qt's library even has a function that lets us explicitly request a writable path to store files in, which should put an end to these permissions issues for good. (Here's hoping.)

[David263]

@SuslikV, Congratulations for taking the initiative to fix this minor but very annoying bug. I found out about the HOME environment variable only because it happened to occur to me as an explanation why a universal application might store files under another universal application. But I'm an experienced software engineer who knows about environment variables, which came from the Linux mindset, not Windows, even though Windows graciously implements them.

[David263]

The other bug, requiring Administrative access for OpenShot, remains. If no one else can replicate it, I'll have to assume it's just some security strangeness on my own computer.

I just tried double-clicking "C:\Program Files\OpenShot Video Editor\launch.exe" again. This time, I didn't get the error dialog box (because I had changed its "compatibility" property to allow Admin access), but I did get the UAC dialog box ("do you want to allow this app..."). If OpenShot actually requires admin access, it should be code-signed so UAC is not invoked. Code signing is not difficult, but it does require purchasing a special security certificate (those are not yet free as of 2019).

[ferdnyc]

@David263 OpenShot does not require admin access, and as I've said is _not_ intended to be run that way. You're not the only one who has reported running into permissions issues on Windows 10, though we still really have no clear idea what the source is as we have so far not been able to replicate the issue, or even determine a common cause.

(You probably _are_ the only user who's resorted to running it as Administrator in order to work around the permissions issue, and as I said that's something I really can't endorse. But, as a workaround it is effective, so ultimately that's your decision to make.)

[SuslikV]

I never seen evidence where the UAC messages were helpful. If user decided to run some application - nothing will stops him.

The UAC message will never gone until you disable its notifications manually. It's kind of instant "permissions warning" from the system. Nothing more. System can give you user elevation prompt if needed. Signing the .exe file will not help here.

[David263]

I found a new variant of this problem on Windows 10. When I assigned launch.exe as the default program for .osp files and tried to open a .osp file, OpenShot created a folder named %USERPROFILE% (yes, including the percents) in the current folder and created a new HOME system environment variable containing the string %USERPROFILE%. After this, trying to run OpenShot using a link to launch.exe resulted in a stack dump error message saying it doesn't have access rights to folder %USERPROFILE%. After I deleted this environment variable I was able to run OpenShot again.

[stale[bot]]

Thank you so much for submitting an issue to help improve OpenShot Video Editor. We are sorry about this, but this particular issue has gone unnoticed for quite some time. To help keep the OpenShot GitHub Issue Tracker organized and focused, we must ensure that every issue is correctly labelled and triaged, to get the proper attention.
This issue will be closed, as it meets the following criteria: - No activity in the past 180 days - No one is assigned to this issue
We'd like to ask you to help us out and determine whether this issue should be reopened. - If this issue is reporting a bug, please can you attempt to reproduce on the latest daily build to help us to understand whether the bug still needs our attention. - If this issue is proposing a new feature, please can you verify whether the feature proposal is still relevant.
Thanks again for your help!

[David263]

Yes, this issue should be reopened--see comment #15 above.