xfer problems sco-sun

[Brian K. White]

Jay R. Ashworth wrote:
> On Thu, Apr 01, 2004 at 02:17:07PM -0500, Brian K. White wrote:
>> swapcpu? Just sounds like:
>> dd conv=swab if=in.txt of=out.txt
>
> *Ghod* no.
>
> You only have to swap the *record headers*, where there is binary
> data. Everything else is stored in ASCII; if you swap it, you'll
> trash the data.

Interesting, annoying too. Oh well, back to the original problem which is
that xfer should have worked.

I would not be surprised if the problem is simple file size.

the file he happens to be working on has very large key & data, like,
pushing the 2 gig limit large, and, there are somewhere over 50 qualifiers
that each have smaller key & data

Although the output file that xfer created was well short of 2 gigs, I
wouldn't be surprized if the problem was that the output file accumulated to
over 1 gig and then hit a single file component like one of the large key or
data that would have pushed the output file over the 2 gig limit, and so
xfer crashes on that file and goes no further, leaving whatever files it
didn't happen to get to yet at the time it hit the big one.

I don't know an easy way around this unless it's possible to direct xfer
output to a pipe instead of to a file.
(maybe you can fake it with a named pipe?)
an stream the output data over the network to the sun box and have xfer on
the sun box read from a pipe instead of a file, again possibly via named
pipe if it doesn't offer a real way to use stdin/out.

xfer attempts to do a job similar to "tar" and this is one reason why such
things as tar and cpio can use stdin and stdout, so xfer should too. If it
can't, I am saying it _should_ and requesting that it be updated at some
point.
stdin/out could then be piped across network or serial by unlimited
different mechanisms.

Brian K. White  --  brian at aljex.com  --  http://www.aljex.com/bkw/
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro BBx  Linux SCO  Prosper/FACTS AutoCAD  #callahans Satriani