i witnessed that, back in time when they barely renamed btsync to resilio.
and never later shortly after.
and after your suggestions still decided to add --vfs-write-back 5s to my rclone invocation script, just in case.
and out of pure curiosity and for the sake of testing, tried to point resilio directly to the rclone-mounted bucket for a folder with documents which are of course small files.
not very many of them, but some are critical enough to bother with an offsite copy.
so, now i have an offsite copy, PLUS a 30day fallback copies archive in case of accidental deletion, in their .sync\archive folder.
works like a charm.
Stability, purity, and architectural reasons. In no particular order:
fuse introduces very high internet latency into virtual filesystem path. Requires very high (up to 599s, but no more than that to avoid other issues) daemon-timeout to avoid nasty behaviour but stalls persist.
part of the code lives in the kernel. Horrible idea. On macOS kexts are on purpose hard to install, and generally frowned upon.
on windows probably also? If not, Microsoft shall know better.
nfsmount is more appropriaye on both fronts â you are using path that is already expecting network flakiness.
no need for kernel extensions, all kernel components already exist.
khe!
tried to put some test file in that documents folder, then delete it on a different computer than the one with the resilio instance pointed to the mounted bucket.
and it didnt move the deleted file into .sync\archive folder on the computer with the mounted bucket.
so it seems i have to limit myself only with the synced copy and not have the fallback archive on the cloud.
very very pity.
huh-huh-huh.
okay, and my current mount is rclone mount storj:vol-s d:\vol-s ...
maybe because of this resilio has trouble moving deleted files to .sync\archive???
what should i change in this, considering that my rclone is on windows?
full mount command: rclone mount storj:vol-s d:\vol-s --vfs-cache-mode full --vfs-write-back 5s --fuse-flag --network-mode --links --cache-dir t:\rclone.cache --vfs-read-chunk-streams 16
what i am currently trying to debug is the fact that resilio couldnt move the file to its .sync\archive after i deleted it on another computer.
one of the work hypotheses was that it works okay, just i dont see it because of caching which has a 1h expire time.
ran with -v and repeated the test.
all okay while creating it then syncing, not even the slightest sign of any attempt to process it in any way when deleted on another computer and let resilio handle that on the mount.
waited some time and looked again at the console where rclone is running with -v.
still not even the slightest sign of any reporting on that file and no errors either.
tried to consult with copilot on this matter and now i am even more disoriented than before.
I would exclude this from rclone sync. Add --exclude ".sync/** to your rclone commands. Stuff there is resilio state specific to this machine. It shall not be replicated.
On the other comment â yes, on windows you probably want to use network mode and mount as a drive letter. Then you can symlink this anywhere you need.
refused, because drive letters are local to the session that runs rclone (from a script ran as a scheduled task fired at boot) and are not visible anywhere else.
it is the same user account as resilio, just different sessions.
rclone is from a scheduled task and resilio as a service for which i changed login details for, from localsystem to that user.
different sessions, so drive letters from rclone are not visible anywhere else.
only mounts as a folder are visible outside session.
i still suspect permissions, but didnt yet find a way to make them persistent or at least memorizable in ram until next mount operation so i could set them up in my global startup script which first waits for the rclone task to do the mount, then does some network shares of that etc.
possible to make a drive mount available to everyone on the system, by running the process creating it as the built-in SYSTEM account. There are several ways to do this: One is to use the command-line utility PsExec, from Microsoftâs Sysinternals suite, which has option -s to start processes as the SYSTEM account. Another alternative is to run the mount command from a Windows Scheduled Task, or a Windows Service, configured to run as the SYSTEM account. A third alternative is to use theWinFsp.Launcher infrastructure)
This will create a mount outside of per-logon namespace. You will need to pass explicit --config and --cache-dir because that user does not have home directory.
okay.
so i just tried to psexec -s specifying the config in addition to what i already had.
could be mounted either as a drive letter that was visible everywhere, or as a folder mount point as before.
but in both cases resilio immediately complained that it doesnt have write permissions as soon as i pointed it to the folder location.
also tried to add -o FileSecurity="D:P(A;;FA;;;WD)" after a bit of rclone mount rtfm.
and the situation returned to the file not being deleted or moved to archive after a remote delete, but all incoming sync worked fine (i mean exactly the same situation as i described priorly).
I see. I remember seeing much higher memory usage for the same performance thoughâmy guess was a duplicated cache between the kernel and rclone. Iâll stay with fuse for now, I really didnât have any bad experiences so farâŚ
