I'm not sure if the above is controlled via the rclone --dir-cache-time flag (currently set to 24h), but I've noticed that uploads over the past 48 hours are not showing in nssm mounted folders and am unsure why that would be.
If I manually purge the local cache and let it rebuild, the changes will show immediately.
How do I ensure that any changes made to remotes via rclone are reflected on the nssm mount within an hour, if not immediately?
what version of rclone are you using?
what is the mount command?
Latest rclone - 1.5.1
Mount command is as follows:
mount --read-only --allow-other --buffer-size 0M --dir-cache-time 24h --drive-chunk-size 32M --vfs-read-chunk-size 32M --vfs-read-chunk-size-limit off --vfs-cache-mode writes --cache-workers=8 --cache-dir "C:\cache_vfs_gcrypt" --cache-db-path "C:\cache_vfs_gcrypt\gcache.db" --cache-chunk-path "C:\cache_vfs_gcrypt\gcache" gcrypt:/ X: --config "H:\rclone\rclone.conf"
Yes, I see the problem here I think...
I think you are confusing 2 flags here.
--dir-cache-time controls the VFS (mount) cache for directory-structure. This should never be on a higher timer than than the cache-backend's own cache for the same thing when you use that. (you are breaking this rule here in this setup).
--cache-info-age is probably the flag you meant to use. This controls the file and folder-structure cache for the cache backend (not the same as the VFS).
So in summary, to solve:
Then test again. I am fairly certain that will fix it
Many thanks as usual @thestigma
I modified the mount to
--cache-info-age 10m and sure enough, the files duly appeared after 10 minutes.
Can you see any downside to leaving the 'refresh' time at 10 minutes?
You can run a much longer --cache-info-age than that if you want...
The main limitation to be aware of is that a long cache timer can take a long time to detect changes that happened outside of this spesific cache. When you change some data the cache will simply take note of this and change it's cache data to reflect this immediately. However if another users, or another system that doesn't send it's data through this cache makes changes then this cache will be blind to those changes until it times out and actually does a hard recheck.
This basically means - for single users you can easily get away with using pretty extreme values because the cache should never become inaccurate anyway barring a bug. The benefit of that is much faster and snapper navigation and searches. The more data you get to cache before it expires the more complete it will be and the better it will work. This is the only downside to a lower timer.
But when you have other computers or parties uploading then you just have to set it to something reasonable depending on your need. In that case a few minutes sounds like it would be reasonable.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.