Repository navigation
[Bug]: Overwriting existing file when exporting results view sometimes fails #4168
Description
Activity
I've tried several times, and can't reproduce it, albeit I'm on WIndows 11.
Do you have an antivirus installed? This could have the file open.
Just to rule out the obvious, but have you tried the nightly version? You can download the .zip and just extract it - you don't have to install it and it won't upset your current version.Do you have an antivirus installed? This could have the file open.
Only standard Windows Defender, but nothing else. I might have to try running Process Monitor in parallel to see if I can catch the error that way and maybe get some clues as to what might have failed.
Just to rule out the obvious, but have you tried the nightly version?
Not yet, but I'm going to give it a try, thanks for the hint. Since the issue only happens somewhat randomly for me, too, it'll be a little while, though, until I can give some feedback on whether there's any improvement there.
Powertoys has a 'file unlocker' tool, so you right-click a file and it'lll show what process has it open.
Does it do it across different files in different locations - eg, desktop, my documents folder, etc?
Or is this on a network, etc?It's a local file on my hard drive, in some subfolder of my documents folder.
Powertoys has a 'file unlocker' tool, so you right-click a file and it'lll show what process has it open.
Yeah, but the issue seems to happen only transiently, because like I said, so far a second attempt a few seconds later has always succeeded. Hence I suspect looking at file accesses with Process Monitor might be a bit more productive (hopefully)…
I've finally managed to record an instance of this happening with Process Monitor (I'd already feared it might have turned into some sort of Heisenbug): SQLite Browser export error filtered.zip
Up to 19:27:09 is the failed attempt, and starting from 19:27:29 the second, succesful attempt.
What seems to be happening is that when using the OS file open/save dialogues, there's a race condition with Windows Explorer temporarily opening the selected target file in order to add it to Windows' recent files list (compare the stack trace of Explorer opening the file) vs. the rename attempt of the atomic file writing logic happening precisely during that small window of time before Windows Explorer has closed the file again.
The problem then is that your (respectively judging from the stack trace for the rename operation, Qt5's actually) atomic file writing logic is using MoveFileEx, and AFAIK MoveFileEx always fails if there are any open handles to the target file, even if they have been opened with full sharing permissions.
After a bit of searching and stumbling across rclone/rclone#9574 which deals with a somewhat related problem, the most elegant way of solving might be using SetFileInformationByHandle with FileRenameInfoEx and
FILE_RENAME_POSIX_SEMANTICS | FILE_RENAME_REPLACE_IF_EXISTSinstead for that kind of potentially overwriting renames where available (meaning 1.) a modern enough Windows, supposedly Win 10 1607 and 2.) a supported file system, i.e. NTFS) and only using MoveFileEx as a fallback otherwise.The "only" problem is that the fix would then have to happen inside Qt code…
What did you do?
What did you expect to see?
Exporting the data succeeds and the file is overwritten with the fresh data.
What did you see instead?
Sometimes, the CSV export randomly fails with an "Access denied" error, even though I don't knowingly have that file opened anywhere. So far, a second attempt at overwriting the file has always succeeded, and I've never encountered similar issues in other software on my computer.
DB4S Version
3.13.1
What OS are you seeing the problem on?
Windows
OS version
Windows 10
Relevant log output
Prevention against duplicate issues