home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / os / msdos / programm / 11887 < prev    next >
Encoding:
Text File  |  1993-01-07  |  1.8 KB  |  46 lines

  1. Path: sparky!uunet!dtix!darwin.sura.net!gatech!usenet.ins.cwru.edu!agate!boulder!csn!evolving.com!judy
  2. From: judy@evolving.com (Judy Bettinger)
  3. Newsgroups: comp.os.msdos.programmer,comp.windows.ms.programmer
  4. Subject: Trouble with I/O commit()
  5. Summary: low-level I/O not writing directly to disk
  6. Message-ID: <1993Jan07.194311.2147@evolving.com>
  7. Date: 7 Jan 93 19:43:11 GMT
  8. Organization: Evolving Systems, Inc.
  9. Lines: 35
  10.  
  11.  
  12.  
  13. Does anyone now of a way to force the low-level C write() function to flush
  14. the buffer to the disk?  A call to commit() isn't doing anything.
  15.  
  16. Details:
  17.  
  18. Our environment is Windows 3.1 running under MS-DOS 5.0 and we're using
  19. Microsoft C 7.00.  The routine we're trying to write just runs in a DOS
  20. window.  The write() call is embedded in a database package
  21. called CBase, but we do have the source -- that's how I've been able
  22. to experiment with it.  I've been testing by running the process that 
  23. does the writing in a Codeview window and just doing 'type' from another
  24. DOS window.
  25.  
  26. What we've tried so far:
  27.  
  28. First, we checked to see if good 'ol stream I/O (fopen, etc.) would
  29. successfully do an fflush().  We finally discovered (no thanks to the
  30. Microsoft support line) , that we needed to call fopen with
  31. the "c" option and bind in commode.obj.  No problem, stream I/O will now
  32. flush properly.  However, when we switch back to cbase, which uses the low-
  33. level routines, we don't see anything written out until we close the file. 
  34. We've tried not running smartdrv and I added a call to commit() to the 
  35. write routine, but no luck.
  36.  
  37. I had thought that the low-level routines didn't buffer in the first place, 
  38. but it 'pears I was mistaken.
  39.  
  40. Anybody got any ideas?
  41. -- 
  42. #include <std_disclaimer.h>
  43. Judy Bettinger  (judy@evolving.com)
  44. Evolving Systems, Inc.
  45. Denver, Colorado
  46.