Gcrpyt Mount hangs while opening folder

It already does fast-list with the call so there is no need to use it.

From what I understand this is correct. It should be superfluous. It's just a remnant of my testing where I "wanted to make extra sure". It won't do any harm, but it shouldn't make any difference either.

And the timeout is also something you probably don't need. Just another thing I added for testing when I experimented. This does do something, but normally you should not time out unless you are doing something weird (which I was at the time).

All right so it does not make any difference then. Thanks!

So these are the final scrips I am using then:
Mount script:

@echo off
::Variables
set driveletter=E
set remotename=gcrypt
set RCport=5572

start /b rclone mount %remotename%: %driveletter%: --allow-other --attr-timeout 1000h --log-level INFO --log-file D:\rclone\logs\mount.log --buffer-size 128M --dir-cache-time 1000h --poll-interval 15s --timeout 1h --rc

::Start cache warmup
call VFSCacheWarmup.bat %driveletter% %RCport%

VFSCacheWarmup script:

@echo off
::Variables
set driveletter=%1
set RCport=%2

:: Check that the folder is valid, otherwise wait until it is
echo Waiting for %driveletter%: to be ready ...

:LOOP1
vol %driveletter%: >nul 2>nul
if errorlevel 1 (
echo " "| set /p dummyName=.
timeout /t 1 > nul
goto LOOP1
) else (
echo Drive %driveletter%: OK!,
)

echo You may use the cloud-drive normally while the cache is being warmed up
echo Awaiting completion-message from RC...
rclone rc vfs/refresh recursive=true --rc-addr localhost:%RCport%
echo Cache warmup for %driveletter%: OK!

Everything is ok here right ?

Looks good to me. Can't see any obvious mistakes. If there are any, it would be simple syntax error which should be easy to find from any errors you might get when you run it.

My only note:
--timeout 1h
is probably not needed either.

The only reason I have found to use this in the mount is if you need to transfer very large files through the mount (such that the mount "stalls" for a long time due to the transfer time on an individual file). If this happens you could get an IO error from Windows because it assumed it's time to give up waiting for a reply. I think the default is 10 minutes. It can be useful - but I'd just keep it in mind for later and add it if you actually see a problem rather than running it from the start. It's up to you though - it shouldn't cause much trouble, but it's nice to know what it's actually for at least.

The script is running fine! Okay I will keep the timeout thing in mind!
One small question, I like to keep the script output as clean as possible. Do you know how to prevent the cmd output from showing this:

{
"result": {
"": "OK"
}
}

Hmmm, try adding
-q (quiet, opposite of verbose - no output)
This works for normal rclone commands, so I imagine they would work for RC commands too.

rclone rc vfs/refresh recursive=true --rc-addr localhost:%RCport% -q

The main reason I did not do this myself was that my "OK" does not actually check that the operation was successful. It can fail - due to error or timeout. It shouldn't normally though.

Maybe run it with output for a little while until you see that it works reliably, then remove it when you trust it to work every time without the explicit confirmation :slight_smile:

A better scripter than I could probably take the output from that command simplify it to not take so much space. It's probably simple, but I am still a batch noob in training :stuck_out_tongue_winking_eye: Maybe I will look into improving it later.

EDIT: what you can alternatively do is use "start" instead of "call" on the cacheWarmup. That will open a new window that contains all the warmup stuff - but that can auto-close when done - leaving your mount window nice and clean. Maybe you prefer that?

Later on you can run all this stuff completely silent as a system service if you want - but it's nice to be truly comfortable that everything is working great before you make it all "invisible" as it's less easy to get feedback on what is happening.

-q does not make any difference. But you are right I should use it as it is for a while atleast. Meanwhile I will try to do some research on batch scripts and maybe be able to use that output and display it more elegantly. I can see that it is in json format, so maybe I can extract the output to a json file and then import it as I wish. I know how to do this in python but with batch scripts I have no clue :rofl:

If -q does not work, then put this at the very end of the command:

rclone rc vfs/refresh recursive=true --rc-addr localhost:%RCport% >nul

This is the general batch redirection of output so it will work for anything (not just rclone, anything in command-prompt). It basically means "take the output, and send it to ... well ... nothing " :stuck_out_tongue:
Usually this is used to send output from one command into another command, but sending it to nul is a nice way of basically just deleting it.

And if you find some more elegant way of displaying it - or other improvements - by all means do share with me :slight_smile:

sending it to nul is a good trick, and sure If I am able to do something better I will put it here.

And if you feel more comfortable in python when there's no reason you can't use that and recreate this, just better. It shouldn't be any issue interacting with rclone from Python I imagine. The only benefit to batch is that it comes default with the OS. Python is superior in all other ways as batch is really limited and clunky.

Making anything fancy in it requires a lot of workarounds. It can be done with some ingenuity, but it takes much more effort. I recently managed to get a multithreading controller for batch working (as that's something that it doesn't normally support at all, but I wanted for my rclone maintenance scripts). Python probably has built-in functionality for handling threads.

I can probably do all this in python.. But I will first try to do it in batch. If nothing works then I will try making the python script.

Here is an example of what you wanted. Put this right under your rclone rc vfs/refresh line:

I have to post this to pastebin because the script includes a weird special character to make sounds that many websites have trouble displaying... Look at the "raw paste data" to make sure you can copy it correctly. Assuming you want the alarm part at all that is:
https://pastebin.com/tPrtUrzp

EDIT: Note that you will have to remove the comments inside of the if ( ) block or else it messes up.

Depending on where you view that character it may show as ^G , BEL or (weird hieroglyphics).

This example is more for illustration than anything and currently it's a bit over-dramatic about a fairly non-critical error and won't let it proceed without being fixed. I'm sure you can modify to your needs :slight_smile: . If not, just ask.

Note:

> nul
only directs the standard output, not error output. Thus, if you get an error you still get to see it. You just ignore the bulky "OK" it sends normally. This might be enough for you. If not then use the error-catch as demonstrated to whatever you think is appropriate. I rang an alarm and make it output running !!!!'s to make sure it's unmissable, but you do you boo :smiley:

It was about time I learned how to handle basic error returns anyway :slight_smile:

hi there,
i use python to script rclone on windows.
if you have any question, i can try to help

I just saw your reply, in the meantime this is what I did:
https://pastebin.com/ppD8jwiE

What this does is that it reads each line of the output of the command and if it finds the substring OK in any of the lines it will display the message

Your error catching method seems fine as well. Any way you could display the error using that technique?

I can modify my script to show the whole output of the command if it is not the result ok one. Meaning it will show the output of the command if there is any error which should help in debugging.

That should work too. Many ways to skin a cat :slight_smile:

The nice thing about error-levels is that it's fairly universal, assuming that the thing you are calling is well made and return proper error-codes as it should. Otherwise you must do something along the lines of what you did there.

Is it possible to display the error using the error catching method? There must be I guess. If yes that would be a very good universal solution.

Yes, it just gets put into a variable
%ERRORLEVEL%

Use it as you would any other variable.

echo Returned error-level %ERRORLEVEL%

But that's just the error-code not the message.
To get the full message you'd have to redirect the ERROR-output
which is something like 2> I think rather than the > that is for standard output

But in my example it's not really needed because the error will display there anyway right above. >nul only redirects the standard ouput, so any error output still goes into the cmd window as normal.

More on redirection in batch here:
https://ss64.com/nt/syntax-redirection.html

All right, that works perfectly then !

I have just modified it like this as I dont want bell sounds whenever there is an error :rofl:

::This triggers if exit code of above command was normal (indicating no error)
if %ERRORLEVEL% equ 0 (
echo Cache warmup for %driveletter%: OK!
)

This is fine right? It will simply just show the error output when error occurs and not show the Cache warmup for driveletter ok , and when there is no error simply show the cache warmup driveletter ok message

You don't like my jank-alarm? Heretic... :stuck_out_tongue:

this is probably a bit more what you want though

::This triggers if exit code of above command was normal (indicating no error)
if %ERRORLEVEL% equ 0 (
echo Cache warmup for %driveletter%: OK!
) else (
echo OpsieDopisie! Something went wrong sadface
)