I'm using Rclone to migrate files on Google Shared Drive since several months and it works perfectly.
But since the path week, when my migration is done and items are well migrated (no error on log) I can not see files or folders on my shared drive. It's weird because on some Shared Drive there is no issue...
I can see files on ''quick access'' or I can have an access through the search bar but nothing is visible. And I need to wait several hours (or days) to finally see files on it.
Do you have the same issue ? And if yes do you know the reason of the delay ?
I would check that it's not due to one of the more common limitations before proceeding.
(1) - Check that it's not due to the VFS cache having out-of-date info. This can happen when the data is uploaded from another source outside of the VFS you view it though. Your settings for
--attr-timeout
--dir-cache-time
--pol-interval
are all relevant to that (and feel free to share these with us). The easiest way to assure this is not the problem is to either run an "rc vfs/refresh" (if you use remote), or simply restart the mount. Assuming you are viewing it through a mount at all that is - if not the VFS system and it's caching is not relevant.
(2) Make sure it's not just fast-list lagging behind. I think this is a known issue related to file-lists being in some sort of cache-system on Google's side - so when you fast-list right after a large transfer you may get inaccurate results (some files can appear to be missing even if they aren't). As far as I know the regular listing method is not vulnerable to this (don't take that as gospel), so reverting to regular listing for the purpose of testing may be a way to confirm this.
In my experience the fast-list lag has never been severe - usually only a matter of a handful of minutes, but I would not be surprised at all if this could take more time if it's a really huge transfer (something I have not really done yet myself) and/or if the Google system is experiencing a heavy load at the moment. Google has a lot of load-balancing systems like this where non-critical tasks can be de-prioritized as needed. The rate at which these caching systems get updated very likely fall into that category.
I'm not sure if the polling system (only relevant to mount) may perhaps be able to pick up these changes quicker. I have not tested this extensively. It could be worth trying though, by setting your polling itnerval to something reasonably low and see if that effectively mitigates the issue. It may be affected by exactly the same problem that fast-list has though.
Ultimately this phenomenon may not be properly fixable as it's definitely due to systems on Google's end - but if your need is sufficiently great the regular (much slower) listing method may be a workaround. Most importantly, this is not indicative of a serious problem. The files are there - and they all do show up with time. It's only really an issue in timing-sensitive scenarios.