Bug 425752

Any news here? Can I provide more information?

If you run KMM from command line, is there any more useful info output to the console?  My suspicion is a problem not in KMM itself, but in one of the underlying KDE IO routines.  Failing once, and then succeeding on a second try make me think of a timing issue.  Do you get the same issue saving to a local file?  Do you have any network shares other that cifs to test?  Also, do you have the same error if the file is NOT pgp encrypted?  You should be able to test with a newly created .kmy file, so you don't need to have unencrypted copies of your own data around.

Changing status

Running from command line the following messages are shown:

1st attempt so save (error)
---
GPG search "$HOME/.gnupg/secring.gpg"
Found
GPG Home directory $HOME/.gnupg
GPG filename /usr/bin/gpg
GPG search "$HOME/.gnupg/secring.gpg"
Found
GPG Home directory $HOME/.gnupg
GPG filename /usr/bin/gpg
QFileDevice::flush: No file engine. Is IODevice open?
Unable to write changes to: $NETWORKSHARE/testfile.kmy
Reason: Failure while writing to '$NETWORKSHARE/testfile.kmy' $GIT/kmymoney/kmymoney/plugins/xml/xmlstorage.cpp:552

2nd attempt to save (successful)
---
GPG search "$HOME/.gnupg/secring.gpg"
Found
GPG Home directory $HOME/.gnupg
GPG filename /usr/bin/gpg
GPG search "$HOME/.gnupg/secring.gpg"
Found
GPG Home directory $HOME/.gnupg
GPG filename /usr/bin/gpg
QFileDevice::flush: No file engine. Is IODevice open?

Even for the successful attempt the error/warning "QFileDevice::flush: No file engine. Is IODevice open?" is shown.

There is no error with:
- unencrypted file on network share
- local unencrypted file
- local encrypted file

The QFileDevice::flush is a warning, not an error, and my guess (which may be completely wrong) is that it is called when KMM closes the temporary output file it writes, before trying to copy it over the original.  

Is the $NETWORKSHARE literally what the error says, or did you substitute to not show your actual share name?  I don't know if it matters, but I'm wondering if on the first write attempt, the share is not mapped, so the write fails, but that write attempt causes the share to get mapped, so it works on a retry.

Question for the developers: looking at xmlstorage.cpp the comment above line 552 says QFile::rename will fail, but line 551 is "if (!QFile::remove(localFile) || !QFile::copy(writeFile, localFile))".  Should that remove be rename?  I don't see why the remove would fail, the first OR second try, so I'm confused either way.

Git commit 4d16fb2d1dab0a833425715091a909795d065466 by Thomas Baumgart.
Committed on 30/11/2020 at 11:39.
Pushed by tbaumgart into branch '5.1'.

Differentiate errors while writing data file

This is to get a bit more information about the cause of a failure
during a file save operation.

M  +6    -2    kmymoney/plugins/xml/xmlstorage.cpp

https://invent.kde.org/office/kmymoney/commit/4d16fb2d1dab0a833425715091a909795d065466

Git commit bbf1b4a9e35e4e93b8b5ff6816e05fa347d0cfd3 by Thomas Baumgart.
Committed on 06/12/2020 at 11:12.
Pushed by tbaumgart into branch 'master'.

Differentiate errors while writing data file

This is to get a bit more information about the cause of a failure
during a file save operation.

(cherry picked from commit 4d16fb2d1dab0a833425715091a909795d065466)

M  +6    -2    kmymoney/plugins/xml/xmlstorage.cpp

https://invent.kde.org/office/kmymoney/commit/bbf1b4a9e35e4e93b8b5ff6816e05fa347d0cfd3

Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!

As supposed $NETWORKSHARE is a substitution to not show my actual share name.

I don't think it is a problem with the mapping of a share because there is always a second try required. E.g.
1) Save attempt --> error
2) Save attempt OK
3) Quickly change something for a second or two
4) Save attempt --> error
5) Save attempt OK

With 5.1.1 the behaviour stays the same, but the message changed to:
"Failure while copying 'XYZ.kmy.wiTsQc' to 'XYZ.kmy' /kmymoney_git/kmymoney/kmymoney/plugins/xml/xmlstorage.cpp:555"

Thanks for the feedback. Now we see a bit better what is going on. KMyMoney at this stage removes the file 'XYZ.kmy' and then copies the temporary file to this location. For whatever reason, erasing the file works, but copying fails. The code can be found at https://invent.kde.org/office/kmymoney/-/blob/master/kmymoney/plugins/xml/xmlstorage.cpp#L539  The second time around, it does not use a temporary file but the real file right away and does not need to do the remove/copy magic because the file does not exist (anymore - was deleted in the first round). So I don't think it is a timing issue either. 

Looking at the code, I think it is not related to the encryption but should also happen with a regular file. 
@TobIs: Can you try this without encryption but using the same network environment?

Also with 5.1.1 there is no error with an unencrypted file within the same network folder.

I recently checked the output on the command line. Despite the line
"Reason: Failure while copying '$NETWORKSHARE/test_encrypt.kmy.JNpouf' to '$NETWORKSHARE/test_encrypt.kmy' $GIT/kmymoney/kmymoney/plugins/xml/xmlstorage.cpp:555"
it is the same as in comment 4.

Git commit 517f451e58ab5bd93d9590e4ce3c10a118f477ad by Thomas Baumgart.
Committed on 02/01/2021 at 15:26.
Pushed by tbaumgart into branch '5.1'.

Remove GPG context before accessing the file again

M  +7    -0    kmymoney/plugins/xml/xmlstorage.cpp

https://invent.kde.org/office/kmymoney/commit/517f451e58ab5bd93d9590e4ce3c10a118f477ad

@TobIs: can you try to run the version which will be created on the (European) morning of Jan 3rd (#881+) on https://binary-factory.kde.org/job/KMyMoney_Release_win64/ and see if that makes a difference? It should contain the change I just pushed with comment 12.

Thank you for looking into this issue and providing a patched binary.

But I'm using Kmymoney with Ubuntu, so I patched the xmlstorage.cpp by hand and compiled Kmymoney 5.1.1. Unfortunately this didn't solve the problem. The faulty behavior stays the same.

I'm not sure why Thomas might have thought you were on Windows, but see https://binary-factory.kde.org/job/KMyMoney_Nightly_Appimage_Build/ for the appimage build for linux, which you can just download, make executable, and run, no compiling needed.  I'm resetting the status based on your response