2

I am trying to copy the content from my source folder to mounted destination folder. What I did is i was mounted 4 devices by giving the ip to /etc/fstab.

//192.168.100.1/C1 /media/Client_1 smbfs guest 0 0

//192.168.100.2/C2 /media/Client_2 smbfs guest 0 0

//192.168.100.2/C3 /media/Client_3 smbfs guest 0 0

//192.168.100.2/C4 /media/Client_4 smbfs guest 0 0

and then by using python script,I am trying to copy the files to all Client_1,Client_2,3 and 4 folders.The below line is used to copy the file to mounted folders.

os.system("cp -f sourcepath/* /media/C1" %locals())
os.system("cp -f sourcepath/* /media/C2" %locals())
like C3 and C4 folders

The file is moving properly. But, the problem is if any network issues are happened while copying the content the script will not move to next line, the process is waiting until the network come back again. Out of 4 mounted device if suppose C2 has a problem, the script terminate the c2 and try to move the content to c3 and c4. I am struggling this place. If you know let me.

Note: I can understand -f means force, if an existing destination file cannot be opened, remove it and try again . What argument i need to use for copy the content to mounted folder, if any network issues happen, it need to terminate that copying folder.

3
  • I'm not an expert, but since you're using python, you should really use the shutil module, since it would give you more control over your file. Nov 16, 2012 at 13:13
  • This is off topic for askubuntu. You should ask programming questions at stackoverflow.
    – psusi
    Nov 16, 2012 at 15:40
  • double-post: askubuntu.com/q/217892/507051
    – dessert
    Nov 21, 2018 at 23:04

1 Answer 1

2

Much that I love python, this isn't really a case for which it is needed. The problem here is that when an smb connection fails, cp operations freeze rather than terminate. Neither python nor bash will detect this.

So, you could start all jobs in parallel

user@host:~$ for dest in /media/Client_{1,2,3,4}; do cp -f sourcepath/* $dest & done

But this will probably choke your network. A better option may be to let cp run for an expected duration and then have it killed if it has frozen

user@host:~$ for dest in /media/Client_{1,2,3,4}; do timeout -k 9 30m cp -f sourcepath/* $dest; done

Which will kill the cp command with SIGKILL (signal 9) after 30 minutes if it has hung.

However, if needing to restart the transfer is a frequent problem, you probably want to use rsync instead of cp, which will check what has already been copied and resume wherever it got to.

Not the answer you're looking for? Browse other questions tagged .