home *** CD-ROM | disk | FTP | other *** search
- Path: ldvgpi16.eikon.e-technik.tu-muenchen.de!flowerp
- From: flowerp@ldvgpi16.eikon.e-technik.tu-muenchen.de (CHRISTIAN BUCHNER )
- Newsgroups: comp.sys.amiga.programmer
- Subject: Re: Wanted: PIPE replacement!
- Date: 19 Jan 1996 11:27:00 GMT
- Organization: EIKON Elektrotechnik TU Muenchen
- Distribution: world
- Message-ID: <4dnv64$pqr@sparcserver.lrz-muenchen.de>
- References: <4dgbo2$4i9@sparcserver.lrz-muenchen.de> <oj64ttt17mo.fsf@hpsrk.fc.hp.com>
- NNTP-Posting-Host: ldvgpi16.eikon.e-technik.tu-muenchen.de
- X-Newsreader: TIN [version 1.2 PL2]
-
- > > PIPE: (or queue) handler. When pushing large data files through the
- > > PIPE:, I will always lose data. Obviously PIPE: was only built for small
- > > files (text output of programs etc.)
-
- > I don't think so. I just tried transferring 31 Mb (the largest file I
- > had handy) through two PIPE: pipes. Worked fine, no data loss
- > whatsoever. If by "large data files" you mean something bigger than
- > that, then I've never tried, so you may be right. But that is, if not
- > big, at least not small I think.
-
-
- huh? Are we both talking about the same queue-handler? I own OS 3.1 and the
- OS 3.1 WB disks.
-
- From one CLI process I type "Copy Image.JPG PIPE:Test" and in another CLI
- process I use "Type >File PIPE:Test". The resulting file will be much too
- short and unuseable.
-
- The HWGQueue-Handler from Aminet fixes this problem.
-
- But is there any C= pipe handler that does not cause this trouble?
-
- > I've never seen the current one lose data. How big of a transfer are
- > you talking about, anyway?
-
- I have heard some people talking about a bug that occurs when buffering more
- than 4KB of data in the pipe (queue) handler. The problem affected me even when
- transferring short JPG images. Strange.
-
- Say, you really didn't install any replacement for queue-handler, did you?
-
- //
- \X/ Flowerpower
-