[QUOTE=Andi47;224051]4.) in the command line type "copy *.out msieve.dat"[/QUOTE]I've seen this go wrong. I always use "Copy /B" to make sure the dat file remains valid.

Also, instead of *.out I would use 0.out+1.out to make sure the files are in the right order.

Thus "Copy /B 0.out+1.out msieve.dat"

[QUOTE=smh;224079]I've seen this go wrong. I always use "Copy /B" to make sure the dat file remains valid.

Also, instead of *.out I would use 0.out+1.out to make sure the files are in the right order.

Thus "Copy /B 0.out+1.out msieve.dat"[/QUOTE]


What does the /B flag do? Check the .dat file for integrity?

[quote=Andi47;224101]What does the /B flag do? Check the .dat file for integrity?[/quote]
It sets copy to binary mode, which makes sure that it doesn't mess with the file at all. (The default is text mode, which may mess with line endings or something like that...I'm not really sure exactly what it does, but at any rate it's not something you want on a dat file like this.)

[quote=mdettweiler;224121]It sets copy to binary mode, which makes sure that it doesn't mess with the file at all. (The default is text mode, which may mess with line endings or something like that...I'm not really sure exactly what it does, but at any rate it's not something you want on a dat file like this.)[/quote]
It has nothing to do with line endings; the only difference between copy's "text" and "binary" modes is that in "text" mode Control-Z is interpreted as an end-of-file character; reading of source files stops at the first C-Z, and it's written at the end of destination files. This bit of insanity comes from the fact that copy emulates faithfully the MS-DOS copy command (on the assumption that someone still might be running old DOS BAT files which depend on this idiocy).