--partial and --partial-dir not working for "Restore Files"

[timboxyz]

Trying to restore from a server whilst connected via a spotty VPN with either --partial or --partial-dir and if using the "Restore Files" option the flags appear not to be honoured.

1/. Start transfer and usual .file.xyz appears in local temp catalogue. 2/. Drop VPN and transfer stalls but the process does not exit. 3/. Stop transfer using the stop button on the "Executing" dropdown. 4/ Re-instate VPN. 5/. Try and restart by re-cataloguing and selecting file. RsyncOSX becomes unresponsive and eventually has to be Force Quit. Alternatively just quit without trying to re-catalogue to avoid the hang. 6/. Restart RsyncOSX 7/. Select file again and restart the transfer. A new .file.abc appears in local temp catalogue. The existing .file.xyz is ignored.

Compare this with a command line of the form:- rsync --archive --verbose --compress -e ssh --partial --stats me@remote:/media/assets/some-file /Volumes/G-DRIVE/local-catalogue/

which if CTRL X'd when VPN drops and rerun when VPN restarts, makes the .file.xyz file and creates a new .file.asd which it then appends to the end of file when completed, the stats show a corresponding speedup depending on how far through the transfer the line dropped.

If you attempt a full restore it seems to work OK.

[rsyncOSX]

I have never tried --partial parameter to rsync before. It seems like the Process object does not catch there is a problem.. Every time a task is executed, RsyncOSX is waiting for two notifications: either a terminate or a filehandler notification. When you select the stop button a termination signal is sent to the Process object..

I am not sure what happens when the VPN tunnel is dropped, but you should see termination message in the output from rsync when the stop button is pressed.. If not seen it is difficult to say which condition/state RsyncOSX is..

There is a similar situation in Add config selecting the Capacity button right in view if the server is not reachable. There is a timeout, and RsyncOSX becomes a kind of unresponsive until the timeout kicks in..

If force quit I think rsync might do a cleanup and is not able to continue where left of.. I have to check what happens.. I will also check if there are some possibility to check if the Process object is alive or not during a task.. And implement a kind of timeout and terminate functionality...

[rsyncOSX]

I am not sure what happens with the Process object when the VPN tunnel is dropped... I suggest I make a test version for you that verifies that the process object is alive after dropping the VPN tunnel.. The only way I can do something when dropping the VPN is through the process object.. So let us do some testing if OK for you...

[timboxyz]

I have compared the behaviour of a command-line rsync and RysncOSX. If the VPN drops neither seem to time out (withing a reasonable waiting time anyway). CTL C'ing the command line, re-establishing the VPN and rerunning the command resumes properly. Stopping RsyncOSX leads to hanging on the restart as mentioned earlier.

However, I have also discovered that if you stop RsyncOSX (VPN still running) the underlying rsync process does not stop immediately when transferring a single file.

I chose to restore a sizeable file and monitored the local catalogue. Then I stopped RsyncOSX but the local catalogue rsync temp file continued to grow until the file transfer was complete. So it looks like the underlying process is still running. This may account for the hang when trying to restart as above, it cannot connect to the process as it is still running.

Happy to test anything you like.

[rsyncOSX]

When you are selecting stop - the process object receives a terminate() signal.. It seems like the process is ignoring this until next file transfer... Anyway, I will make a test for you to verify what happens when the VPN is dropping...

[rsyncOSX]

Hi.. First of all I have to make sure that dropping the VPN does not make RsyncOSX a zoombie.. There is a download link to dropbox, just download the dmg and execute RsyncOSX from within the dmg file..

https://www.dropbox.com/sh/5pe9h2fh4md2n15/AABaR0sZk1JVvs82QXpzIYsTa?dl=0

Also create a new logfile..

Select a task and just do a normal dry-run execution, double click.. Every second during the dry-run, a tag is written to the logfile.. Start the estimation, drop the VPN connection and let RsyncOSX run for about 10-20 secs after dropping the VPN..

[timboxyz]

Doesn't seem to be being zombied

Creating a new logfile: file:///Users/tim/Documents/rsynclog.txt
-------------------------------------------
17 Jun 2020 at 13:42
-------------------------------------------
Checking 17 Jun 2020 at 13:42:18 BST
-------------------------------------------
17 Jun 2020 at 13:42
-------------------------------------------
Checking 17 Jun 2020 at 13:42:19 BST
....
17 Jun 2020 at 13:42
-------------------------------------------
Checking 17 Jun 2020 at 13:42:50 BST
-------------------------------------------
17 Jun 2020 at 13:42
-------------------------------------------
sending incremental file list
.DS_Store
._.DS_Store
packet_write_wait: Connection to 10.0.0.155 port 22: Broken pipe
rsync: connection unexpectedly closed (13 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(226) [sender=3.1.3]

[rsyncOSX]

OK; great.. well i did not belive it should.. I will continue to see what to do next.. I have to investigate how to verify rsync is executing as expected and add a timeout before terminating the process...

[rsyncOSX]

As a test I added an interupt every 5 sec and stopped (interupt() method) the transfer, and restartet it.. For me it seems like the --partial is working..

[rsyncOSX]

I have uploaded a new dmg to test the --partial param to rsync. It interrupts a task after 10 seconds.

1. Select the task and execute the task by ⌘R (executes the task without estimation)
2. After 10 secs the task is interupted, check the partial transferred file
3. Select the task again and execute by ⌘R and after 10 secs the task is interrupted again..
4. Continue num 2 and 3 until checked enough..

https://www.dropbox.com/sh/5pe9h2fh4md2n15/AABaR0sZk1JVvs82QXpzIYsTa?dl=0

[rsyncOSX]

I also did another test with the released version, started the task by ⌘R, pressed the stop button after about 10 secs, selected the task again and continue by ⌘R.. and it seems like partial is working..

[timboxyz]

⌘R doesn't seem to work on restore only on sync. It just boings at me.

[timboxyz]

Also if I start a restore normally and press stop, I don't see a SIGTERM in the log to show that rsync has received one and it continues to the end of the file (unless the VPN drops, but even then I don't see a 'broken pipe' error which I would expect if the VPN drops).

[rsyncOSX]

The ⌘R only works in sync, not restore... one reason is because of control of restore and not by accident overwrite files.. If you are syncing files on a regular basis from a remote to local you should probably utilize a syncremote task.. A syncremote task is executed from the main sync view and can also be initiated by ⌘R..

[timboxyz]

Not sure it is a regular basis. But occasionally needing to pull back one or two big files from a folder to work on, hence the use of --partial, then push results back. I will try a syncremote

Any progress on why a stop doesn't seem to be sending a SIGTERM to rsync on restore of a single file but does for a full restore?

[rsyncOSX]

The abort in restore is also changed now, all aborts now is ending up here, a SIGTERM should now also be seen in aborting a restore :-) changed yesterday in code...

[timboxyz]

I can confirm that with syncremote --partial/--partial-dir work as expected when the process is stopped using the stop button. Even if using the normal estimate and run mode on the rerun.

What I can't seem to see happening is the rsync process timing out when the VPN drops. You have to use the stop button. This is not your problem, but a strangeness nonetheless.

[rsyncOSX]

OK, that is nice.. I have done som changes and implemented a scheduled check on single tasks.. the check is number of output from rsync increases at every check.. If not increasing a popup is presented and give the user a possibility to interrupt a task.. the challenge is that the schedule is not connected to filesize.. if the schedule kicks in before file is transferred a pop up is shown... it is still in beta - have to see if there are any method of estimating how long time...

Can I close the issue?

[timboxyz]

I think closing is appropriate. I'm sorry if this has turned out to be an odd side issue that has consumed too much time.

[rsyncOSX]

I think open the issue was wright :-) I have got some new input, some code are changed and I have a few ideas.. This is how SW get better ... ask questions, and I am depended upon input from users to make RsyncOSX a better tool...

So, thx for opening the issue...

[timboxyz]

OK thank you. Just one final thought. Do you have any idea why running the command line in a terminal session would mean rsync stops with a connection unexpectedly closed error in a few seconds if the VPN drops. But when run from within RsyncOSX it never seems to notice and just sits there?

[rsyncOSX]

I am sure it has something to do with RsyncOSX not picking up signals from the macOS... I believe rsync is monitoring the connection and picks up like network signals.. I have put this on my todo list to investigate what it takes to monitor macOS system signals.. I am quite sure it is possible in Swift, but I dont yet know how... So, maybe in the next version :-) Most likely yes...

fre. 19. jun. 2020 kl. 15:13 skrev timboxyz notifications@github.com:

OK thank you. Just one final thought. Do you have any idea why running the command line in a terminal session would mean rsync stops with a connection unexpectedly closed error in a few seconds if the VPN drops. But when run from within RsyncOSX it never seems to notice and just sits there?

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/rsyncOSX/RsyncOSX/issues/1783#issuecomment-646628801, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFLDNTDMPXZKKJFJAIDRIO3RXNQARANCNFSM4N72DJSA .

[rsyncOSX]

Hi.. for your info I have (in test) implemented monitoring of network.. If network drops a interrupt signal is sent to the process and the process stops.. I am not sure it detect if a VPN tunnel is dropped, but it detect network changes...

[timboxyz]

If you have a version you would like me to test happy to do so.

[rsyncOSX]

Link is here : https://www.dropbox.com/sh/5pe9h2fh4md2n15/AABaR0sZk1JVvs82QXpzIYsTa?dl=0

You have to enable Monitor network connection in user config.. It detects if network is dropped and interrupts a rsync action, bu I do belive it does not detect a drop in VPN tunnel...

[timboxyz]

No, it appears not to detect a VPN drop. :(

[rsyncOSX]

I did expect that the network monitor only detects if there is an issue with network connection.. I don't know what it takes to monitor a VPN tunnel. Anyway, your issue resulted in code for monitoring the network, and that is nice..

So, I am sorry I can't solve your specific problem...

tir. 23. jun. 2020 kl. 15:59 skrev timboxyz notifications@github.com:

No, it appears not to detect a VPN drop. :(

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/rsyncOSX/RsyncOSX/issues/1783#issuecomment-648167912, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFLDNTDI5KGGQSVRDFP64KTRYCYMPANCNFSM4N72DJSA .

[timboxyz]

Since stopping the transfer results in rsync doing a clean up and exit its just a case of spotting when things have stalled and doing it manually. So not the end of the world.

I think monitoring a VPN tunnel would need some cleverness around spotting the configuration in ifconfig contained a PPP and then keeping an eye on that. Sounds overly complicated for little gain to me.