Opening database and then trying to save the database again to the same local location.
Cannot get past the error and corruption occurs, as the file seems to disappear??
Edit: Deleting the db and trying to re-create cause the error again and the new db dialog to keep askig me for the new db filename.
db Argon 2 (KDBX4)
KeePassXC - 2.3rc1 AppImage and 2.3 git
Revision: snapshot 220218
Libraries:
Operating system: Arch Linux
CPU architecture: x64
Kernel: 4.15.3-2
Enabled extensions:
Do you have the "Safe saves" option enabled?
Yes I do, but after enabling save on every change and on exit things have settled down a little.
I was in a frustrating loop of not being able to save or quit the app, but now things are behaving.
I am using nextcloud to sync the db and it seems to be syncing correctly now too, so I see the changes on the other machines.
One thing I did change previously that I haven't now is the database name in the db metadata settings menu, which previously I was changing to the same name as the database file and am not sure if that was causing an issue too?
The database name should have nothing to do with file saving trouble.
If the problem occurs again, can you try disabling Safe saves? It shouldn't be causing an issues on Linux, though.
Yes will do.
I had done a fsck on my disk and no issues were found either.
Ok so it happened again this morning and I had turned that option off. I re-enabled it and the message went away and the dB was saved fine.
I am using a dB on a local nextcloud folder that the NC client then syncs.
I am still trying to understand how things are working myself so appreciate this may not be much help.
I will keep monitoring the situation.
The same thing happens to me on the latest snapshot (installed from AUR on Arch Linux) with safe saving disabled. Databases just get deleted when I attempt to save changes.
Clean config, only the safe saving option is turned off.
I can't even create a database, I get the "Writing the database failed, Invalid cross-device link" error. That error prevents the program from closing while printing this in the console on every attempt:
QFileSystemWatcher::addPath: path is empty
QFile::copy: Empty or null file name
QFile::remove: Empty or null file name
QFileSystemWatcher::addPath: path is empty
QFile::copy: Empty or null file name
QFile::remove: Empty or null file name
...
If "backup before saving" option is enabled, then it creates a snapshot named with a double extension, like this: My_DB.old.kdbx.old.kdbx
Everything is fine in the safe saving mode, but I can't use that mode for syncing reasons.
Can't wait for 2.3 to hit stable, looks like it's going to be a great release!
Thanks @Busimus Thats the same as I had, but I thought I was seeing things with the archive being deleted.
Do you have the file on a specific mounted volume? Could you post the output of mount and tell me in which directory (or at least which volume) you have your database file, please?
@Busimus what do you mean by "syncing reasons"?
I tried to reproduce the described behavior, but couldn't, no matter what I tried.
QFileSystemWatcher looks like auto-reload is involved. Does the problem still occur if you turn that off?
After a few hours of debugging, it turned out to be a Qt bug: QTBUG-64008.
The bad news is that the issue has been closed, but the problem persists in a slightly different way.
@phoerious try running this code with a path as an argument:
#include <QTemporaryFile>
#include <QtDebug>
#include <QtGlobal>
#include <QSysInfo>
int main(int argc, char *argv[]) {
qDebug() << "compiled against Qt" << QT_VERSION_STR;
qDebug() << "running with Qt" << qVersion();
qDebug() << "running on" << QSysInfo::kernelType() << QSysInfo::kernelVersion();
QTemporaryFile file;
Q_ASSERT(file.open());
Q_ASSERT(file.write("Important stuff"));
Q_ASSERT(file.rename(argv[1]));
return 0;
}
For me, specifying any path except for /tmp/... makes the last assert fire:
$ ./QTempFile_test /home/user/testfile
compiled against Qt 5.10.1
running with Qt 5.10.1
running on "linux" "4.15.5-1-ARCH"
ASSERT: "file.rename(argv[1])" in file ../QTempFile_test/main.cpp, line 14
Seems to only happen on 5.10 Qt versions, but I'm not sure.
As a temporary workaround, writing tempFile.copy(filePath) instead of .rename(filePath) on this line worked for me and it basically achieves the same result (if you remove the tempFile.setAutoRemove(false) call that happens upon successful copy).
Okay, so this only happens when safe saves is off?
This is really peculiar. We developed a workaround for a bug and all Qt say is "hold my beer..."
Yes, because only unsafe save mode utilizes QTemporaryFile.
Okay, I'll make a fix. Just in time for the release.
Alright, at home I can reproduce it. At work I couldn't.
The problem with copying is that it's never atomic. Renaming is atomic at least when done within the same volume. Since this is a Linux-only bug, I could make the fix Linux-only.