home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / unix / wizards / 5281 < prev    next >
Encoding:
Internet Message Format  |  1992-12-21  |  1.7 KB
  1. Path: sparky!uunet!think.com!barmar
  2. From: barmar@think.com (Barry Margolin)
  3. Newsgroups: comp.unix.wizards
  4. Subject: Re: /dev/null and file locking
  5. Date: 19 Dec 1992 02:22:38 GMT
  6. Organization: Thinking Machines Corporation, Cambridge MA, USA
  7. Lines: 26
  8. Message-ID: <1gu11eINN4tn@early-bird.think.com>
  9. References: <15945@auspex-gw.auspex.com> <1992Dec18.182107.22098@zeus.ieee.org>
  10. NNTP-Posting-Host: gandalf.think.com
  11.  
  12. In article <1992Dec18.182107.22098@zeus.ieee.org> jbarth@ep.ieee.org writes:
  13. >I recall reading in Bach's "The Design of the UNIX Operating System" that
  14. >device inodes, unlike regular inodes, are never locked.  I don't remember
  15. >what the rationale was -- perhaps someone more knowledgeable than me could 
  16. >comment.
  17.  
  18. The locking operations lock a specific range of bytes of a file.  Some
  19. devices, like tty's, simply present data continuously, and have no
  20. meaningful notion of offsets into the file.
  21.  
  22. However, this should only be a problem for mandatory locking, since the
  23. kernel tries to relate the locks to the read() and write() operations.  In
  24. the case of advisory locks they only interact with other locking
  25. operations, so the ranges could be considered as arbitrary identifiers,
  26. with no necessary relationship to the file contents.
  27.  
  28. It sure would be nice if you could lock devices, though.  The lack of this
  29. forces many applications to create extraneous files just to mediate access
  30. to a device.  An example is the locking files in /usr/spool/uucp.  And if
  31. two applications try to use the same device but have different lock file
  32. conventions, they don't work together properly.
  33. -- 
  34. Barry Margolin
  35. System Manager, Thinking Machines Corp.
  36.  
  37. barmar@think.com          {uunet,harvard}!think!barmar
  38.