hi there I was discussing with jenner and kobold this bug.
Here is how I understand this bug: someone sets a restrictive umask and then calls mkzopeinstance.py and then runs zope and fails .... well.... I dont see this as really a bug in zope ... indeed, it is up to the user to choose an umask as they see fit; in my view, it mkzopeinstance.py would change the umask and disrespecting the umask of the user calling mkzopeinstance.py, this may be worse than the current situation. For example, suppose one user sets the umask for a good reason , 'cos he needs a very restricted zope instance ... and we open it up I propose : not to change the umask inside mkzopeinstance.py (or whatever is used in the newer zope); I suggest that mkzopeinstance.py will issue a warning if the umask is too restrictive to correctly run zope without some changes. a. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
