google-drive-ocamlfuse icon indicating copy to clipboard operation
google-drive-ocamlfuse copied to clipboard

renaming or deleting files locally from bash cause weird renaming issues

Open pyron83 opened this issue 3 years ago • 1 comments

the issue started a few months ago, discovered it by accident while renaming some files on my Google Drive.


system: xubuntu 20.04.03 google-drive-ocamlfuse, version 0.7.27


Example: cd GoogleDrive/ mv file1 file2

  • expected result: file2
  • actual result: file1 (bc57158f), file2 doesn't exist

the same happens also when deleting or moving files to other locations of my GoogleDrive

if I do the same with a newly created file (like 'touch test1' and 'mv test1 test2' the issue doesn't happens)

The weird thing is that, if I open my Drive from webapp, files are renamed and moved correctly. So in the example above, "file1" will disappear from my Drive and file2 will take its place, like it should.

I tried to wait some times to see if it was a "caching" issue, but after many hours files are still the same, at least locally.


Things I tried:

  • deleting my .gdfuse/cache
  • resetting .gdfuse/config to default

until now, none of it worked

pyron83 avatar Jan 25 '22 10:01 pyron83

I also encountered the same issue yesterday when I tried to locally delete a file.


system: ubuntu 20.04.3 LTS google-drive-ocamlfuse, version 0.7.27


How I discovered it: I tried to move and delete a bunch of files from my Obsidian vault (it should just move / delete markdown files, it worked well for one year before I encountered this issue).

Other encounters:

  • Using bash commands (moving / deleting)
  • Using Unison to sync a local file with a file in my mounted drive

Example with Obsidian:

  • I create file1 and file2 in folder_a
  • I edit file1 and file2 --> no problems
  • I drag and drop file1 in folder_b --> the file disappears. When I restart Obsidian, I find file1 (175bsw20) in folder_a and folder_b is still empty
  • I delete file2. When I restart Obsidian, I find file2 (9e4bo054) still in folder_a

Example with Unison: I have a local folder I want to sync with a folder in the Google Drive mounted drive. Mounted: action done in the mounted drive folder Local: action done in the local folder

  • Mounted: I create created_from_mounted folder

  • Unison doesn't detect the new folder

  • Local: I create created_from_local folder

  • Unison detects and syncs the new folder

  • Local: I create created_from_local_deleted_from_local

  • Unison detects and syncs the new folder

  • Local: I delete created_from_local_deleted_from_local

  • Unison detects the deletion and also deletes the folder in the mounted drive

  • Local: I create created_from_local_deleted_from_mounted

  • Unison detects and syncs the new folder

  • Mounted: I delete created_from_local_deleted_from_mounted

  • Unison detects the deletion and also deletes the folder in the local drive

  • I start an Unison check again --> found:

    • created_from_mounted (128bdc14)
    • created_from_local_deleted_from_mounted (9e4be067)
    • created_from_mounted (the file created at the very beginning which wasn't detected until now) ocamlfuse_bug_01
  • Starting Unison sync

  • The filed mentioned above are added to the local file, but nowhere to be seen in the mounted drive

  • Another unison check --> everything is up to date

ocamlfuse_bug_03


Things I tried:

  • deleting my .gdfuse/cache
  • resetting .gdfuse/config to default
  • reinstalling google-drive-ocamlfuse
  • config delete_forever_in_trash_folder=true
  • config disable_trash=true
  • manually deleting the trash folder from Google Drive --> sometimes it made these weird named files disappear from the mounted drive (not visibles in Obsidian anymore)

Same for me, except for some lucky trash deletion from time to time, nothing worked.

GradelerM avatar Feb 03 '22 10:02 GradelerM