Jim Simon wrote: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.