OK, so apologies first:
Paul Winkler's comment in this thread was nearer the mark than Tres Seavers. clienthome is not relevant to where caches are created, and of course I need zeo-client-home.
Problem is now that zeo-client-home seems not to have the intended effect.
I set zeo-client-home to zeo1, in my first conf file and restart, but never see any cache files of that name.
I traced as far as the parse handler zeo_client_home. It's invoked with the correct value. But it stuffs the value into the env, and I can't see any other reference to ZEO_CLIENT pulling it back out of there again.
Working up the stack trace from ClientCache.py, where the files are created (*-None-*), my client value is always None, but there's a gap in the middle that I did not bridge, around BaseConfig and ZeoConfig.
Has anyone been successful naming cache files? I'm on OSX Panther 10.3.
I've traced through to the zeo_client_name handler, and see the name of
On 23 Jul 2004, at 21:37, Chris McDonough wrote:
On Fri, 2004-07-23 at 16:21, Tim Peters wrote:—————————————————————
self._f[current] = open(self._p[current],'w+b')
.... will be likely to fail at the last line if you're using
nonpersistent cache files, because self._p[current] is (bogus)
'1-None-0' (relative bogus filename).
Is it really *likely* to fail?
I suppose it depends on the working directory of the shell/process used
to start Zope. Zope doesn't mess with the working directory on its own,
If you follow Richard Stevens' ("UNIX Network Programming" guy,
apparently now dead) advice, he says that "well-behaved" daemon
processes should change their working directory to "/". So I suspect
there are daemonizers that do this.
Guido's zdrun daemon (which "zopectl" uses) gives you an option to set
the working directory of the daemonized process, but I don't use it
(neither zdrun nor the option, that is). It does nothing to the working
directory by default.
But I think the common case is that the program is run out of an
/etc/init.d "rc" script, and I suspect the working directory is "/" when
Zope gets started in that circumstance. Which I guess makes the error
It's just a name, and it's opened in
'w' ('+b') mode, not 'r' mode. That is, it creates the file -- no
file of that name need already exist (and if one does, it tries to
overrwrite it). Running on Windows most days, I'm not usually aware
of all the permission bugs Linuxheads delight in torturing themselves
Yes. Gotta agree with you there. I don't think a day passes where I
don't want to rip the face off the guy who proclaimed that TCP ports
below 1024 couldn't be bound to by a user other than root. What a
There should probably be a _using_persistent_cache flag attr rather than
trying to inspect self._p to find out if we're using persistent caches.
+1. As you later discovered, this "hmm, let's try to guess what we're
doing based on obscure droppings" business is a continuing bug
Thankfully, Dieter fixed it so it doesn't (at least in this one case).
I may try to work up a patch + test for this later.
I'm neutral on whether you try, but +1 on you actually doing it <wink>.
Too late! It's already fixed. I didn't know either. ;-) This thread
was full of sound and fury....
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -
Solution Workshops for Plone
(+44) (0) 7789 338868
_______________________________________________ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )