Deleting files on mount with VFS

[dennis_de]

Regardless of a specific version, I have noticed that even though VFS cache is enabled (full), when I delete files in the filesystem, the feedback does not run async. Is this possible to set via a parameter? Because the system always waits for the feedback from the remote, deletions take an eternity.

/usr/bin/rclone rcd \
  --config=/home/<obfuscated>/.config/rclone/rclone.conf \
  --rc-addr localhost:5572 \
  --rc-user <obfuscated> \
  --rc-pass <obfuscated> \
  --rc-enable-metrics \
  --rc-web-gui \
  --rc-web-gui-no-open-browser \
  --rc-web-gui-update \
  --log-file /var/log/rclone/data.log \
  --tpslimit 15 \
  --tpslimit-burst 15 \
  --transfers 16 \
  --checkers 16 \
  --use-mmap \
  --timeout 15s \
  --buffer-size 256M \
  --dropbox-batch-mode async

/usr/bin/rclone rc --rc-user <obfuscated> --rc-pass <obfuscated> mount/mount fs=dbx_fbx_storage_combined: mountPoint=/mnt/cloud/Data vfsOpt='{"CacheMode": 3, "CacheMaxAge": 60000000000, "WriteBack": 120000000000, "ChunkSize": "512M"}' mountOpt='{"AllowNonEmpty": true, "AllowOther": true,"AttrTimeout": 600000000000,"DirCacheTime": 86400000000000}'

Thank you in advance for your support.

[Animosity022]

No, there isn't a way to do that as that would lead to some unique situations.

[dennis_de]

In what ways would that be problematic? Would like to understand.

[Animosity022]

If you have a delete and it doesn't work on the backend for whatever reason, you'd be out of sync with the backend.

I delete a file, it fails for whatever reason, but I've already moved on and someone changes the file somewhere else, I would have a collision on what to do and figure out if I'm missing something.

You can always submit jobs async via remote control as well, but that wouldn't work on a mount.

Those jobs would run in the background until completion.

[dennis_de]

Okay, I understand that, of course. There needs to be more logic in the Core to deal with such situations/behavior before you would allow something like that to happen, of course. Thanks for the detailed explanation!