Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I've got a number of bash scripts that copy files across a network using cp from a CIFS (Windows) mount.

  1. Is there any risk of data corruption or any other irregularities caused by interrupting the script using Ctrl+Z (and then of course resuming it again by using [fg,bg] <job ID>)?
  2. Also, is it possible that risk depends on what kind of mount you are copying from?

These questions assume that the network connection is not physically interrupted or lost at any point, i.e. by 'pulling the plug', or forcibly unmounted.

share|improve this question
I might use rsync to gain some enhanced restartable functionality:… – BrianAdkins Jul 14 '12 at 0:00
@BrianAdkins This doesn't really answer the question. If people think it's a a question more appropriate for ServerFault then I will move it. – Doddy Jul 14 '12 at 1:10
up vote 3 down vote accepted

WHen you stop a process with Ctrl-Z, it does not "know" that it has been paused unless it explicitly monitors signals.

So, in other words, there is little or no risk that the data at the other end will be corrupted.

I say "little or no" because there is always a risk that the communication path will timeout in some way if the job is paused for too long. For instance, there are timeouts implicit in many NAT implementations, so if there is a NAT router in the path you may see issues if you pause for long periods of time. I can't really say how long is "too long", but if you are merely interrupting the job to put it in the background within a few seconds, I'd say this timeout risk is almost nil.

I don't think the source or destination file type matters here; again, certain sources and destinations may not like pauses. I'm not taking buggy implementations into account here; buggy kernels might not like a process being stopped, but I've never seen it in practice.

A smart move in your case might be to use rsync; coupled with Ctrl-Z you get a really fine degree of control - both the ability to stop, and the ability to restart a failed transmission (which, to be clear, I am assuming would fail for reasons other than the process being stopped).

There is one important point here - if you stop a job in an interactive multi-command line, sometimes the next job will start or resuming will forget about the additional jobs. You could test this with something like: echo 1; sleep 10; echo 2; echo 3 and stop the job while the sleep is happening, and see whether you get all the numbers printed in the right order with the right timing. This does not apply to shell scripts; a Ctrl-Zed shell script will resume from where you stopped it.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.