userBARD@mts.ucs.UAlberta.CA (Barry Ard) (10/31/90)
I'm using TC++ 1.0 and am fopen()'ing a file that I write to using fwrite(), I then do an fflush(), and as a test I reboot via the 3 finger salute (ctrl-alt-del). When I check the file the fwrite() didn't happen. It is my understanding that the fflush() should force the buffers to be written to disk. Am I mistaken? I don't want to have to open, write, close, the re-open the file, it seems so kludgy and defeats the purpose of why I am flushing in the first place. -------------------------------------------------------------------------- "So long Grizzly dudes", Bart Simpson Barry Ard | uucp: ..!alberta!uqv-mts!userbard University Computing Systems | inet: userbard@mts.ucs.ualberta.ca University of Alberta | bitnet: userbard@ualtamts.bitnet Edmonton, Alberta | bard@ualtavm
emmo@moncam.co.uk (Dave Emmerson) (11/26/90)
In article <1778@mts.ucs.UAlberta.CA>, userBARD@mts.ucs.UAlberta.CA (Barry Ard) writes: > I'm using TC++ 1.0 and am fopen()'ing a file that I write to using > fwrite(), I then do an fflush(), and as a test I reboot via the 3 finger > salute (ctrl-alt-del). When I check the file the fwrite() didn't > happen. Heh, I got burned by that one too. Problem is, fflush doesn't flush the DOS buffers to disk, so you need to do : FILE *stream ; int fhandle ; .... fflush(stream) ; fhandle = dup(fileno(stream)) ; close(fhandle) ; .... Its messy, but it'll fix it for you. Note that stream remains open, but the buffers have been flushed, and the FAT updated. ATB, Dave E.
valley@uchicago (Doug Dougherty) (11/27/90)
emmo@moncam.co.uk (Dave Emmerson) writes: >Heh, I got burned by that one too. >Problem is, fflush doesn't flush the DOS buffers to disk, so >you need to do : >FILE *stream ; >int fhandle ; >.... >fflush(stream) ; >fhandle = dup(fileno(stream)) ; >close(fhandle) ; >.... >Its messy, but it'll fix it for you. Note that stream remains >open, but the buffers have been flushed, and the FAT updated. >ATB, >Dave E. Incidentally, there is a "Commit File" system call in DOS 3.3+ Supposed to be the bestest, fastest way to do it.
ho@hoss.unl.edu (Tiny Bubbles...) (11/27/90)
In <1020@marvin.moncam.co.uk> emmo@moncam.co.uk (Dave Emmerson) writes: >In article <1778@mts.ucs.UAlberta.CA>, userBARD@mts.ucs.UAlberta.CA (Barry Ard) writes: >> I'm using TC++ 1.0 and am fopen()'ing a file that I write to using >> fwrite(), I then do an fflush(), and as a test I reboot via the 3 finger >Problem is, fflush doesn't flush the DOS buffers to disk, so Is this a problem in Turbo C 2.0 also, or is it just an artifact of Turbo C++ 1.0[1]? I'm curious if I need to go recoding all of my fflush()es (probably aren't too many, but just to be safe...) -- ... Michael Ho, University of Nebraska Internet: ho@hoss.unl.edu | "Mine... is the last voice that you will ever hear."
b-davis%cai.utah.edu@cs.utah.edu (Brad Davis) (11/27/90)
In article <1990Nov26.164656.858@hoss.unl.edu> ho@hoss.unl.edu (Tiny Bubbles...) writes: >>Problem is, fflush doesn't flush the DOS buffers to disk, so > >Is this a problem in Turbo C 2.0 also, or is it just an artifact of >Turbo C++ 1.0[1]? Artifact of MS-DOS from 1.0 to 3.2. As was mentioned, 3.3 has a call to do this, but then again, we can all write software that only needs to run on 3.3. -- Brad Davis ..!uunet.uu.net!cs.utah.edu!cai.utah.edu!b-davis b-davis@cs.utah.edu, b-davis@cai.utah.edu One drunk driver can ruin your whole day.
w8sdz@vela.acs.oakland.edu (Keith Petersen) (11/27/90)
I sent the original posting to a friend who works for Borland. Here is his answer. "fflush is doc'd as flushing the stream's internal buffer, but not forcing the DOS buffers to be flushed. In fact the online help for fflush shows the hack using dup in its example of how to use fflush." He says that Borland will be on the Internet next month, which is good news. Keith -- Keith Petersen Maintainer of SIMTEL20's MSDOS, MISC & CP/M archives [IP address 26.2.0.74] Internet: w8sdz@WSMR-SIMTEL20.Army.Mil or w8sdz@vela.acs.oakland.edu Uucp: uunet!umich!vela!w8sdz BITNET: w8sdz@OAKLAND
Ralf.Brown@B.GP.CS.CMU.EDU (11/27/90)
In article <valley.659637095@gsbsun>, valley@uchicago (Doug Dougherty) wrote: }Incidentally, there is a "Commit File" system call in DOS 3.3+ }Supposed to be the bestest, fastest way to do it. Interestingly enough, there is an undocumented "Commit ALL Files" system call in DOS 3.0+ (INT 21/AX=5D01h). -- UUCP: {ucbvax,harvard}!cs.cmu.edu!ralf -=- 412-268-3053 (school) -=- FAX: ask ARPA: ralf@cs.cmu.edu BIT: ralf%cs.cmu.edu@CMUCCVMA FIDO: 1:129/3.1 Disclaimer? | I was gratified to be able to answer promptly, and I did. What's that? | I said I didn't know. --Mark Twain
bmarsh@cod.NOSC.MIL (William C. Marsh) (11/28/90)
In article <1990Nov26.185230.13800@hellgate.utah.edu> b-davis%cai.utah.edu@cs.utah.edu (Brad Davis) writes: >In article <1990Nov26.164656.858@hoss.unl.edu> ho@hoss.unl.edu (Tiny Bubbles...) writes: >>>Problem is, fflush doesn't flush the DOS buffers to disk, so >>Is this a problem in Turbo C 2.0 also, or is it just an artifact of >>Turbo C++ 1.0[1]? >Artifact of MS-DOS from 1.0 to 3.2. As was mentioned, 3.3 has a call >to do this, but then again, we can all write software that only needs >to run on 3.3. An even easier way to do this is to dup() and then close() the filehandle associated with the stream. This has worked since version 2.0 of MS-DOS. You do need an open filehandle to do this, however... i.e. fflush(stream); close(dup(fileno(stream))); Bill -- Bill Marsh, Naval Ocean Systems Center, San Diego, CA {arpa,mil}net: bmarsh@cod.nosc.mil uucp: {ihnp4,akgua,decvax,dcdwest,ucbvax}!sdcsvax!nosc!bmarsh "If you are not part of the solution, you're part of the problem..."
granoff@vaxwrk.enet.dec.com (Mark H. Granoff) (11/28/90)
In article <1778@mts.ucs.UAlberta.CA>, userBARD@mts.ucs.UAlberta.CA (Barry Ard) writes: >... Am I mistaken? I don't want to have to >open, write, close, the re-open the file, it seems so kludgy and >defeats the purpose of why I am flushing in the first place. As a matter of good programming, I would close the file explicitly before leaving the program. However, I see your point, and can't explain your results. Perhaps its a bug, which ought to be reported. --------------------------------------------------------------------------- Mark H. Granoff | Enterprise Integration Services/Engineering VAXworks --------------------------------------------------------------------------- Digital Equipment Corporation | ARPAnet: granoff@vaxwrk.enet.dec.com 129 Parker Street | Usenet : ...!decwrl!vaxwrk.dec.com!granoff PKO2-1/M21 | AT&T : +1 508 493 4512 Maynard, MA 01754 | FAX : +1 508 493 2240 --------------------------------------------------------------------------- Opinions herein are my own and do not necessarily reflect those of Digital. ---------------------------------------------------------------------------
scjones@thor.UUCP (Larry Jones) (11/29/90)
In article <1020@marvin.moncam.co.uk>, emmo@moncam.co.uk (Dave Emmerson) writes: > In article <1778@mts.ucs.UAlberta.CA>, userBARD@mts.ucs.UAlberta.CA (Barry Ard) writes: > > I'm using TC++ 1.0 and am fopen()'ing a file that I write to using > > fwrite(), I then do an fflush(), and as a test I reboot via the 3 finger > > salute (ctrl-alt-del). When I check the file the fwrite() didn't > > happen. > > Problem is, fflush doesn't flush the DOS buffers to disk, so > you need to do : It may be worth noting that this is the standard behavior for fflush. fflush is a >C< library function that flushes the >C< library's buffers. I know of NO systems where it also causes the file system / operating system buffers to be flushed as well. ---- Larry Jones UUCP: uunet!sdrc!thor!scjones SDRC scjones@thor.UUCP 2000 Eastman Dr. BIX: ltl Milford, OH 45150-2789 AT&T: (513) 576-2070 Santa's gonna skip this block for years. -- Calvin
mhg@lance.hss.bu.oz.au (Miles Gillham) (11/29/90)
In article <1778@mts.ucs.UAlberta.CA> userBARD@mts.ucs.UAlberta.CA (Barry Ard) writes: >... >happen. It is my understanding that the fflush() should force the buffers >to be written to disk. Am I mistaken? I don't want to have to >open, write, close, the re-open the file, it seems so kludgy and >defeats the purpose of why I am flushing in the first place. You are not mistaken that the flush forces the buffers to disk but it takes a close or something better to make sure that the DOS dir and FAT info is also committed. The "something better" is a DOS call introduced in version 3.3 by the name of "68h Commit File". It was added to DOS for the very reason of avoiding a close/open sequence every time you wanted to force the data to be persistent in the case of some disaster. You will need to set up a DOS INT 21h call with the following registers on entry: AX - 68h BX - DOS File Handle No return values except normal DOS error codes. Regards, Miles of Smiles -- Language Centre E-mail: mhg@lance.hss.bu.oz.au Bond University, Gold Coast, QLD 4229 Phone: +61 75 952524 Australia Fax: +61 75 952545
keating@motcid.UUCP (Edward Keating) (11/30/90)
In article <2493@cod.NOSC.MIL>, bmarsh@cod.NOSC.MIL (William C. Marsh) writes: > > An even easier way to do this is to dup() and then close() the filehandle > associated with the stream. This has worked since version 2.0 of MS-DOS. > You do need an open filehandle to do this, however... > > fflush(stream); > close(dup(fileno(stream))); > This solution will only work for a non-networked version of DOS. It seems that some network implementations (3+) cache the duplicate open and do not flush the information to disk. I had put this identical code into a networked PC environment and then found out that it was non-functional. The most notable problem in this area is that the file length doesn't get written to disk until an the close is performed. The DOS 3.3 and above Flush command is equivalent to an atomic close and re-open that will not allow any other network used to open the file in the window between the close and open. Performing the close and open discretely will flush the information to disk. If you need a lock to prevent others from opening the file, you can use a logical semaphore by using a create file/delete file. i.e. First one to creat a common file name has the resource until he deletes the file. This technique works on a number of different operating systems. -- Ed Keating, Motorola C.I.D, 1501 W. Shure Drive uunet!motcid!keating Arlington Heights, Il 60004 If they revoke the right to assemble, then we can only compile, right?