🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: alt.msdos.programmer
Article #62

Re: file positioning with buffered/unbuffered I/O

#62
From: Charlie Wilkinson
Date: Thu, 06 Aug 1992 15:41
44 lines
2926 bytes
nett@technix.mn.org (Jerry Nettleton) writes:
: A program I'm working reads a text file to load a database.  When an
: error is encountered in the text, I need to go backwards in the file
: to a saved location and print the text and error messages.  I've tried
: to use 'ftell/fseek' and 'fgetpos/fsetpos', but these functions don't
: work reliably when buffered I/O is enabled.  They return multiples of
: 0x0200 (BUFSIZ).  I've also tried to open the twice, one file pointer
: to read lines and parse the info and the other one for generating
: error messages.  Unbuffered I/O slows down the conversion process
: significantly...
: 
: Any ideas?

You might want to consider using the low level I/O functions:
open()  - opens the file
sopen() - open for file-sharing
creat() - make a new file or truncate an existing one
dup() & dup2()  - force a second file handle to refer to an open file
lseek() - set current position within the file
tell()  - get current position within the file
read()  - read bytes from file (up to 65534 at a time)
write() - write bytes to file   "      "     "     "
eof()   - determines if EOF has been reached
close() - closes the file

They are slightly more of a pain to use, but can be much faster if you
read/write in large chunks.  My book (The MSC Bible 2nd edition) says
that although none of these functions are ANSI compliant, almost all of them
can be used with every compiler.  The exception being that some are not
Unix and/or Xenix compatible.  You didn't mention what compiler you are
using.  I would venture to say that you should be able to do exactly what
you want to do using these functions.  If you set up a large array (20k or
so) for moving big chunks with read() and write(), you should get blazing
speed compared to the high level functions.  If you are not moving too many
bytes in or out and are mostly seeking and reading small pieces, things
should still clip right along.

Hope this is helpful, and please let me know what happens.

--
cwilkins@irscscm.uucp                                   /======================\
uunet!mimsy!prometheus!media!ka3ovk!irscscm!cwilkins    | Micro-Sig(tm) pellet |
N3HAZ@KA3RFE.MD.USA.NA                                  |   -just add water    |
...or you can call me Charlie                           \======================/
Technical Details
Message-ID: <1992Aug6.154146.11988@irscscm.UUCP>
Path: arc1-ca.pugleaf.net!sparky!uunet!wupost!sdd.hp.com!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!unixhub!lll-winken!iggy.GW.Vitalink.COM!nocsun.NOC.Vitalink.COM!wetware!wsrcc!ka3ovk!irscscm!cwilkins
References: <1992Aug02.080128.18475@technix.mn.org>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!sparky!uunet!wupost!sdd.hp.com!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!unixhub!lll-winken!iggy.GW.Vitalink.COM!nocsun.NOC.Vitalink.COM!wetware!wsrcc!ka3ovk!irscscm!cwilkins
From: cwilkins@irscscm.UUCP (Charlie Wilkinson)
Newsgroups: alt.msdos.programmer,comp.lang.c,comp.os.msdos.programmer
Subject: Re: file positioning with buffered/unbuffered I/O
Message-ID: <1992Aug6.154146.11988@irscscm.UUCP>
Date: 6 Aug 92 15:41:46 GMT
References: <1992Aug02.080128.18475@technix.mn.org>
Organization: Internal Revenue Service
Lines: 44