If you are making data for me, then I would like the timespan between stopping and starting to me minimal, just enough to do the lsl command - and please remember to make it a continuous log.
I'd just start a new mount / new location / make a single file test and be done with it as I like to reduce variables.
That is also my next step, after seeing that we actually do have an rclone related issue and not something else going on. And then I have an additional experiment in the backhand to check anything (presumably not uploaded) remaining in the cache.
Ok, so I'm going to assume its some weird issue with either the vfsmeta or the cache folder in general, because changing the cache folder and uploading one of the problematic files, once its finished the file gets evicted correctly
What I don't get is what would cause it to only affect non-english filenames?
Are you going to provide the data I asked for - or can I leave this thread?
I haven't had a chance to upload it yet, its been only a minute....
Then I suggest yo focus on that and wait with all the questions and speculations. Let's get some facts to talk from!
before gist:928876aaab08c9957c5dc94ea0fd99b0 · GitHub
after gist:bb0de1407b04dc3c7ee780b28df4cf50 · GitHub
Thanks!
I don't see any issues with the cache cleaning of the Japanese filename, do you? where?
I am however not quite sure why the file "TeraCopyTestFile-1234567890" reappears in the after log, could you please do this to check if it was indeed cleaned:
rclone lsl "Z:/rclonetest/vfs/archiveenc/"
Like I said, I think the cache not clearing is a result of some malformation with the previous cache directory or its metadata, because the new cache location is completely empty under the remote folder
The TeraCopy* file is TeraCopy checking if the directory is writable, it appears twice because it writes it at the start of the transfer, and then deletes it once the transfer is done or at some point after the transfer has proceeded
That could well be the case.
I suggest you keep tuning parameters at a minimum, that will keep you on the more walked/tested part of the road.
And I really wouldn't change --attr-timeout unless having a very specific reason and understanding the full consequences (which I don't).
The reason I had it set is because I am the only one other than google themselves that has access to the drive, and it helps limit the amount of time spent waiting for rclone to waste time checking for changes that as far as I understand cant have changed outside of what rclone would already know about
Then you should just increase --dir-cache-time, that will keep rclone from asking the remote for a fresh directory listing. The default is 5m and it can easily be increased to 5h like you had before. That is much safer.
More info here:
https://rclone.org/commands/rclone_mount/#attribute-caching
https://rclone.org/commands/rclone_mount/#vfs-directory-cache
Ok, thanks for the help
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.