File removed from project remains locked in Windows 10

[ItsJustATypo]

Thank you for the excellent program!

Describe the bug:
An image file imported into the project, and then removed, remains locked by the program, according to Windows 10.

(Buh? Maybe it's not controllable by the program.)

Steps to reproduce the behavior:

1. File > Import files > {select an image from the operating system folder}
2. Place the image on Track
3. Right-click the image > Remove clip
4. In Project Files > right-click file > Remove from Project
5. File > Save Project
6. From the Windows 10 file explorer, trying to delete or overwrite the file results in "File In Use: The action cannot be completed because the file is open in OpenShot Video Editor. Close the file and try again."

Expected behavior:
After a file is removed from the project, it is unlocked and available to Windows for file operations.

System Details:

• OpenShot Version 2.5.1 (downloaded 5/1/2020)
• Operating System Windows 10, 64-bit (all updates applied)

Log Files:
Exception / Stacktrace:

Screenshots:

[SuslikV]

I cannot reproduce this with Win7. Make sure that you didn't miss the steps in "steps to reproduce the behavior", probably, some action is missing.

1. Is the application was downloaded from the https://www.openshot.org/download/ ?
2. Please, post the OpenShot's log-file right after the steps to reproduce the issue was complete.

[rexdk]

I confirm this with 2.5.1-dev2 (July20) Win 10

Furthermore the exported file is locked - so cannot be moved or deleted - though it can be played by eg VLC.

[ItsJustATypo]

@SuslikV

I cannot reproduce this with Win7.
I reported this for WINDOWS 10, not Win 7.

1. Is the application was downloaded from the https://www.openshot.org/download/ ?
   YES

[rexdk]

It seems that OpenShot keeps undo history - even when a project is saved. So in theory you can re-open a project and un-delete a file from previous sessions - so long as it has not been deleted in the file system in the meantime. Not exactly a sensible logic in my view, but apparently by intent. Yuk.

[ferdnyc]

Yeah, it's intended as a feature. I don't much like it either, and it causes real problems.

That being said, I don't think it's the cause of this problem. Which is to say, the file isn't being held open intentionally because it might be in the project history, and I suspect it would remain locked even if the history is turned off or cleared.

(It is possible to clear the undo history using Edit > Clear History, and that will destroy the accumulated list. Doing it right before save will get you a project file with no history entries in it. That's a step I recommend taking before saving very involved projects, to help reduce the size and complexity of the resulting file. It's also possible (now) to set the undo limit to 0 steps, and that will prevent any history being stored in the project file — but it will also mean that you have no Undo protection even within a session. I definitely don't recommend that.)

The fact that this isn't reproducible under Windows 7, even with the same (or more recent) OpenShot builds, is actually very helpful information, because it means the issue is most likely the result of a change made by either Qt or Microsoft. We certainly don't have any code that intentionally acts differently based on whether it's running in Win7 or Win10. I can't imagine how we'd even go about doing that if we wanted to.

A run of C:\Program Files\OpenShot Video Editor\openshot-qt-cli.exe --debug in a Command Prompt window, along with switching on libopenshot debugging (Edit > Preferences > Debug tab > "Debug Mode (Verbose)" checked) prior to reproducing the issue MIGHT shed some light, but honestly I doubt it. I don't think OpenShot will be able to detect anything out of the ordinary at all, it'll just report business as usual.

What we'd really need to do is dig around in the running process memory and see where there are still file handles open to the image in question. That'd be kind of an undertaking.

[rexdk]

Rats again! Sorry about that, memory playing me tricks.
I've tried this morning, but the build I have installed is playing me up in several ways - it may be because I've had an unstable recent build installed and had to go backwards to a previous build, so I'll need to sort that before reporting any results

[ferdnyc]

I'm going to close this in favor of #3791, since the dissection of this problem is farther along there and there's more concrete information about what's going on with it. But rest assured that the problem is still being tracked, and @ItsJustATypo or anyone else is encouraged to subscribe to #3791 to continue following it.