Skip to content
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 · Fixed by #1385
Closed

Saving DB fails intermittently on windows #197

mattvchandler opened this issue Jan 25, 2017 · 36 comments · Fixed by #1385

Comments

@mattvchandler
Copy link

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
Copy link
Member

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
Copy link
Author

mattvchandler commented Jan 26, 2017

Originally created in KeepassX 0.4 imported into KeepassX 2.x

@mattvchandler
Copy link
Author

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
Copy link
Member

No problems for me under Windows 10 64-bit

@dsbert
Copy link

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
Copy link
Author

mattvchandler commented Jan 30, 2017 via email

@droidmonkey
Copy link
Member

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

@phoerious
Copy link
Member

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

@Dunkh4n
Copy link

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
Copy link

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
Copy link
Member

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
Copy link

dsbert commented Apr 3, 2017 via email

@droidmonkey
Copy link
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.

@ghost
Copy link

ghost commented Apr 9, 2017

The same issue, also what is this ?
image

@ghost
Copy link

ghost 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
Copy link

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
Copy link

tronjs commented May 5, 2017

I have the same problem

@phoerious
Copy link
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
Copy link

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
Copy link
Member

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

@felixkopf
Copy link

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
Copy link

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
Copy link

jask05 commented Sep 14, 2017

Hi,

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

Thanks!

@rockihack
Copy link
Contributor

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

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

@snospar
Copy link

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
Copy link

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

@krizian
Copy link

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
Copy link
Member

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
Copy link

@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
Copy link
Contributor

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

@CosmicToast
Copy link

Ah, ok. Thanks for clearing that up :)

@krizian
Copy link

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
Copy link
Member

Will be worked on in conjunction with #1002

@sdidit
Copy link

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
Copy link
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
Copy link

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
Projects
None yet
Development

Successfully merging a pull request may close this issue.