ghjebus

Thanks for putting that test case together! I can confirm that just running the CopyFile.exe fails when trying to copy to the gvfs mount but not to a direct smb mount or local file system. Even if the destination path contains a comma or colon. I'll throw a bug over in mono's court. Thanks for all the help! Edit: There was an eerily similar bug already in the mono github, so I added details from this test case to it. (https://github.com/dotnet/runtime/issues/96503).

Thanks for putting that test case together! I can confirm that just running the CopyFile.exe fails when trying to copy to the gvfs mount but not to a direct smb mount or local file system. Even if the destination path contains a comma or colon. I'll throw a bug over in mono's court. Thanks for all the help!

Looks like I'll have to find a workaround for this as it definitely seems to be an issue with Mono, gvfs/fuse, or the combination of the two. I sincerely appreciate all the help with trying to track this down! I should be able to get creative with fstab mounting only the KeePass dir and since those databases are owned by a specific user and password protected it should be safe enough. And that should allow transactions again. I might try to figure out how to compile C#/mono apps in linux or track...

Forgot to upload the sync failure on the symlink directory without a ":" in it. While it still fails, it does emit a different error than attempting to synchronize to the 'long form' directory. The result of the sync operation is a 0 size destination file.

Forgot to upload the sync failure on the symlink directory without a ":" in it. While it still fails, it does emit a different error than attempting to synchronize to the 'long form' directory.

Hi Dominik, Oops, that's my fault. I didn't realize I had to disable file transactions again! gvfs does support rename, I tested this with success (see attached). Do you know if, when transactions are disabled, a temp file is still created and renamed on save? Rename is atomic so it should be pretty much as safe as file transactions in this case. As for the synchronizing, that is the correct path and the database does exist. KeePass is able to open the .kdbx file via File -> Open -> Open File and...

Thanks for the quick turnaround! I'm attaching the results of the operations (sync and save-over-existing kdbx) on gvfs mounts. Sync does not end up changing the gvfs mounted version, and attempting to save over an existing file has the same reult with 0 file .kdbx and .kdbx.tmp file that can be renamed to a proper keepass database. Though that's probably expected if the only changes are for the error messages =) If you need me to test anything else or gather more data, please let me know!

All good, thanks for looking in to this!