>> But ... why? I mean, seriously. That means that people who use >> system-provided nmh packages lose. I always thought compile-time >> configuration was something that was to be avoided. What exactly is >> your beef with making it runtime configurable? > >Code complexity.
Fair enough ... but the most complexity really comes from the run-time code selection, and that's already in place. >> And how come you're bringing this up NOW, instead of when we hashed >> this all out in March? > >Because I hadn't run across the current Solaris 11 behaviour. Which >would have pushed the point a lot harder. I didn't like it back then, >but I didn't have a definitive example of where it would break things. >Now I do. Alright. I could be persuaded to be neutral on this if you really object that much (although, I can't really see the harm of keeping the runtime configuration around ... it seemed like there was enough confusion about the right locking protocol to use on an NFS-mounted mail spool that there was some value there). But I do have a practical question about the use of the maillock functions you posted. Right now you can "inc" any file, and nmh doesn't know that the file is a mail spool; it just knows there's a default file to inc from. The maillock() functions you posted only take a username as an argument, and obviously they're only appropriate for locking the actual spool file. To make that work properly you're going to have to add some code in there to distinguish between opening a spool file and some other, random file. Also I suppose technically you need to be sure that you're not opening some other mailbox that's not your own (I don't know how common that is). None of those things are impossible, but it's going to be a bit of a mess. >Regardless, the mbox locking needs to be completely divorced from the >rest of the nmh locking. There is too much ambiguity in the code to >believe that we are doing either side of it correctly. I guess I don't understand this statement. What ambiguity are you talking about? --Ken _______________________________________________ Nmh-workers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/nmh-workers
