As part of the project I am working on, I needed to backup all files from a private account on one computer and move them to another computer on a different private account. I thought this would be fairly simple. Little did I know it would take much longer than necessary and was very tedious to accomplish.
On the source machine, I typed the following to create the backup file.
Source-ACCT_ID3>TBACKUP A A_Drive.tbk (BACKUP
This created a 2.5GB TBK file. I made this file accessible via FTP on the source machine and connected to the destination machine to transfer the file.
Destination-ACCT_ID4>NET RECEIVE FTP://username@Source/A_Drive.tbk
The file transfer box informed me that it would take about an hour to complete. I checked back in an hour and found the following on my screen:
┌────────────────────────────────────────┐
│NET FTP Download │
├────────────────────────────────────────┤
│ File: │
│ Transferred: 919.36 MB of 2589.71 MB │
│ Remaining: 52 min, 57 sec │
│ Rate: 540 KBps │
│ ┌────────────────────────────────────┐ │
│ │████████████ 35% │ │
│ └────────────────────────────────────┘ │
│ ┌──────────┐ │
│ │ Cancel │ │
│ └──────────┘ │
└────────────────────────────────────────┘
I watched it for about a minute to see if there was any progress, which there wasn’t. I opened another session on the destination computer to see if it was still functioning, it was. I typed NET SOCK to check the status of any network sockets.
Nbr│OpCode│Local │ Remote │ Port│IState │OState │Pid│ IN│ OUT│Retry
───┼──────┼──────────────┼───────────────┼─────┼─────────┼───────┼───┼─────┼─────┼──────
6│ │62148 │10.0.100.2 │ 21│ESTABLISH│IDLE │203│ 28│ 0│ 0
7│RECVFR│62149 │10.0.100.2 │ 5021│ESTABLISH│IDLE │203│ 0│ 0│ 0
This shows the FTP command socket (number 6) and also the FTP data socket (number 7). It seemed strange that the command socket had 28 bytes in the input buffer.
I connected to the source machine to see if it had locked up. It hadn’t. I typed NET SOCK to check the status of any network sockets.
Nbr│OpCode│Local │ Remote │ Port│IState │OState │Pid│ IN│ OUT│Retry
───┼──────┼──────────────┼───────────────┼─────┼─────────┼───────┼───┼─────┼─────┼──────
6│RECVFR│ 21=ftp │10.10.3.115 │62148│ESTABLISH│IDLE │200│ 0│ 0│ 0
I immediately saw the problem. The data socket did not exist! Performing a SHOW USER showed that the PID serving the request was waiting for input.
Id │Account │Program │Status / Info │User │Terminal│IP
────┼────────┼────────┼────────────────┼────────┼────────┼───────────────
200*│FTP10623│FTP │I TCPIP:13ABC │ │ │10.10.3.115
I have no idea as to why the source machine decided to close the data socket. My only choice was to abandon the transfer and try again. I restarted it by pressing Break+Q (to abort the job), Page Up (to recall the prior command from the command line history) and Enter to execute the FTP command. Luckily, it continued from where it left off instead of starting over.
This time I watched the transmission. It failed again.
┌────────────────────────────────────────┐
│NET FTP Download │
├────────────────────────────────────────┤
│ File: │
│ Transferred: 1801.94 MB of 2589.71 MB │
│ Remaining: 6 min, 6 sec │
│ Rate: 2.16 MBps │
│ ┌────────────────────────────────────┐ │
│ │████████████████69%██████ │ │
│ └────────────────────────────────────┘ │
│ ┌──────────┐ │
│ │ Cancel │ │
│ └──────────┘ │
└────────────────────────────────────────┘
I typed NET SOCK again on both machines. The destination machine had similar results as before with the only difference being the command socket did not have the 28 bytes in the Input buffer. The difference on the source machine was that it now contained a data socket!
Nbr│OpCode│Local │ Remote │ Port│IState │OState │Pid│ IN│ OUT│Retry
───┼──────┼──────────────┼───────────────┼─────┼─────────┼───────┼───┼─────┼─────┼──────
6│ │ 21=ftp │10.10.3.115 │62150│ESTABLISH│IDLE │200│ 0│ 0│ 0
10│SENDTO│ 5021=ftp-dta │10.10.3.115 │62151│ESTABLISH│RETRANS│200│ 0│17520│ 14
Apparently it was attempting to send 17520 bytes and was on the 14th retry. Shortly after I copied the above to my clipboard, the data socket disappeared and the 28 bytes appeared in the input buffer on the destination machine.
My guess is that something happened on the destination machine which caused packets from the data connection to not be received. The source machine attempted to resend the unacknowledged packet. After about 20 attempts, the source machine closed the data connection and sent a notification on the command socket that the connection had been dropped (the 28 bytes). The destination machine did not consume the 28 bytes which is why they were still waiting in the input buffer.
I restarted the transmission again and this time it finished successfully.
When the transfer finally finished, I attempted to restore the archive with the following
TBACKUP A_Drive.tbk (RESTORE REPLACE NOQ
Which gave me the following error.
┌───────────────────────────┐
│TBACKUP │
├───────────────────────────┤
│ │
│ Source Account not found. │
│ │
│ ┌──────────┐ │
│ │ OK │ │
│ └──────────┘ │
└───────────────────────────┘
I realized that I failed to include the option to specify which account to restore. I tried again
TBACKUP A_Drive.tbk (RESTORE REPLACE NOQ FROM ACCT_ID3
but received the same error. Perhaps the FROM option only worked in conjunction with the VOLUME option and I needed to actually be logged on to the account ACCT_ID3 in order to restore the data. The problem is that ACCT_ID3 already had a different data set on it that could not be replaced. I decided to change ACCT_ID3 to be a synonym to the account I was trying to restore to, ACCT_ID4. I typed ACCOUNT, selected ACCT_ID3 in the list and clicked the Modify button, only to find that the Alias to: and Id: boxes were grayed out and didn’t allow modifications.
My next idea was to manually edit the Account.bin file. WW /Theos/Config/Account.bin opened the file as read only. I had to remove the write protections on the file before I could manually edit it.
CHANGE /Theos/Config/Account.bin (nrnwnxnenmnh shared nrnw noq
WW /Theos/Config/Account.bin
I found ACCT_ID3 and changed ID=S3 to ID=S4. I then logged on as ACCT_ID3, and was able to successfully restore the TBACKUP file.