Aside from putting on kernel 2.0.39-pre4 and DAC960 support, there are new versions of pax and dd. The dd especially I'd like tested, and I'd like some feedback from other users on: What output do you get on _your_ system from: dd if=/dev/zero bs=10000 count=1 > test1 dd if=/dev/zero bs=10000 count=1 | dd bs=10000 count=1 > test2 ls -l test1 test2 Now, to MY lights, dd should be usable this way to count a chunk of a file, it should NOT depend on the size of the shell's pipe buffer, but, on all the 'dd' version I can find (except the one I patched for .204), the second 'dd' counts 1 input block based on what is available in the pipe, and the results are different. Well, I have to admit, it seems to be "broken" on HP/UX (at 8192) and Solaris (at 10240), also, but, given that you never know exactly what a pipe will buffer, it makes it useless for counting/skipping/seeking unless you know exactly what the physical characteristics are of what you are reading from. Now, it turns out that the only reason I included 'dd' on tomsrtbt in the FIRST place was I wanted an accurate way of doing seek/skip/count stuff, I certainly don't want to be forced to using "bs=1 count=10000", yes, that would work, but is painfully inefficient, I don't really want to read one byte at a time from the floppy. _SO_, what I have done, is changed the "safe_read" routine in the fileutils/lib for the "dd" so that it will keep trying to fill up the requested read until it either has a full buffer, or EOF, or an error. This means some inefficiencies if you are trying to use it just instead of the 'buffer' program, I suppose, but what I really want to know is, can anyone think of any other negative side effects? -Tom
