home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / os / linux / 22296 < prev    next >
Encoding:
Text File  |  1992-12-31  |  2.1 KB  |  46 lines
  1. Newsgroups: comp.os.linux
  2. Path: sparky!uunet!math.fu-berlin.de!news.th-darmstadt.de!mnl
  3. From: mnl@dtro.e-technik.th-darmstadt.de (Michael N. Lipp)
  4. Subject: How can I invalidate a block device buffer?
  5. Sender: news@news.th-darmstadt.de (The News System)
  6. Message-ID: <MNL.92Dec31210305@mnlsun.dtro.e-technik.th-darmstadt.de>
  7. Date: Thu, 31 Dec 1992 21:03:05 GMT
  8. Nntp-Posting-Host: mnlsun.dtro.e-technik.th-darmstadt.de
  9. Organization: TH-Darmstadt
  10. Lines: 34
  11.  
  12. I'm using Linux .99p1. Its really great. Yet, I have a problem. 
  13.  
  14. I have written a program `mfcp' that can copy files larger than a
  15. single floppy on several floppies, breaking it up in chunks of (floppy
  16. size - 1 sec).  (The one sector is used for a header, counting the
  17. floppies, etc.) I have used this program without problems for the last
  18. years on a Sun and with Interactive Unix, using the raw floppy device.
  19.  
  20. There is no raw floppy device in Linux (right?, I didn't find any).
  21. So I changed the program to handle a floppy device opened as block
  22. device. There remains one problem: In order to verify that the floppy
  23. was written correctly, my program re-reads it. It seems that Linux
  24. keeps the floppy contents buffered although the floppy device has been
  25. closed after the write and reopened for the verify pass (the floppy
  26. LED blinks once when the device is reopened, but all subsequent reads
  27. are satisfied from some buffer). Of course, this is "legal" if a
  28. change of floppy is detected and the buffer invalidated in that case
  29. (which, I think is done by Linux). In my program, however, it should
  30. not be necessary that the user ejects the floppy after the write and
  31. re-inserts it for the verify.
  32.  
  33. Is there any way to invalidate the buffer? I would prefer that to
  34. writing the raw device driver :-).
  35.  
  36. Michael
  37.  
  38.  
  39. --
  40. -----------------,------------------------------,------------------------------
  41. Michael N. Lipp  !  Institut fuer Datentechnik  !  Phone: 49-6151-163776
  42.                  !  Merckstr. 25     ,----------'  Fax:   49-6151-164976
  43.                  !  D-6100 Darmstadt ! E-Mail:
  44.                  !  (Germany)        !     mnl@dtro.e-technik.th-darmstadt.de
  45. -----------------'-------------------'-----------------------------------------
  46.