there seems to be concerns with unmounting a mount using a hard-kill such as
taskkill rclone.exe /F
forum posters are claiming that to hard-kill a rclone mount creates "hanging drives in weird state"
i respectfully disagree.
i believe that to hard-kill a rclone mount is safe and reliable.
when i suggested this to @kapitainsky in post, Rclone mount - progrmatic umount under windows
he wrote that
"Thx for your suggestion. I have tried and as mentioned before results are not as expected. I kill rclone but WinFsp-FUSE rclone is using does not behave the same way as with simple ctrl-C on rclone. Leaves "hanging" drives in weird state etc."
when i asked for clarification about the hanging" drives in weird state, i never got a direct reply.
the reason i asked for clarification about is that would imply that there is a SERIOUS bug in winfsp.
for 3 reasons, i can find no evidence about weird states and hanging drives.
- i have been hard-killing rclone mount all the time for many months on a couple of window servers and desktops.
- i ran the following script below for two hours, many hundreds of times, with zero problems.
- most important of all, winfsp was DESIGNED to handle hard-kills.
based on this post, from the developer of winfsp, makes it clear that hard-kill is the way to unmount on windows.
"For this reason there was never a need for an "unmount" utility in WinFsp"
"closing the volume handle (voluntarily or because of a crash) makes the volume go away: the kernel ensures that all associated kernel resources are properly cleaned up and freed. There are no ill effects, like ghost volumes, system instability, etc"
here is the test code i ran
start /b rclone.exe mount wasabiwest01:vserver03-bjv.h.vserver03.g.ampe01\ x:
timeout /T 5 > nul
taskkill /im rclone.exe /f
timeout /T 5 > nul
so can we please settle this once and for all, how to unmount a rclone mount on windows computers?
I think this is answered here by the author of WinFSP
The proper way to unmount a file system that uses WinFsp-FUSE is by sending it a Ctrl-C. On Windows this is done by calling
GenerateConsoleCtrlEvent . On Cygwin you can also use
pkill to send it a
SIGTERM , especially if you run it as a Cygwin daemon.
@kapitainsky was referring to this issue: https://github.com/kapitainsky/RcloneBrowser/issues/13
I don't know if there are other cases of "weird state"
yes, i agree with you, as i had already read that same weblink you just posted.
perhaps perchance, someday, somebody will implement that solution.
but until then, my question remains, is there anything wrong with a hard-kill of rclone mount?
i have run my script over 1000 times and still no hanging drives and anything weird.
You'd want to simulate drive access / reading / writing.
It's pretty much the same on Linux. If you hard kill and things are going on, odd states happen.
I'd surmise you'd get similar issues on Windows.
the point i am trying to make is that i have experienced zero problems with hardkill on windows.
and given that the creator of winfsp make it clear that a hard kill is not a problem for winfsp.
The use case though as it's not a realistic example of a mount that's being used by read / write.
Things tend to get lost when hard killed so while WinSFP may or may not handle it fine, other issues can arise like for rclone if you are in mid write of a file or something along those lines.
yes, that is a good point about read/write.
i only use rclone mount as read-only.
i use rclone sync to backup large veeam backup files.
about the mount
veeam has a recovery feature called instant vm recovery but expects local storage to read the backup files.
so i use rclone mount, read-only, so that veeam can access those files from wasabi.
how does rclone 'connect' to winfsp?
is there more info about this?
It would be pretty easy to script some dummy traffic into that test-script if you wanted to look into it.
I do agree that simply mounting and hard-killing without any activity probably isn't very representative, and it would likely only expose the most obvious of problems.
I have no need for this personally, but I would still be curious to know the answer from an academic perspective
side-question: @asdffdsa On windows, closing a window (manually) carries an implicit CTRL-C right? It's something I've never really considered before, but I assume that works as a soft-kill.
i am trying to understand the problem.
is the problem that rclonebrowser cannot send a ctrl+c to the rclone.exe?
that since there is no window/console, it is not possible to send the ctrl+c?
so i understand that a hard-kill is not a solution.
but what about a softkill, a normal request to close a .exe.
rclone.exe does not seem to respect a soft-kill request such as
taskkill /im rclone.exe
a soft-kill sends a signal to the .exe to close gracefully.
C:\data\rclone\scripts>taskkill /IM rclone.exe
ERROR: The process "rclone.exe" with PID 3000 could not be terminated.
Reason: This process can only be terminated forcefully (with /F option).
SUCCESS: Sent termination signal to the process "rclone.exe" with PID 15936.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.