[pmwiki-users] Install/reinstall problem

Joachim Durchholz jo at durchholz.org
Wed Jun 29 05:03:14 CDT 2005


Algis Kabaila wrote:
>>> For Sharon's benefit, I seem to recall that the permission
>>> problems can be mitigated if one copies files into wikilib.d
>>> directory and hopes that the pmwiki.php will cause the Apache to
>>> copy those files across to the wiki.d directory, with the correct
>>> owner, group and permissions, no?
>> 
>> That should work. However, I wouldn't recommend that: any future 
>> upgrades may overwrite files that you have edited.
> 
> I have not experienced any overwrites from during the upgrades.  I
> would like to understand how the upgrades work.  My impression is
> that the pmwiki.php copies all upgraded files to the wikilib.d
> directory and pmwiki.php copies them to the wiki.d directory, but
> only if there is not a preexisting file of the same name in the
> wiki.d directory already.  Is that so, Jo?  Or should we ask Pm?
> What do you think?

The installation writes to wikilib.d, overwriting any files it finds
there that happen to have the same name. IOW if you include a file
PmWiki.Whatever, and Pm decides that the installation should install a
page names PmWiki.Whatever, then your Whatever page will be overwritten.

It's a rare thing to happen (the name space is segemented enough to make
such a problem unlikely in practice), but if it does happen, you'll lose
your text and even its history (since both text and history are stored
in the file that's being overwritten).
If PmWiki ever decides to come with a real installation script, it will
even be free to purge the contents of wikilib.d before upgrading.
wikilib.d is meant to contain the initial contents of PmWiki pages as
delivered in the PmWiki package.

Pages get copied from wikilib.d to wiki.d when they are edited. That
way, the original in wikilib.d is preserved (so you can always go back
to the "factory settings" if you feel like it), and if it's overwritten
due to a PmWiki upgrade, you won't lose your pages.

In other words: don't mess with wikilib.d, mess with wiki.d :-)

(This kind of split is a Good Thing IMHO: a clear distribution of
authorities who's supposed to change where is helpful. Everybody knows
where to change things.)

> I did read somewhere in the google world about something like
> "sessions disabled in the SuSE distro".  Well it does work now.  Have
> no idea why, but the aussie saying is "if it ain't broke, don't fix
> it".  BTW, phpinfo gives this line the Configure Command description:
> 
> '--enable-safe-mode' '--enable-sigchild' '--disable-ctype'
> '--disable-session' '--without-mysql'
> 
> That  '--disable-session' seems to suggest what it says.  Perhaps I
> should return to learning php...

Well, I never recomiled PHP (Debian is a mostly-binary distribution, and
that has been working well enough for me).

But I do tend to agree with you that --disable-session is not a good
idea ;-)

I'm really wondering why anybody would want to disable session support.
It's such a basic feature of PHP!

Anyway, I was never convinced of SuSE. They were doing far too many 
decisions for me, and many of them not in the direction that I liked. 
Reports like yours make me more comfortable with my decision for Debian ;-)

> Jo, thank you again - your email response cheered me up and
> encouraged  me to continue with the experimentation.

You're welcome :-)

Regards,
Jo



More information about the pmwiki-users mailing list