Please stop the file locking

It's very frustrating to have Resolve put a read/write lock on files and retain that lock even after a file has been removed from a project. I have to close Resolve to release the lock.

Today, I accidentally drug a file over the taskbar and Resolve popped up, and the file looked as though I was dropping it on the timeline, but I never released the left mouse button, and drug the file elsewhere. Resolve put a lock on the file before I even released the mouse button even though the file was never even officially put into the project! I had to stop my work, close Resolve, and do what I wanted to do with the file, then restart.

Very frustrating and time consuming.

P.S. I'm not sure if this still affects 14 but I surmise that it does.

[Peter Chamberlain]

If the file is in the media pool its in the project.
If you delete from the media pool and not have it selected in the storage do have the same issue?

Yes. That was the point of the post. Put the file in the project. Remove the file from the project (i.e. the timeline, the media pool, everywhere in Resolve). The file is still locked in the OS. Can't move it, rename it, delete it in the OS. Have to close Resolve to release the file lock. Very frustrating.

I've experienced the same. Media removed from the Media Pool remains locked by the OS and can't be deleted, moved or renamed.

To be fair, the same happens with Premiere Pro.

To be fair, the same happens with Premiere Pro.

That's putting the bar pretty low though.

Same here

Sent from my ASUS_Z00AD using Tapatalk

Hi there,

Can anyone please give me hints about what's new in the field of locks in R14 ?

I was surprised a TL was locked 2 days ago, and didn't know why and how to unlock it. Didn't find an answer after a quick look in the manual...
Thx in advance

If the file is in the media pool its in the project.
If you delete from the media pool and not have it selected in the storage do have the same issue?

Any update?

+1. This is one of the very first irritations I observed about Resolve.

It's true that removing files from the media pool does not close open handles on this file (verified with Sysinternals tools), but it's sufficient just to view a file in the media browser. Resolve seems to keep these files open forever, and once they're touched in any way within Resolve, they can't be managed from Explorer. (Which includes deleting or renaming, because NTFS is lame.)

Hi,

I was having an issue with Resolve keeping a lock on files and after a search I found this (old) thread.
Am I right in assuming that this is something that won't be changed in 15 or future versions of resolve?
In Vegas I can simply replace or change an audio file in an external program (if Vegas isn't playing), switch back and press play and everything is fine.

In Resolve that's not possible at all.

Luc

I also wrote about it here:

viewtopic.php?f=32&t=72417

I haven't heard anything from BMD on this so no indication that there's any plan to change it.

OK, thanks.
I thought this was by design but if you haven't even used the file it's clearly a bug.

In a black box system you can afford to take ownership of everything. In a multitasking/multi-user environment you just can't do that.

I also did a test with an image, changed it outside of resolve and in that case nothing happens, it isn't locked but Resolve continues with the cached image as if nothing happened.

Luc

It's a big time suck at our shop too. Just last week I was thinking that I need to make time to find a way to low level delete locked files. Many applications do this, but they release the file once it's no longer in use.

Hi,

has anyone tested if this is solved in beta 16?
Don't have the time to test it myself so was hoping that someone could check.

thanks

Luc

Beta 16?

The behavior still exists in 15b8.

Hi,

Did anyone test this in the latest versions? 15.1.2 or 15.2?

Thanks

Luc

they release the file once it's no longer in use.

I wonder if the History feature is what's using the file, in which case it makes sense to keep it locked, at least while that project is open.

Did anyone test this in the latest versions? 15.1.2 or 15.2?

I was able to overwrite files last night on my edit in 15.2

I havn't had a chance to do more extensive testing to make sure it wasn't a fluke, but it at least has my hopes up.

I was unable to move a file on the hard drive after removing it from the bin using Studio 15.2 on Windows 10 Pro (1803).

But I was able to restore the file using Undo, so the file lock makes sense, and shouldn't be changed as it would break the History feature.

But I was able to restore the file using Undo, so the file lock makes sense, and shouldn't be changed as it would break the History feature.

That's an interesting example. But if I delete a file outside Resolve and later try to undo a change that referenced that file, the expected result in my opinion is that the undo should fail.

Consider the current behaviour on Linux. I would be able to delete the file anyway (on Linux, flocks are only advisory). Technically the undo would succeed because of how inode-based filesystems like ext4 work -- the open file descriptor would reference the unlinked inode but the inode wouldn't be freed until the file is closed -- but indeed once the app is closed the file is gone, even though my in-app undo succeeded. Reopening the project would then fail.

So on both Windows and Linux prefer the behaviour where I'm able to delete an unreferenced file outside of Resolve and where an undo action that needed that file would fail. (In the Linux case, you need to choose between two failure modes and this more immediate failure mode is clearer.)

And that use-case aside, certainly there's no reason to hold a file open just because you happened to browse a directory that contains the file in the media storage browser.

I second this request.

That is one part of resolve that's super annoying.

the expected result in my opinion is that the undo should fail.

I would find that...less workable. I don't think it's such a good idea to design the software so that something fails.

there's no reason to hold a file open just because you happened to browse a directory that contains the file in the media storage browser.

I would agree with that.

I would find that...less workable. I don't think it's such a good idea to design the software so that something fails.

In the Linux case either way you have a failure. I'd argue in fact the failing undo is a much better failure mode than having undo succeed in a project only to find your project is broken next time you reopen it.

I'd argue in fact the failing undo is a much better failure mode than having undo succeed in a project only to find your project is broken next time you reopen it.

My point was that locking the file is the best solution, in the Undo scenario, for all OS's.

I don't know if that's possible on Linux, but it is on Windows, and should remain.

My point was that locking the file is the best solution, in the Undo scenario, for all OS's.

What you are saying makes absolutely no sense.

When you add a file that is stored in your computer into Resolve's bin, you don't ACTUALLY do anything to that file or to the storage location of that file. What you do is create a Resolve's representation of the file that REFERENCES the actual one.

In the case of undoing a clip removal from Resolve's bin of a file that was also deleted from your computer what happens is that the clip will appear in your bin but it will be marked with a MEDIA OFFLINE flag. Nothing else will fail.

the clip will appear in your bin but it will be marked with a MEDIA OFFLINE flag. Nothing else will fail.

I consider the Missing Media a fail.

For anyone reading this, it appears this issue was corrected in v16, at least on Windows. I just added a clip to the bin, removed it, left Resolve running, and renamed the file in the OS without any lock complaints.

I can't confirm it's fixed on 16.0. I followed the same steps (add clip to bin, remove clip from project, try to rename from Explorer) and the file was still in use by Resolve.

Edit: just tried 16.1.1 and now the test was successful. So possible the fix was introduced in 16.1. It's much better now. I can even rename files that are added to the project. Excellent.