You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have seen this behaviour multiple times; time to ask about it. When running m5copy (jive5ab v3 on my side, probably also at recipient in Vienna) with --resume option (after transfers stopped for some reason), then I get a message that some files "already exists". However, my impression is that all files checked already exists. But, the message only appears for some of them. For the others, I get a few seconds of looking at "Waiting for remote end to flush ... None" which suggests there are no packets to flush? But then it should show "already exists" also for these files? Here is a bit of m5copy output:
Here are my side of the j5ab logs for two represenativ scans, the 1801_0 which doesn't show the "already exists" message, and 1801_1 which does show the message:
Interestingly, it seem to say "wrote 0 (0byte)" in both cases. So my assumption that both files were actually transferred seem correct. Curious then why the "already exists" message is only shown for one of them?
The text was updated successfully, but these errors were encountered:
This probably has to to with (yet another) timing issue.
Whether m5copy displays the message ... already exists, skipping depends on the code handling the actual transfer throwing an IgnoreFile exception. However, the condition under which this is thrown is subject to timing, see the following snippet, and also the preceding comment. Sometimes the sender finishes itself before the while loop is entered, and sometimes it doesn't.
It would be interesting to run m5copy -d ... -d is the sekrit hidden command line option that prints all traffic (commands and replies) between m5copy and the sending/receiving jive5ab)
# HV: 9 dec 2014 GRRRR. Roger H. finds that, sometimes,
# "disk2net=on" takes so long that it remains
# in the connected state by the time we get to the
# .progress(self) method. So we must wait here
# for the status to become active
# 4 jan 2016 BE finds that status could go to inactive
# if the transfer finishes (very) quickly
while True:
r = CTRL.send_query("disk2net?", [0])
if "connected" not in r:
break
progress_print("\r>>>> Waiting for disk2net to start")
time.sleep(1)
if "inactive" in r:
# Sender immediately stopped sending because everything is already there!
raise IgnoreFile
I have seen this behaviour multiple times; time to ask about it. When running m5copy (jive5ab v3 on my side, probably also at recipient in Vienna) with --resume option (after transfers stopped for some reason), then I get a message that some files "already exists". However, my impression is that all files checked already exists. But, the message only appears for some of them. For the others, I get a few seconds of looking at "Waiting for remote end to flush ... None" which suggests there are no packets to flush? But then it should show "already exists" also for these files? Here is a bit of m5copy output:
Here are my side of the j5ab logs for two represenativ scans, the 1801_0 which doesn't show the "already exists" message, and 1801_1 which does show the message:
Interestingly, it seem to say "wrote 0 (0byte)" in both cases. So my assumption that both files were actually transferred seem correct. Curious then why the "already exists" message is only shown for one of them?
The text was updated successfully, but these errors were encountered: