Date: Thu, 31 Oct 1996 13:59:28 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: MRC@Panda.COM (Mark Crispin) Cc: terry@lambert.org, gpalmer@FreeBSD.org, jgreco@brasil.moneng.mei.com, j@uriah.heep.sax.de, roberto@keltia.freenix.fr, current@FreeBSD.org, scrappy@ki.net Subject: Re: /var/mail (was: re: Help, permission problems...) Message-ID: <199610312059.NAA26174@phaeton.artisoft.com> In-Reply-To: <MailManager.846791961.5917.mrc@Ikkoku-Kan.Panda.COM> from "Mark Crispin" at Oct 31, 96 11:59:21 am
next in thread | previous in thread | raw e-mail | index | archive | help
> On Thu, 31 Oct 1996 11:29:55 -0700 (MST), Terry Lambert wrote: > > It's possible to test the failure case during > > config by compiling up a small test program. > > How do you test the failure case during config for a mailbox accessed in the > future? Well, my personal opinion is that it should be runtime, not build-time, configured. Failing that, you could look at /var/mail with stat and look at st_dev to see if it was NFS and the permissions to see if they will let your users create .lock files successfully. You may not be able to know that fcntl() *will* work, but you can know .lock files *won't* work. > Please explain how config will know what sort of systems you will access over > NFS in the future. The same way your config knows that the remotely mounted /var/mail that will be accessed in the future is mode 1777. 8^). Again, I would prefer runtime configuration. If nothing else, because I use AMD to relocate my mail files to user accounts, and some are local and some are NFS mounted. > The majority of UNIX systems in the world do not use system call locking. > They use lock files. Some BSD variants once used system call locking, but > gave up because of the need to support NFS. > > Please explain how FreeBSD, perhaps the only system in the world that still > uses system call locking, is going to get the world to convert. By publicising the fact that fcntl and flock locking are available on all POSIX conformant and POSIX compliant systems, and that POSIX strictly mandates how an FS must act, and NFS is an FS? > Once again, this issue is not about whether or not my code supports system > call locking. It does. Already. And it has for many years. > > This issue is about whether or not my code should try to use lock files too, > and what should happen if it can't. There are only two choices: > 1) give a warning message, which is annoying if you are a FreeBSD > system, everything is on the FreeBSD system, and you know that it > is safe not to bother with lock files. > 2) don't give a warning message, which on 99% of the systems in the > world means that locking has failed for real and the user is > vulnerable to data corruption. > > 99% is conservative. FreeBSD is much less than 1% of the UNIX market. Actually the question is where there will be a BSD4.4-Lite specific #ifdef for the default FreeBSD configuration to avoid the warning so that we don't have to hack around the warning using "port" code. Your answer was that you weren't going to put in a BSD4.4-Lite specific #ifdef because you thought that BSD should be dragged back into the dark ages of non-working POSIX mandated system calls because everyone else was still back there. Frankly, you might as well ask the BSD community to also remove RFC 1323 and RFC 1644 "Transaction TCP" support because most older systems fail to implement TCP/IP option negotiation in compliance with the non extended standards. After all, having your NFS mount of your mail spool lock up your mail program during use has to be much worse than the lock failure (which only causes damage in the rare conflict case instead of all the time, like an NFS lockup would). > Give me one good reason why I should let 1% of the market tell me that I > should do something that puts 99% of the market at risk. Because fcntl() should work, and removing the incentive to fix fcntl() is not an effective means of moving forward. The same reason that RFC 1323 and 1644 are "on" by default in BSD 4.4: to make people with non-standards-compliant implementations fix them instead of forcing applications vendors (like yourself) to live without. > Give me one good reason why, given that you've been told how to take > the risk by building it to quell the warning, you are still bothering > me. Because the program should build out of the box for the most correct configuration for the system it is being built for. For BSD systems, this means not putting out the warning as a result of an intentional system configuration by the vendor (the dfault mode of the mail directory). Alternately, your install should check the mode and ask if you want to change the mode (not recommended, since the directory is a system component) or disable the warning (recommended; we must assume the vendor set the modes intentionally, and changing the mode might break other software). Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199610312059.NAA26174>