zgel05@apctrc.UUCP (George E. Lehmann) (07/07/88)
Tulsa, Oklahoma Keywords: Does anyone have any experience with maintaining file integrity on a DOS system during extreme conditions such as power failure or users rebooting the system? Doesn't DOS buffer writes interminably beyond the normal C programmer's control, preventing my knowing what has actually made it out to disk? What about techniques for making linked lists and such survive these calamaties? Thanks in advance for any answers... -- George Lehmann, ...!uunet!apctrc!zgel05 Amoco Production Co., PO BOX 3385, Tulsa, Ok 74102 ph:918-660-4066 Standard Disclaimer: Contents are my responsibility, not AMOCO's.
Ralf.Brown@B.GP.CS.CMU.EDU (07/07/88)
In article <472@apctrc.UUCP>, zgel05@apctrc.UUCP (George E. Lehmann) writes: } Doesn't DOS buffer writes interminably beyond the normal C }programmer's control, preventing my knowing what has actually made it out }to disk? Yes, it can and does, but only if both of the following conditions are met: a. the file remains open b. no call to INT 21h/AH=0Dh (DISK RESET) is made DOS writes out any buffered data if the file is closed, and also when it is told to reset the disk subsystem. You can thus force the data to be written by closing and reopening the file (which also updates the file's directory entry, something that DISK RESET doesn't do). Since opening a file is expensive, you can make a duplicate of the file handle and close the duplicate, like so: void commit_file(int handle) { int new_handle = dup(handle) ; close(new_handle) ; } Note that DOS 3.3 finally has a function to write out a file's buffered data: INT 21 - DOS 3.3 - COMMIT FILE, WRITE ALL BUFFERED DATA TO DISK AH = 68h BX = file handle Return: carry flag set on error (and error code in AX) -- UUCP: {ucbvax,harvard}!cs.cmu.edu!ralf -=-=-=- Voice: (412) 268-3053 (school) ARPA: ralf@cs.cmu.edu BIT: ralf%cs.cmu.edu@CMUCCVMA FIDO: Ralf Brown 1:129/31 Disclaimer? I |Ducharm's Axiom: If you view your problem closely enough claimed something?| you will recognize yourself as part of the problem.
madd@bu-cs.BU.EDU (Jim Frost) (07/08/88)
In article <472@apctrc.UUCP> zgel05@apctrc.UUCP (George E. Lehmann) writes: |Does anyone have any experience with maintaining file integrity on a DOS |system during extreme conditions such as power failure or users rebooting |the system? Doesn't DOS buffer writes interminably beyond the normal C |programmer's control, preventing my knowing what has actually made it out |to disk? MS-DOS and most cache programs use "write-through" techniques, meaning that every write goes to the disk when it's made, with no buffering. Many languages buffer internally for speed advantages (C is definitely one of them), but you can override this buffering with a simple fflush on the standard functions. Some controllers may do real caching, but I haven't dealt with any. It's not the norm. Additionally I've seen drivers that allow it, but again it's not the norm. If you're worried about power outages, I'd suggest an uninterruptable power supply. They aren't cheap, but they're worth it if your data is important. |What about techniques for making linked lists and such survive these |calamaties? If you're talking about on-disk linked lists (I assume you are) then you should try hard to make sure all writes are actually made. Using the lowest level commands (eg open() close() read() write()) will insure this, but often at some speed penalties. Note, however, that it's pretty easy to recover most or all of a linked list in most cases, so even if you don't do physical writes all the time, it's quite likely that you could make an automatic restore utility. This is basically what CHKDSK is. jim frost madd@bu-it.bu.edu
dixon@zephyrus.steinmetz (Walter V. Dixon) (07/08/88)
Newsgroups: comp.sys.ibm.pc
Subject: Re: disk updates and power failures
Summary:
Expires:
References: <472@apctrc.UUCP>
Sender:
Reply-To: dixon@zephyrus.UUCP (Walter V. Dixon)
Followup-To:
Distribution:
Organization: General Electric CRD, Schenectady, NY
Keywords:
There are two levels of buffering. The C run time maintains internal
buffers and dos also maintains a buffer of disk blocks. Most C run
time libraries provide a mechanism for flushing the C buffers. DOS
uses its buffer cache for fat and directory blocks; the buffer cache
is also used for reading PARTIAL blocks. When a file is closed
DOS may update the directory entry from information contained in
SFT (see followup to 19371). The directory entry is marked dirty
and then all dirty blocks are flushed from the cache.
At any time issuing a disk reset forces a cache flush, but the
directory entry may not get updated. Duplicating a handle
and then closing the file will update the directory entry and
flush the buffer cache.
I hope this helps.
Walt Dixon {ARPA : dixon@ge-crd.com }
{US Mail: GE CRD }
{ PO Box 8 }
{ Schenectady NY 12345 }
{Phone : 518-387-5798 }bturner@hpcvlx.HP.COM (Bill Turner) (07/08/88)
There are two things that can be done to keep disk files updated correctly: 1) The SYNC call will flush the "dirty" disk buffers, but this doesn't update the file length in the directory. The data is there, but the dir entry has a different size. 2) You can close and reopen the file after each write. Don't laugh! This is the only way I know of using DOS (and not doing nasty things yourself) to force the file to be correctly updated to disk after each write. --Bill Turner HP Corvallis Workstation Operation "Every time I have to kill someone who's family, I get depressed." --Ferman Crotty (Ed Asner), "The Wild, Wild West"