Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!overload!dillon From: dillon@overload.Berkeley.CA.US (Matthew Dillon) Newsgroups: comp.sys.amiga.tech Subject: Re: Files larger than available memory. Message-ID: Date: 2 Oct 90 14:07:14 GMT References: <924@ucsvc.ucs.unimelb.edu.au> <1990Sep23.174736.16118@lavaca.uh.edu> <83986@tut.cis.ohio-state.edu> <14646@cbmvax.commodore.com> <1089@ucsvc.ucs.unimelb.edu.au> <523@public.BTR.COM> Lines: 48 I've always envisioned a scheme like this: char **Lines; long **Storage; long NumLines; long MaxLines; Basically, Lines points to an array of pointers to each line in the file. NumLines specifies the number of lines in the file and MaxLines specifies the maximum number of entries in the Lines & Storage arrays that have been allocated (determines when you have to reallocate Lines due to extending past the MaxLines limit). Storage points to the file position in either the original file or a scratch file. Unmodified line, line not in memory Lines[i] = NULL; Storage[i] = seek-position-in-original-file Modified line, line not in memory Lines[i] = NULL; Storage[i] = 0x80000000 | seek-position-in-scratch-file Unmodified line, line in memory Lines[i] = Storage[i] = seek-position-in-original-file Modified line, line in memory Lines[i] = Storage[i] = 0x80000000 | seek-position-in-scratch-file In anycase, all that would be required to remain in main memory is NumLines * 8 bytes. You also get random access out of this scheme. Additionally, you could implement a locking system (lock line in memory) internally to make editor functions more efficient. The scratch file would slowly fill up with changes and, upon reaching a certain size, would be 'packed' by creating a new scratch file, copying pertainent entries, and deleting the old. -Matt -- Matthew Dillon dillon@Overload.Berkeley.CA.US 891 Regal Rd. uunet.uu.net!overload!dillon Berkeley, Ca. 94708 USA