Folder not updating when a file is moved/deleted

[Snowflake6]

I noticed this while using Obsidian, but then tried it in Nautilus and found the same thing.

In Obsidian: When I try to move a file from one folder to another, the file disappears from the source location but never shows up in the destination. If I look in Nautilus, the file is still in the source location, with a hex code added to the filename in brackets. ie.
20220610.md ==> 20220610 (1945a57e).md

If I try to move the file within Nautilus, a second hex code is added. This seems to have changed within the last couple of days for some reason. Any suggestions where to start? I tried looking for logs but didn't find anything ocaml-fuse specific... I may not be looking in the right place though so guidance is welcome. I can add logs to this issue if any would be useful.

Ubuntu 22.04
Obsidian 0.4.15
google-drive-ocamlfuse 0.7.28-0ubuntu2

[Snowflake6]

Updates:

1. It appears that if I reboot, the issue is resolved by the time I get to a desktop and open a Nautilus window. So it appears like something isn't triggering google-drive-ocamlfuse to do the update when a change is made.
2. Existing files can be edited, saved, and re-opened without issue. It's just moving/deleting that doesn't happen until a reboot.

[jnordberg]

I have the same issue on Ubuntu 20.04. Have you found any workaround? This bug is very frustrating

[jnordberg]

Attaching debug log and steps to reproduce, it seems to be related to images somehow, I cannot reproduce using a .txt file. Remounting with -cc does not help.

$ mv /drive/testdir/artwork/0025.png /drive/testdir/test123.png
$ ls /drive/testdir/test123.png
ls: cannot access '/drive/testdir/test123.png': No such file or directory
$ ls /drive/testdir/artwork/0025.png
ls: cannot access '/drive/testdir/artwork/0025.png': No such file or directory

debug.log

[Snowflake6]

@jnordberg No, no solution found. And since I can't work with this instability, i'm reverting to InSync until I can figure out another solution.

[astrada]

Thanks for reporting (and thanks @jnordberg for the logs)! Should be fixed in version 0.7.30 that I'm publishing now on the beta channel and on opam.