Path: utzoo!attcan!uunet!bu.edu!rpi!zaphod.mps.ohio-state.edu!samsung!cs.utexas.edu!rutgers!cbmvax!andy From: andy@cbmvax.commodore.com (Andy Finkel) Newsgroups: comp.sys.amiga.tech Subject: Re: Files larger than available memory. Message-ID: <14703@cbmvax.commodore.com> Date: 27 Sep 90 21:33:25 GMT References: <924@ucsvc.ucs.unimelb.edu.au> <1990Sep23.174736.16118@lavaca.uh.edu> <83986@tut.cis.ohio-state.edu> <14646@cbmvax.commodore.com> <14669@cbmvax.commodore.com> Reply-To: andy@cbmvax.commodore.com (Andy Finkel) Organization: Commodore, West Chester, PA Lines: 39 In article mwm@raven.pa.dec.com (Mike (My Watch Has Windows) Meyer) writes: >In article <14669@cbmvax.commodore.com> andy@cbmvax.commodore.com (Andy Finkel) writes: >Is that on the device the file is on, or on the device the text editor >was started from? And it's sort of silly if you that device winds up >being ram:. Likewise, you have to deal with being able to write on >that file. Since mg isn't part of a commercial product, I'm tempted to Its :t relative to the current directory, actually. I'd suggest :t relative to current directory, falling back to :t on the same volume as the source file if there's not enough space in the first choice volume. This neatly avoids the ram: problem, since RAM: is always 100% full. (actually, you could also try the same volume first, falling back to relative to the current directory; that would work out too) andy >make this feature something you have to enable at compile time, and if >it's on, allow the user to give a file name for the disk buffer file. That wouldn't be that bad either. > > Thanx, >