Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.


#78 WebDAV deletion error


I often (i.e. 3 times out of 4) end up with the remote database being entirely deleted when using sync over a WebDAV connection. The Save function simply doesn't create anything. This isn't KeePass' fault as such, more likely down to the innumerable proxies and firewalls between me and the server.

Problem: In FileTransactionEx.cs function CommitWriteTransaction, it deletes an existing file if it exists. However, it doesn't check that the file it intends to rename exists. Suggest adding a simple test on line 99 which will at least leave the original file intact:

if (!IOConnection.FileExists(m_iocTemp))



Second, it seems that a simple delay is enough to make the file write to the WebDAV provider correctly. I don't like this answer, but I also don't have time to properly fault-find :( The delay must come *before* the CommonCleanUpWrite call. Specifically, before the "hashedStream.Close()" call in CommonWriteCleanup; having it between here and the subsequent sSaveTo.Close() doesn't work.

In Kdb4File.Write.cs, function Save, suggest adding something more elegant than this to the "finally" clause:

finally {
if (saving to web) { System.Threading.Thread.Sleep(1000); }
CommonCleanUpWrite(sSaveTo, hashedStream);



  • Will R
    Will R

    This is a problem I run into a lot when running KeePass under Mono. The Mono WebDAV implementation seems to be a lot slower, so it's much less tolerant of race/sequencing errors.

    I've implemented this patch naively and it seems to have the desired effect - if the temp file doesn't exist, sync/save fails with an error from a thrown exception (which I throw).

    One thing I did notice was the first few runs I got some type of threading dead-lock when it ran. At a guess, the threading deadlock might be adding an arbitrary delay in save seems to help getting all the data to the WebDav server.

    EDIT: The threading deadlock hasn't reoccurred in my time using this patch - I think it was an unrelated issue (Mono is touchy at times).

    Last edit: Will R 2013-10-19