home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / unix / wizards / 4765 < prev    next >
Encoding:
Text File  |  1992-11-17  |  1.2 KB  |  27 lines
  1. Newsgroups: comp.unix.wizards
  2. Path: sparky!uunet!charon.amdahl.com!pacbell.com!ames!ncar!uchinews!machine!chinet!les
  3. From: les@chinet.chi.il.us (Leslie Mikesell)
  4. Subject: Re: The Problem with UNIX
  5. Message-ID: <Bxvws6.IsF@chinet.chi.il.us>
  6. Organization: Chinet - Public Access UNIX
  7. References: <1992Nov9.172715.16367@cs.wisc.edu> <1992Nov14.151318.1376@global.hacktic.nl> <1992Nov17.132517.9313@thunder.mcrcim.mcgill.edu>
  8. Date: Tue, 17 Nov 1992 23:48:05 GMT
  9. Lines: 16
  10.  
  11. In article <1992Nov17.132517.9313@thunder.mcrcim.mcgill.edu> mouse@thunder.mcrcim.mcgill.edu (der Mouse) writes:
  12.  
  13. >That's a point.  They should have had the guts to dump creat() when
  14. >they folded it into open().  (Or are you saying they shouldn't have
  15. >extended open?  Would you prefer to have a separate syscall for each
  16. >permutation of flag bits in the second argument to current open()?)
  17.  
  18. I'd prefer to have more arguments - for example to control locking the
  19. file atomically with the open().  It just seems so inelegant to open
  20. a file, possibly creating it, and then to have to fight with other
  21. processes over who has control of it.  And the traditional unix solution
  22. of using separate lockfiles has a worse problem: there's no way to
  23. remove a stale one safely.
  24.  
  25. Les Mikesell
  26.   les@chinet.chi.il.us
  27.