Where H: is a USB drive. I have tried setting the backup.path to a directory on the C: drive just to see it that mad any difference, it does not.
The first time I attempt to save the database after starting the program a file named Database.kdb.tmp is created in the H:\KeePassDB\ folder, the following error is displayed:
Backup of 'C:\Users\thisUser\Keepass\Database.kdb' to
'H:\KeePassDB\Database.kdb’ failed.
The handle is invalid.
and backups are disabled.
The next time that I start KeePass the Database.kdb file in the H:\KeePassDB\ folder is deleted and the Database.kdb.tmp file is renamed Database.kdb.
I am baffled by the occurrence of this error. Prior to switching to Windows 10 backups with this command line worked without a problem, I believe that initially it worked on Windows 10 in releases prior to 1809, but I am not absolutely certain.
All the information that I have been able to find on the Web about the 'handle is invalid' error indicates that it occurs when a file or folder is being deleted or renamed, and that it involves the use of specific keywords in the file/folder name. That does not seem to be the case here, unless ABP is including a reserved keyword in the name internally but not reporting it in the error message.
I have used ABP for many years and would like to continue to use it in the future but this error is preventing it from being used properly.
Thank you,
J C Bingham
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Short Answer: Based on your description, and my assumption that the problem is a Windows 10 bug, a temporary workaround is to replace ABP 1.12 with ABP 1.11.
Long Answer: In all releases of ABP before 1.12, the backup file is written directly on top of any previous backup file to the same directory. This means that the old backup file is effectively deleted as soon as ABP begins writing the new one. With this simple design, there is a risk that if ABP never finishes writing the new backup file (such as if the computer loses power, the operating system crashes, etc.) then no usable backup file will remain in that directory. This outcome is worse than if ABP did not run.
To mitigate this risk, ABP 1.12 introduced a more robust – but regrettably more complex – design: Whenever an old backup file already exists, ABP writes the new backup file to a temporary filename in the same directory, instead of writing directly on top of the old one. It then deletes the old backup file and renames the temporary file to it. With this new design, the risk is not entirely eliminated, because a crash occurring before the delete or the rename will still result in an unsatisfactory state. However, at least the new backup file will be present in the desired directory (though under a temporary name), so recovery is possible. In your scenario ABP indeed recovers to the desired state the next time KeePass is invoked. This outcome may be better than in previous releases, where no usable backup file remains. Also, with the 1.12 design, the time interval of vulnerability (between delete and rename) should be shorter, especially when database files are large.
In your case, ABP apparently failed while attempting to delete the old backup file or rename the temporary file. Previous versions of ABP do not delete or rename files, so they should work fine, albeit at the risk of destroying the old backup file without replacing it.
If my assumption is correct that this is indeed a Windows 10 bug, it may be fixed in the future, restoring your ability to use ABP 1.12 once again. However, the Windows 10 bug may have damaged your machine so that ABP 1.12 won't work correctly even after Windows 10 is fixed. You may need to undo this damage to your machine before ABP 1.12 can work again.
Thanks so much you for your inquiry – just days before the tenth anniversary of ABP's latest release. I'm glad you're finding ABP useful. Please post here to say whether this note resolves your problem.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you for your response.
Your explanation seems reasonable, except that I do not understand how ABP can successfully delete the old backup file and rename the temporarry file on startup, yet cannot do the same thing immediately following the creation of the temporary file.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Good point! Investigating the situation more deeply, I found the following:
The ABP code path that causes successful deletion and renaming is the same code path with the same parameters as that which causes the invalid handle response.
ABP has no code for deletion or renaming. Instead, ABP calls back to KeePass through the plugin interface to perform these functions.
The deletion and renaming is encapsulated in a single plugin interface function called IKpFileTransaction::CommitWrite().
Based on your description, it appears to me that it is in the CommitWrite() function of KeePass that the failure occurs. This could still be a Windows 10 bug.
However, I now see that it might instead be a bug in KeePass. To test this latter possibility, could you do the following: Do not revert ABP, but instead revert KeePass to a release that you know has worked correctly with ABP. If you still get the invalid handle bug, then this appears to be a Windows 10 bug. But if the problem disappears, then KeePass 1.37 may be at fault. Either way, it might be possible for Dominik to find a workaround, but let's first diagnose the problem more precisely.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am using KeePass 1.37 with ABP 1.12 on a Windows 10 system running the 1903 release, but this problem also occurs on the 1809 release.
I start KeePass with a shortcut containing the command line:
"C:\Program Files (x86)\KeePass Password Safe\KeePass.exe" C:\Users\thisUser\Keepass\Database.kdb /backup.path:"H:\KeePassDB\"
Where H: is a USB drive. I have tried setting the backup.path to a directory on the C: drive just to see it that mad any difference, it does not.
The first time I attempt to save the database after starting the program a file named Database.kdb.tmp is created in the H:\KeePassDB\ folder, the following error is displayed:
Backup of 'C:\Users\thisUser\Keepass\Database.kdb' to
'H:\KeePassDB\Database.kdb’ failed.
The handle is invalid.
and backups are disabled.
The next time that I start KeePass the Database.kdb file in the H:\KeePassDB\ folder is deleted and the Database.kdb.tmp file is renamed Database.kdb.
I am baffled by the occurrence of this error. Prior to switching to Windows 10 backups with this command line worked without a problem, I believe that initially it worked on Windows 10 in releases prior to 1809, but I am not absolutely certain.
All the information that I have been able to find on the Web about the 'handle is invalid' error indicates that it occurs when a file or folder is being deleted or renamed, and that it involves the use of specific keywords in the file/folder name. That does not seem to be the case here, unless ABP is including a reserved keyword in the name internally but not reporting it in the error message.
I have used ABP for many years and would like to continue to use it in the future but this error is preventing it from being used properly.
Thank you,
J C Bingham
Short Answer: Based on your description, and my assumption that the problem is a Windows 10 bug, a temporary workaround is to replace ABP 1.12 with ABP 1.11.
Long Answer: In all releases of ABP before 1.12, the backup file is written directly on top of any previous backup file to the same directory. This means that the old backup file is effectively deleted as soon as ABP begins writing the new one. With this simple design, there is a risk that if ABP never finishes writing the new backup file (such as if the computer loses power, the operating system crashes, etc.) then no usable backup file will remain in that directory. This outcome is worse than if ABP did not run.
To mitigate this risk, ABP 1.12 introduced a more robust – but regrettably more complex – design: Whenever an old backup file already exists, ABP writes the new backup file to a temporary filename in the same directory, instead of writing directly on top of the old one. It then deletes the old backup file and renames the temporary file to it. With this new design, the risk is not entirely eliminated, because a crash occurring before the delete or the rename will still result in an unsatisfactory state. However, at least the new backup file will be present in the desired directory (though under a temporary name), so recovery is possible. In your scenario ABP indeed recovers to the desired state the next time KeePass is invoked. This outcome may be better than in previous releases, where no usable backup file remains. Also, with the 1.12 design, the time interval of vulnerability (between delete and rename) should be shorter, especially when database files are large.
In your case, ABP apparently failed while attempting to delete the old backup file or rename the temporary file. Previous versions of ABP do not delete or rename files, so they should work fine, albeit at the risk of destroying the old backup file without replacing it.
If my assumption is correct that this is indeed a Windows 10 bug, it may be fixed in the future, restoring your ability to use ABP 1.12 once again. However, the Windows 10 bug may have damaged your machine so that ABP 1.12 won't work correctly even after Windows 10 is fixed. You may need to undo this damage to your machine before ABP 1.12 can work again.
Thanks so much you for your inquiry – just days before the tenth anniversary of ABP's latest release. I'm glad you're finding ABP useful. Please post here to say whether this note resolves your problem.
Thank you for your response.
Your explanation seems reasonable, except that I do not understand how ABP can successfully delete the old backup file and rename the temporarry file on startup, yet cannot do the same thing immediately following the creation of the temporary file.
Good point! Investigating the situation more deeply, I found the following:
Based on your description, it appears to me that it is in the CommitWrite() function of KeePass that the failure occurs. This could still be a Windows 10 bug.
However, I now see that it might instead be a bug in KeePass. To test this latter possibility, could you do the following: Do not revert ABP, but instead revert KeePass to a release that you know has worked correctly with ABP. If you still get the invalid handle bug, then this appears to be a Windows 10 bug. But if the problem disappears, then KeePass 1.37 may be at fault. Either way, it might be possible for Dominik to find a workaround, but let's first diagnose the problem more precisely.