guy@SUN.COM (Guy Harris) (03/15/88)
If someone were to do this now, I'd strongly recommending providing the choice between flock() and fcntrl(), since fcntrl() is (coincidentally) the only environment-independent locking mechanism for both SunOS and OSx. "flock()" works exactly the same in both environments in SunOS. However, it does not work over NFS in either environment; you can lock a file that's being accessed over NFS, but it will only affect processes on the machine where the "flock()" was done. "fcntl()" locking, which also works exactly the same in both environments in SunOS, uses the Lock Manager and maintains locks for a file on the server holding that file, so if you use "fcntl()" to lock a file it will affect all processes doing "fcntl()" locks on that file.
csg@pyramid.pyramid.com (Carl S. Gutekunst) (03/29/88)
(Cross posted to comp.mail.uucp because of the general issue of lock files.) In article <476@tness1.UUCP> unsegh@swbt.com (Greg Hackney) writes: >Do the OSx 4.1 uucp programs use flock() ? I just reread this, and I'm not sure if you mean mailers or UUCP. For mailers see my previous message in comp.sys.pyramid. UUCP uses lock files, like it always has. Too many things would break if it were changed to use flock(). The difference between universes is that: - ucb (4.3BSD UUCP) uses a separate subdirectory, /usr/spool/uucp/LCK, to hold lock files. The contents of the lock file is the PID, in binary, of the uucico process that created the lock. The use of the subdirectory is a com- pile-time option, and I chose to put it in since that allows you to use 755 modes in /usr/spool/uucp, and 777 modes on /usr/spool/uucp/LCK. - old att (SVR2.2 UUCP) puts the lock files directly in /usr/spool/uucp. Their contents is identical to that of 4.3BSD. Note that OSx 4.1 is shipped with SVR2.2 UUCP hidden away in /usr/.attold, and will soon be moved to an option tape. - new att (Basic Networking Utilities, aka HoneyDanBer) puts locks in the di- rectory /usr/spool/locks. The contents of the lock files is the uucico PID in ASCII, right justified in a 10-character field, terminated by a newline. I modified both 4.3BSD and HDB to recognize each others lock files, and set up OSx 4.1 with a symbolic link from /usr/spool/locks to /usr/spool/uucp/LCK. So you can run them concurrently. (At least one site, though, has complained that they stomp each other when run out of the same /usr/spool/uucp. That site set up separate /usr/spool/.attuucp and /usr/spool/.ucbuucp directories, joined at /usr/spool/uucp by a conditional symbolic link.) <csg>
mechjgh@tness7.UUCP (Greg Hackney ) (03/30/88)
I certainly appreciate all the recent postings about the mail and uucp characteristics on the Pyramid, especially Carl's info. In article <17784@pyramid.pyramid.com> csg@pyramid.pyramid.com (Carl S. Gutekunst) writes: >I just reread this, and I'm not sure if you mean mailers or UUCP. I meant UUCP. We are using 2 modified versions of HDB "cu". One has file capture features, the other one executes a script file for automatic logon and command execution. I had some trouble with the lock files. It turned out to be the fact that the att universe uses ASCIILOCKS, and the ucb universe uses binary locks. My att programs were trashing the Berkeley locks, so I had to modify the progs to recognize them. I asked the question about flock() at first suspecting it. Problem solved. Our machine is the one that split the /usr/spool/uucp directories into 2 universes: We are using all the mail facilities on both universes. Some of the supporting administrative files, i.e. cleanup programs, status programs, interfered with each other in the differrent universes. Splitting them seems to have solved all the problems, and it took 20 seconds to do. There was also a problem that the ucb universe creates new mail files with a mode of 600, and the att, a mode of 660. So, the att people can't read their mail from ucb people. This was fixed by installing smail 2.5 on the att side, and having sendmail call smail. (Honey's shell script in smail 2.5 that builds sendmail.cf files was a big help for a sendmail novice.) >UUCP uses lock files, like it always has. Too many things would break if it >were changed to use flock(). Thanks Carl. That answered my original question. It is a terrible thing to not have access to the Pyramid source code, but we are working on it. If anyone modifies the ELM code for flock(), I would appreciate a copy of the affected files. Our Elm 1.5 is highly hacked over, so mods in any condition would be fine. -- Greg
mechjgh@tness7.UUCP (Greg Hackney ) (03/30/88)
In article <28@tness7.UUCP> I write: >There was also a problem that the ucb universe creates new >mail files with a mode of 600, and the att, a mode of 660. So, >the att people can't read their mail from ucb people. I didn't say that correctly... If the mail file has a mode of 600, the incoming att mail can't write in the mail file, since att mail needs a mode of 660, with a group permissions of "mail". (I should have said, I can read my mail, but att users can't send me mail.) (I sent this info to pyramid!bugs). -- Greg