Keepassxc: Saving DB fails intermittently on windows

[mattvchandler]

Current Behavior

Most of the time, attempting to save a database file on windows fails with this message:

Writing the database failed.

The Process cannot access the file because it is being used by another process.

A copy of the DB file is written at path\todb.kdbx.<2 random? letters>\

Occasionally, the write does go through without an error.

Steps to Reproduce (for bugs)

I have not yet been able to reproduce the error with a fresh database created with either keepassxc or keepassX. Obviously, I'm not willing to upload one of my real DBs.

Context

Process Explorer reports no other process has a handle to the .kdbx file.

Your Environment

• KeePassXC version/commit used: 42c0815cdaa652bcdf25b90a2a4a20b2981a39b2
• Qt version 5.6.2
• Compiler: gcc version 6.3.0 (Rev1, Built by MSYS2 project)
• Operating System and version: Windows 7 SP1

[droidmonkey]

What is the origin of your original DB that caused this error? Was it created in KeePass or some other program?

The reason why this error is thrown is for three distinct reasons:

1. Cannot open the file for writing
2. Cannot write to the IOStream for some reason
3. Cannot commit the changes to the file AFTER writing to the IOStream

[mattvchandler]

Originally created in KeepassX 0.4 imported into KeepassX 2.x

[mattvchandler]

I deleted all entries from the problematic DB and see the same error with the now empty DB. See attached. master pw is 'asdf'
test.zip

[droidmonkey]

No problems for me under Windows 10 64-bit

[dsbert]

I'm experiencing this same issue. Windows 7 64 bit. This may be due to keepass not playing well with other file watchers. I have my database file in a drop box share. If I move the file outside of that share, I don't see the errors anymore.

I did not experience these issues on KeepassX

[mattvchandler]

I have my problematic files in Dropbox too.

That seems to be the key. I can reproduce the problem consistently with
a new database file saved in Dropbox, and the problem stops when Dropbox
is off or the file is moved outside it.

On 1/30/2017 9:51 AM, Dan wrote:
>

I'm experiencing this same issue. Windows 7 64 bit. This may be due to
keepass not playing well with other file watchers. I have my database
file in a drop box share. If I move the file outside of that share, I
don't see the errors anymore.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/keepassxreboot/keepassxc/issues/197#issuecomment-276153705,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABd4c3PCnPn6P6e9yrP634TorSWxjNRuks5rXjEYgaJpZM4Ls9Zj.

[droidmonkey]

Interesting, I store mine in Google Drive (and previously OneDrive) and have not had any issues. I will test with dropbox.

[phoerious]

I don't have issues with Nextcloud/OwnCloud (i.e., csync), either.

[Dunkh4n]

Hi,

Just to say that i have the same problem..
Dropbox or GoogleDrive..
I want to use KeePassxc instead off KeePass, but i can't because off this bug :(

[dsbert]

This is still a problem in version 2.1.3. However, it seems like it might not be happening quite as often.

[droidmonkey]

So I came upon this issue with a slow upload to google drive... seems like when these cloud providers are syncing the file they hold a lock on it. This prevents KeePassXC from writing to the file (naturally). There is really nothing we can do about it...

[dsbert]

How do other programs handle this behavior? How does Keepass 2? Is it
silently failing in the background and just not notifying me? It is trying
to save multiple times before it raises an error? I understand there are
difficult issues when integrating with third-party applications. However, I
feel like there is definitely more that could be done to smooth this out. I
know this is an open source program (and everything that implies), but I
hope this issue isn't just closed as 'not fixable'.

On Sun, Apr 2, 2017 at 11:57 PM Jonathan White [e-mail]
wrote:

So I came upon this issue with a slow upload to google drive... seems like
when these cloud providers are syncing the file they hold a lock on it.
This prevents KeePassXC from writing to the file (naturally). There is
really nothing we can do about it...

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/keepassxreboot/keepassxc/issues/197#issuecomment-291043780,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABQkmq9gHHFdBMqn-huUxxOCc9MSMoVoks5rsG4tgaJpZM4Ls9Zj
.

[droidmonkey]

I found that waiting for the upload to complete worked great. Other than that I am out of ideas... unless we are being too strict when we try to write to a file? Trying multiple times or waiting a delay doesn't seem to be a good solution to me. I don't know what other programs do, perhaps you can experiment for us?

https://github.com/keepassxreboot/keepassxc/blob/develop/src/gui/DatabaseTabWidget.cpp#L348

That is where the database file is actually saved. I'll run this in debug mode and see which block it fails in.

[ghost]

The same issue, also what is this ?

[ghost]

@droidmonkey seems that keepass2 works with copy of original db file ".lock", to save it delete original db file and rename .lock to original db file name

[SemyonDragunov]

I have problem too. Win7 64bit. Dropbox sync is enabled - DB no save (save many files.). Disabled - Normal Save.
KeePassXC 2.1.4

[tronjs]

I have the same problem

[phoerious]

I would assume that this is a Windows-only problem due to the fact that Windows is the only OS that grants and requires exclusive file access. I'm not sure what we can do about it.

[JaggedJax]

I get this same issue with the kdbx file sitting in a dropbox folder on Windows 8.1 x64. Even after the file has been synced by Dropbox I cannot save in KeePass XC and it just keeps creating new temporary DB files in the folder every time it tries to save.

edit: Note that closing KeePass XC and opening KeePass 2, it does not have trouble writing to this same file under the same scenario so it seems to be more than just an exclusive windows file lock since other applications can write to the file.

[droidmonkey]

We probably make the wrong checks for writability which result in false negatives

[felixkopf]

Same issue here.

I figured out, that when I click "Save" or press CTRL+S two times quickly in a row, it works.
The first attempt fails with the error message and a new .kdbx.'something'-File is created in my Dropbox.

[tooor]

Windows 10 64-bit experiencing 100% reproducible behavior when I do the following:

1. Have Dropbox running
2. Store my DB file in Dropbox folder
3. Try to save DB file.

Problem is immediately fixed _without_ restarting keypassxc when I close Dropbox, then try to save again. So my temporary solution is just close Dropbox when I can't save the DB, then start Dropbox again to sync my newest version of DB to cloud.

[jask05]

Hi,

I have the same problema like @tooor. Are there any workaround?

Thanks!

[rockihack]

Probably a qt bug. QSaveFile uses a temporary file without exclusive lock.

https://bugreports.qt.io/browse/QTBUG-57299

[snospar]

I can confirm the same issue when using Windows 10 and opening the kdbx file from my NAS (drive mapped using SMB). Bizarrely, if I click multiple times on the Save button it will work - I hear the NAS update the file (the disk chunters) and when I shut the application it knows that the file has been saved so doesn't prompt.

I've never had this issue when accessing the same kdbx file from the same NAS when using Linux on the same dual boot machine.

[andreas-profitlich]

same problem (Windows 10, Dropbox) - this is a blocker guys

[krizian]

same problem here for three Windows PCs in a private network with NAS Server (1x Windows 7, 2x Windows 10). Autosave doesn't save. We can't use KeepassXC till this issue is solved. Agreeing to andreas-profitlich: this is a real blocker!
If the save Button is clicked manually a second time it will work. As we need a DB and synchronisation, this is no option.

[droidmonkey]

The use case of a shared database among multiple users was not programmed into this app. I consider a file sync service as a multiple user in this context. It is technically not a blocker since there is a workaround (click save till it works). With that said its on my short list to fix.

[CosmicToast]

@droidmonkey the FAQ gives an impression that using a file sync service (to synchronize the same db accross multiple machines of a single user, as in this issue) isn't just supported, but is recommended.

Maybe it makes sense to modify the FAQ to reflect the original intent in this case?

Furthermore, spamming save seems relatively inconsistent (e.g in my testing I've never managed to get it to sync, even after a full minute of clicking), so I wouldn't really consider it a real workaround (that's not to mention the lock-file per-click that gets created (and therefore synced)).

[TheZ3ro]

@5paceToast he is referring to KeePassX, originally it wasn't developed with syncing in mind. Now it's a requirement.

We are wrapping up features such as sync, auto-reload and auto-merge trying to make the sync process easy, transparent and multi-platform. The FAQ are fine

[CosmicToast]

Ah, ok. Thanks for clearing that up :)

[krizian]

@TheZ3ro @droidmonkey is the plan to keep the principle of using one file and copy features such as sync and auto-merge from Keepass, or would it be possible to create a real db with sync features like e.g. a sql db ?
In Keepass auto-reload was missing for daily multi-user use.
Thank you in advance! : )

[droidmonkey]

Will be worked on in conjunction with #1002

[sdidit]

It seems to me the problem is caused by the temporary file. If Google Drive starts to sync the temporary file before it is renamed, the rename will fail. I'm then left with a temporary file and no database file. The problem happens more often now that Google has updated their sync utility.

[droidmonkey]

Perhaps the temp file should be created in the tmp directory then moved into the appropriate location afterwards.

[sdidit]

It's more an issue of Backup and Sync. Other applications that create temporary files have the same problem with Google Drive. There's an option to ignore certain file extensions, but that only applies to the backup function, not the sync function.