New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Saving DB fails intermittently on windows #197

Closed
mattvchandler opened this Issue Jan 25, 2017 · 36 comments

Comments

@mattvchandler

mattvchandler commented Jan 25, 2017

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\to\db.kdbx.<2 random? letters><PID>

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: 42c0815
  • Qt version 5.6.2
  • Compiler: gcc version 6.3.0 (Rev1, Built by MSYS2 project)
  • Operating System and version: Windows 7 SP1
@droidmonkey

This comment has been minimized.

Member

droidmonkey commented Jan 26, 2017

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

This comment has been minimized.

mattvchandler commented Jan 26, 2017

Originally created in KeepassX 0.4 imported into KeepassX 2.x

@mattvchandler

This comment has been minimized.

mattvchandler commented Jan 26, 2017

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

This comment has been minimized.

Member

droidmonkey commented Jan 26, 2017

No problems for me under Windows 10 64-bit

@droidmonkey droidmonkey added not reproducible and removed bug labels Jan 26, 2017

@dsbert

This comment has been minimized.

dsbert commented Jan 30, 2017

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

This comment has been minimized.

mattvchandler commented Jan 30, 2017

@droidmonkey

This comment has been minimized.

Member

droidmonkey commented Jan 30, 2017

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

@droidmonkey droidmonkey self-assigned this Jan 30, 2017

@phoerious

This comment has been minimized.

Member

phoerious commented Jan 30, 2017

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

@Dunkh4n

This comment has been minimized.

Dunkh4n commented Feb 27, 2017

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 :(

@phoerious phoerious added the bug label Feb 27, 2017

@dsbert

This comment has been minimized.

dsbert commented Mar 30, 2017

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

@droidmonkey

This comment has been minimized.

Member

droidmonkey commented Apr 3, 2017

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

This comment has been minimized.

dsbert commented Apr 3, 2017

@droidmonkey

This comment has been minimized.

Member

droidmonkey commented Apr 3, 2017

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.

@netforhack

This comment has been minimized.

netforhack commented Apr 9, 2017

The same issue, also what is this ?
image

@netforhack

This comment has been minimized.

netforhack commented Apr 11, 2017

@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

This comment has been minimized.

SemyonDragunov commented May 4, 2017

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

@tronjs

This comment has been minimized.

tronjs commented May 5, 2017

I have the same problem

@phoerious

This comment has been minimized.

Member

phoerious commented May 14, 2017

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

This comment has been minimized.

JaggedJax commented Jul 25, 2017

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

This comment has been minimized.

Member

droidmonkey commented Jul 26, 2017

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

@felixkopf

This comment has been minimized.

felixkopf commented Sep 2, 2017

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

This comment has been minimized.

tooor commented Sep 10, 2017

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

This comment has been minimized.

jask05 commented Sep 14, 2017

Hi,

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

Thanks!

@rockihack

This comment has been minimized.

Contributor

rockihack commented Sep 16, 2017

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

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

@snospar

This comment has been minimized.

snospar commented Sep 16, 2017

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.

@droidmonkey droidmonkey added this to the v2.3.0 milestone Oct 22, 2017

@andreas-profitlich

This comment has been minimized.

andreas-profitlich commented Nov 4, 2017

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

@krizian

This comment has been minimized.

krizian commented Nov 13, 2017

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

This comment has been minimized.

Member

droidmonkey commented Nov 13, 2017

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.

@5paceToast

This comment has been minimized.

5paceToast commented Nov 13, 2017

@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

This comment has been minimized.

Member

TheZ3ro commented Nov 13, 2017

@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

@5paceToast

This comment has been minimized.

5paceToast commented Nov 13, 2017

Ah, ok. Thanks for clearing that up :)

@krizian

This comment has been minimized.

krizian commented Nov 14, 2017

@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

This comment has been minimized.

Member

droidmonkey commented Nov 20, 2017

Will be worked on in conjunction with #1002

@sdidit

This comment has been minimized.

sdidit commented Dec 13, 2017

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

This comment has been minimized.

Member

droidmonkey commented Dec 13, 2017

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

@sdidit

This comment has been minimized.

sdidit commented Dec 13, 2017

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment