Windows - failure to release file handle from source

Bug
1

What is your operating system?
Windows 10 20H2 x64
Windows 10 21H1 x64
… and a few earlier releases

What is your Shotcut version (see Help > About Shotcut)? Is it 32-bit?
21.05.18 x64 portable
… and all prior versions going back ~2 years

Can you repeat the problem? If so, what are the steps?
I realize this could be a Windows issue, not necessarily a SC issue. But, perhaps, something can be done in SC to alleviate the issue.

I use SC for restoration of second-source material. It could be digitization of film, tape, analog capture, etc. Sometimes, it’s cheap camera, bad cell phone white balance, exposure, lighting, sound, etc. If I think the export of my SC edit is “better” than the original, I’m not opposed to deleting the original.

That’s where the problem happens. Occasionally, Windows Explorer complains it can’t delete the original file because it is in use by another process. I’ve resorted to file handle un-locking tools to explain (always shotcut.exe process) and to force-close the file handle to delete the source file.

Work-arounds are a re-boot. Sometimes, but not always, Task Manager to kill the explorer.exe processes and re-launch it. Recently, it’s been happening not long after rebooting.

Either SC isn’t thoroughly releasing file handles, or Windows Explorer is missing the release event. Either way, it’s a pain.

2

Are you attempting to delete the files while Shotcut is still running, or after Shotcut has been fully exited?

Is the media still loaded in the Source window or a playlist?

If Shotcut is the lock holder, I’m not sure why this helps or even works.

3

yes shotcut is running. I’ll run through restoration of a couple of videos at a time.

yes the encode job is complete before trying to delete the source files.

no the project is not open. I close the project when I submit the encode job.

no the source files aren’t open in another project.

I can’t say for sure whether killing explorer.exe and re-launching it actually helps. Mostly it’s just a full reboot cycle and start over.

4

It is a well known problem that files are not closed immediately upon File > Close or opening a different project or file in Source. There are things that still hold stale references until they are replaced by opening and selecting other things. It needs improvement, but usually the workaround is to close Shotcut - much less impactful than a reboot.

1 Like
5

I have found that in a windows environment, when files hang so that they can’t be deleted it’s because the file has somehow been retained in the source window. Often, after deleting the file from the playlist and closing the project, if you add one (or sometimes more than one) new file to the playlist, the original file is released from the source window and can be deleted. Thereafter, the files in the playlist can be removed. Though by no means convenient, I find this a better workaround than having to close shotcut and restart it.

1 Like
6

This is helpful. I was using lockhunter and iobit unlocker. Sometimes one of them is unable to release the lock. Sometimes neither.

I tried sysinternals, too, but clearing the handle forcibly closes shotcut. Not helpful when you have jobs in the queue :frowning:

I recently had an issue putting a new file in a playlist didn’t release the lock on the first. Closing the project and using a third file finally released the lock on the first.