Writing to database synced via DAVx5 from Nextcloud results a 0 Byte file

[K4LCIFER]

Describe the bug

If you sync a database from Nextcloud over WebDAV using DAVx5, and subsequently write to that synced database using KeePassDX, the database will be overwritten with an empty (0 B) file of the same name.

To Reproduce

Steps to reproduce the behavior:

1. Sync a database from Nextcloud over WebDAV using DAVx5
2. Create a new item in KeePassDX
3. Observe that after saving, the database is overwritten with an empty file

Expected behavior

I expect it to be able to save without issue.

KeePass Database

• Created with: KeePassXC on Linux
• Version: I'm not sure how to find this
• Location: Remote file retrived from Nextcloud over WebDAV using DAVx5
• File provider ?
• Size: ~ 300 kB
• Contains attachment: no

KeePassDX:

• Version: 3.5.1
• Build: Google Play
• Language: English

Android:

• Device: Pixel 6
• Version: 14 beta

Additional context

This may be because KeePassDX doesn't save a temporary file before writing to the database. KeePassXC, for example, does have such an option:

[K4LCIFER]

Related: #1516, #1520, #1594,

[J-Jamet]

For #1520 and #1594, it's probably related. But #1516 has nothing to do with your problem, it's linked to the data merge system.

My first assumption is, if a file arrives at 0b, that it's simply because there was an unknown error during the writing process. So the question is, do you see an error displayed when this happens? Because normally the KeePassDX code simply sends the data to the write stream provided by the file provider of the file manager application. If this is not possible, an exception is raised and KeePassDX displays it. In this case, it's best to "Save a copy to ..." to save to another accessible URI. If no error is reported, this means that the file manager has judged that it's OK to write to the file, but in this case, maybe, it no longer has rights, because (maybe), a synchronization is performed in the background by another process. So, the data file is overwritten but not saved because it's not possible, but no exception is raised and KeePassDX has no way of knowing the error.

Maybe it's something else, but I can't see what. If anyone has another explanation, please let us know, and we might be able to solve the problem.

[J-Jamet]

This may be because KeePassDX doesn't save a temporary file before writing to the database. KeePassXC, for example, does have such an option:

KeePassDX don't write an external temporary file as it doesn't have permission to write to external storage, however there is the same concept in RAM before writing data to the URI, it's only destroyed when the database is closed but it doesn't matter if no exception was raised, because this means (theoretically, if the file manager does its job of raising exceptions correctly) that the file is well written.

[K4LCIFER]

So the question is, do you see an error displayed when this happens?

An error is not displayed, no.

[J-Jamet]

In this cqse it's problematic. We'd have to be able to reproduce the problem every time and check why there's no exception. If there is, we need to know why it's not reaching KeePassDX.

[K4LCIFER]

We'd have to be able to reproduce the problem every time and check why there's no exception.

I am able to trigger the overwrite of the file reliably. Everytime any write to the database occurs, it will overwrite with a 0B file.

[J-Jamet]

Reproducing it is already a good thing, now we need to understand why it's not written and why there are no exceptions.

[Max-Q]

I have the same problem. Interesting another app (AuthenticatorPro) also created an empty file. Could it have to do with this caveat (from the DAVx5 documentation): ... the app opens the file in read/write mode (which is currently not supported by WebDAV/DAVx⁵

[dumpfheimer]

I had a similar issues yesterday. I changed something, was prompted to touch my yubikey, which failed due to an unrelated issue. I (yes, my fault) then went on doing other stuff to get back to it later and noticed that in the mean time the database was corrupted and replaced by a 0 byte file.

While I recognize that my behavior was the origin of the mess, I would expect the database not to be corrupted.

How does the app handle Database writes?

Is KeePassDX using something like swap files? If not, would that be a possible solution? Or is it just the combination of KeePassDX and Nextcloud that is messing things up?

[J-Jamet]

There is no swap file system, as there is no actual file writing in KeePassDX. What is written is simply the URI exposed by the file provider. The contents of the database are stored in RAM while the database is open, and when a save is requested, the contents of the base are encrypted on the fly and sent to the stream.

In the case of the Yubiley, the encryption key must be rebuilt, as it changes every time the user uses it, so when the save is initialized, a thread takes over to asynchronously retrieve the key from the physical bundle.

I'm aware that there's still some behavior to be corrected when using the Yubikey driver, which is why it's still in beta. But if there's an exception before the backup, normally it doesn't change the provider file. As it's not KeePassDX that sends exceptions, it's the responsability of the file manager.

[dumpfheimer]

Thanks for getting back to me so quickly and for the detailed explanation, appreciate it.

I could have expected it to be more complicated than swapping a file ;-) I know Yubikey is in beta (even though it does not feel like it, mostly works like a charm), and I apologize if I sounded needy.

Also, thank you for your work. I would have not been able to migrate away from privacy-concerning password solutions withouth it.

If there is anything I can help with (testing or similar) let me know.

[J-Jamet]

I come back to the definition of this issue because the problem may not have been well identified at the start. Another bug #1666 prevents a database from being saved if it has been opened in read-only mode. Is this the case for you and does it work well if the database is open for writing?

[Max-Q]

When I had this problem, did NOT open the database in read-only mode or used save as.

Nov 4, 2023, 18:59 by @.***:

I come back to the definition of this issue because the problem may not have been well identified at the start. Another bug > #1666 https://github.com/Kunzisoft/KeePassDX/issues/1666> prevents a database from being saved if it has been opened in read-only mode. Is this the case for you and does it work well if the database is open for writing?

— Reply to this email directly, > view it on GitHub https://github.com/Kunzisoft/KeePassDX/issues/1620#issuecomment-1793508577> , or > unsubscribe https://github.com/notifications/unsubscribe-auth/AEJE5CMDQ5UMZRWK3CANAPDYCZ67VAVCNFSM6AAAAAA32MCIASVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOJTGUYDQNJXG4> . You are receiving this because you commented.> Message ID: > <Kunzisoft/KeePassDX/issues/1620/1793508577> @> github> .> com>

[DiagonalArg]

I've had the same problem of KeePassDX writing out a 0B database, when the back end is nextcloud via the nextcloud app (not davx5). I've had that problem in tandem with this one.

[J-Jamet]

Behavior has been improved with the cache displaying an error without trying to save the database, linked to https://github.com/Kunzisoft/KeePassDX/issues/1680