That is when it starts.
Looks to be viable around here.
You've only included a snippet of the log though if it's problematic after that so it's a guessing game.
Yes because its a very very long log file, and there is lots of duplication, the only difference is a different file is entered into the upload queue.
That would cause a delay but without seeing the log, we just guess.
If you want to include a usable log here, that is how we can help identify the issue.
Ok well where would you like the log to stop? As the log file keeps filling up until I presume all the files in the upload dir have entered the queue, at which point I guess the mount point would appear? This takes hours as it seems to be uploading files as they enter the queue, this slows it down significantly so I believe it's waiting for the upload queue to be empty before it shows the mount point. If that is the case the mount point isn't likely to appear for approx a week at a guess, and the log file will continue to grow for that amount of time also.
If you share the full log, that's helps the most.
I understand that it helps the most, but the log I posted above that file is 15gb in size, and the gui says it's going to take 17 hours to upload, which is fine but obviously I have an issue with the mount point not showing up, and would ideally like the mount point to show up before the 17 hours is up, there is several other files after this one with varying sizes, so it's going to be a very long wait to get a full log to you and my issue resolved it appears.
You can zip it up before you upload it somewhere.
You can make a Google Drive link to it.
You can make a One Drive link to it.
You can share it any myriad of ways that is easier / best for you.
If you want an answer and help, a full log file is needed.
If it doesn't matter to you why, you can just mark it solved and that's that.
No you misunderstand, the providing the log is not the problem.
The problem is the amount of physical time that will have passed to get you a full log.
As I said the first file in the upload queue will take 17 hours to upload, and the files after this I don't know how long they will take to upload.
So if I can't get a full log to you for over a week? that means I just have to have a non working mount for that amount of time, does that make sense what I am trying to explain?
If you have a large set of files in your upload queue, the mount doesn't become active until the queue is cleaned out so I'd assume you stopped the mount before things cleared out.
By providing the full log in the first post, we would have arrived at that answer after the first post. Since you only gave a brief snippet in the first post, we spent some time trying to get a picture of what's going on.
So if you provide the current full log, we can show you what's going on based on the log.
@ncw Is there a reason for that? No not stopped as such, more of Windows decided it wanted to do an update and the machine rebooted whilst I was sleeping.
That's all that was in the log at the point of making the post I couldn't give you more at the time, but I did state there was a large upload queue.
Confused, I have looked at the log and can see that files are uploading, there isn't much else going on. Confused as to why there is a delay in the mount becoming active just because there is an upload queue.
Still no log file?
Getting into a catch-22 here. If you share the log, I can show you.
hello,
some of these flags do nothing, based on your config
--cache-db-path
-cache-tmp-upload-path
to simply testing, remove all the flags and test with a simple command such as rclone.exe mount gdrive: Z:
if it works well, then add more flags, test and repeat until the delay happens, and then you will know which flag is causing the delay.
if the command still has the delay, then continue to diagnose the problem with that simple command.
The issue isn't any flags, it's the upload queue that has to be processed.
That is shown in the logs..
Not sure your internet stats, but the transfers being at 1 only allows 1 transfer at a time so that will slow things down.
You got files queued up to upload as you'll see a bunch of these in your log:
2021/03/06 12:18:27 DEBUG : ***REDACTED***: vfs cache: delaying writeback as --transfers exceeded
You can do a count since the file names are all redacted.
It's trying to empty the queue before it returns the mount.
What's the size of your backlog?
I did that as I didn't want the uploads to take up all the transactions and leave too few for reading, so I thought I would just do 1 at a time and as I am in rush for the files to be uploaded.
How would I check that ?
There is 67 files in the upload folder, there is more in the vfs folder but I believe thats the cache.
The VFS cache doesn't behave like that - it will upload things in the background while running the mount. However things won't get uploaded until the queue is clear.
@ncw Doesn't behave like what? Sorry I am lost as to what "that" is referring to.
Why can't the mount becoming active and for it to then do the uploading from the queue? instead of the opposite?
I was referring to "If you have a large set of files in your upload queue, the mount doesn't become active until the queue is cleaned out "
I'm saying the mount doesn't behave like that. It will become active, then upload things from its queue. At least that is what it does in my tests!
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.