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 run into a strange problem when uploading a .mov video file to a remote sftp location:

The problem is that although the local is playable, the remote one throws a -2048 error while trying to play (and a log like "moov atom not found").

PREMISE: the local file and the remote one have exactly the same size. So what can be broken?

share|improve this question

migrated from Mar 20 '12 at 1:18

This question came from our site for professional and enthusiast programmers.

Hi Minitech, did you moved the topic? Should I move it because as I see I had no luck yet here – Mark Mar 19 '12 at 21:07
Sorry, looks like not many people paid attention. I've flagged it for a moderator to move it now. – Ryan O'Hara Mar 19 '12 at 21:32
up vote 2 down vote accepted

Some video formats cannot be encoded from beginning to end like this; the encoder goes back to the beginning to modify some data fields (size, length, etc.). The piecewise copy was unable to handle this, and thus you now have a broken video file.

share|improve this answer
you are right, the header gets modified, any ideea how I could update the header on the server with the bytes from the local header? – Mark Mar 20 '12 at 11:52
You could use dd to copy a few megabytes from the beginning of the complete file, transfer them over, then use dd to integrate them into the broken file. – Ignacio Vazquez-Abrams Mar 20 '12 at 13:47
the local machine can be windows or mac, so I cannot use dd to copy the header. Instead I could use java, but I don't find a way to transfer the information over http, and use it on the server side (for example on php) – Mark Mar 20 '12 at 14:38
There is dd for Windows – deed02392 Mar 21 '12 at 12:39

As far as I can tell (I couldn't really find any documentation describing, or even admitting the existance of it) SFTP resume assumes the part of the target file that already exists is identical to the first part of the source file, up to the size of the remote file. Then it appends the rest of the source file behind the existing target file, and assumes that the two files are now identical.

This fails if the part that was first transferred changes in either file before the transfer is resumed. I guess your .mov file has some kind of header in the very beginning of the file that is necessary to play it, and this is not written to the file until the encoding is finished. Then the remote file you have copied will miss this header, as it was not written yet when it was transferred.

Other tools like rsync have the capability to detect these things, and in some cases avoid retransferring the whole file, at least if the late change is merely overwriting and not insertion.

share|improve this answer
thanks man, I also had the same thought but you just confirmed – Mark Mar 20 '12 at 11:51

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.