eggert@twinsun.com (Paul Eggert) (04/20/91)
rhartman@thestepchild.sgi.com (Robert Hartman) writes: >BTW, does this imply that SCCS and RCS can also fail over NFS? >I'm not aware of them using the NFS lock manager! I don't know about SCCS, but RCS 5.5 uses a slightly different technique. The lock file never exists in writable form, avoiding the NFS protocol bug that Jonathan Kamens described. A similar method can be used in the shell. For example (Bourne shell): if (umask 777; echo >lock) then Perform whatever operation required locking. rm -f lock else Report that you could not obtain the lock. fi
chip@tct.com (Chip Salzenberg) (04/22/91)
According to eggert@twinsun.com (Paul Eggert): >For example (Bourne shell): > > if (umask 777; echo >lock) > then > Perform whatever operation required locking. > rm -f lock > else > Report that you could not obtain the lock. > fi Unfortunately, this method is still prone to spurious failure when an imperfect network loses the ACK from the initial creation attempt. "NFS: We Bring Net Errors To Life." -- Brand X Industries Custodial, Refurbishing and Containment Service: When You Never, Ever Want To See It Again [tm] Chip Salzenberg <chip@tct.com>, <uunet!pdn!tct!chip>
les@chinet.chi.il.us (Leslie Mikesell) (04/23/91)
In article <28124072.1774@tct.com> chip@tct.com (Chip Salzenberg) writes: >>For example (Bourne shell): >> >> if (umask 777; echo >lock) >> then >> Perform whatever operation required locking. >> rm -f lock >> else >> Report that you could not obtain the lock. >> fi > >Unfortunately, this method is still prone to spurious failure when an >imperfect network loses the ACK from the initial creation attempt. Spurious failure is not nearly as bad a problem as spurious success when creating a lockfile. However, won't this always break when run by root? Les Mikesell les@chinet.chi.il.us
rhartman@thestepchild.sgi.com (Robert Hartman) (04/24/91)
In article <1991Apr22.175620.8054@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: >In article <28124072.1774@tct.com> chip@tct.com (Chip Salzenberg) writes: >>>For example (Bourne shell): >>> >>> if (umask 777; echo >lock) >>> then >>> Perform whatever operation required locking. >>> ... >> >>Unfortunately, this method is still prone to spurious failure when an >>imperfect network loses the ACK from the initial creation attempt. > > > ... However, won't this always break when run by root? > >Les Mikesell > les@chinet.chi.il.us Hmm. Seems to fail when I run it as root. For a while this example had me stymied because it seemed to belie my earlier contention that deletion/truncation is a separate type of file access. If write permission could protect a file from truncation, then my thinking said that perhaps denying write permission would be sufficient to cover cases of truncation, and denying write permission on the directory would be sufficient to cover cases of deletion (even though rm -f overrides it, but then, you're suppoed to know what you're doing, right?). However, write permission does not protect a file from truncation by root. Perhaps it should. But I'm sure there are good reasons why it doesn't. And, it also can be argued that protecting a file from spurious deletion is not the job of a directory's permission bits. It ought to be the job of the file's permission bits. Also, although truncation can be considered a form of "writing" on a file, it is of a different sort than editing. It could go either way, but functionally, from the user's standpoint, truncation is more closely related to deletion than it is to editing, even if, from the OS's standpoint, it is implemented as a write operation. So, I'm back to the opinion that deletion/truncation is a separate type of file access, and should (someday) be protected by it's own set of permission modes. I'm not, however, holding my breath. All this is IMHO. -r