When upgrading an existing installation, I moved over the existing pub dir. in the process I forgot to create _work_areas, the default dir for plugins work areas. A plugin (Headlines) failed with the unhelpful "Coule not create work area" message. This message could mention the configure setting where the work areas are defined
--
TWiki:Main/CrawfordCurrie - 31 Jan 2007
New checker is possible patch candidate.
CC
Good enhancement for the installer and low risk to break anything else.
Merged to Patch04x01
--
TWiki:Main.KennethLavrsen - 31 Jan 2007
I am removing this from 4.1.1 until it behaves better.
Right now it produces an error the first time you run configure. This error is the result of other settings not yet being saved
Once you have save the
LocalSite.cfg the error is gone by itself.
The reporter was an upgrader and had a different situation. And the developer probably tested this on a working TWiki.
Try and run on a TWiki with
LocalSite.cfg deleted and see it with newbie eyes.
The problem is that the newbie will not see all the good advice it says at the top of configure because there is so much information on that page. Instead he will try and fix the error and then he most likely creates more problems than he fixes.
Harald recently fixed some other setting checks so that they do not start creating errors or warnings until after
LocalSite.cfg has been saved. Same method could be applied to this setting.
--
TWiki:Main.KennethLavrsen - 04 Feb 2007
Oh yes. When this is fixed remember to add the new check file to the MANIFEST. It was fogotten for this one. I just noticed as I was about to remove it.
--
TWiki:Main.KennethLavrsen - 04 Feb 2007
Let's get this straight;
configure
is an admin interface,
not an installer script.
Having said that I understand your point, but it should reflect on
Item3559, not on this checker which is quite correct and is required.
Pushing back to
KJL for a release decision.
CC
A proper fix is to do this in TWiki, not configure. If access to the work area fails, try to create the directory. This is fast in the normal working case, and a bit slower if the directory needs to be created.
--
TWiki:Main.PeterThoeny - 05 Feb 2007
Not sure I understand why you think that. We don't do that for
pub
or
data
, so why would we do it for
_work_areas
?
configure
would still have to check that the path to
{WorkAreas}/..
was valid and writable - we don't want the plugin work area creation to fail in the middle of a plugin run. As you would expect the work area dirs for the individual plugins are created on demand, but the
_work_areas
dir itself (which defaults to a dir in pub, shipped in the release) needs to be pre-created and checked.
--
TWiki:Main.CrawfordCurrie - 05 Feb 2007
data
and
pub
have been in TWiki for ages. An automated and quick way to create
_work_areas
would help upgraders avoid yet another "gotcha".
--
TWiki:Main.PeterThoeny - 05 Feb 2007
One sample of a user who fell into this "gotcha":
TWiki:Support/ActionTrackerRCSProblem
--
TWiki:Main.PeterThoeny - 06 Feb 2007
Work areas is a default existing directory in TWiki 4.0 and 4.1.
This user must have removed it. Or he has setup wrong access rights for it.
As much as a favour auto-creating /tmp/twiki - as much am I advising not to auto create a directory like _work_areas. The default value should always point to a valid directory unless the installer has removed it or has tried to fix a false warning.
This may be the problem in fact.
The first time you install TWiki using configure to set it up - you need to save the general paths first. And if you try to set anything else before you have saved
LocalSite.cfg the first time chances are that you setup something else to a non-working value. And we should not have TWiki create directories all over the place if you setup something wrong.
The key thing to a well working setup of directories is
- Configure only shows the general basic paths when you run it first time. First time defined as LocalSite.cfg does not exist.
- Once LocalSite.cfg is created configure shows all the settings and can now - without confusing anyone signal errors when directories are missing or not writable.
- As an exception the temporary directory checker should not check that the lowest level directory exists and is writable but that the parent directory is. Ie if setting is /tmp/twiki it should check for /tmp being writable. And when you later run TWiki the /tmp/twiki directory should be created. But that should really be the exception. We cannot let configure create it because the directory may get wiped at a reboot and then we need a new created.
Different medicin for different problems. But the
TWiki:Support/ActionTrackerRCSProblem I really think we solve better with a configure that does not lead you to fix the wrong errors before you have saved the General paths and then displays an error if you delete the _work_areas or change the setting to a non-existing directory.
--
TWiki:Main.KennethLavrsen - 06 Feb 2007
Ping - this is marked as waiting for your feedback, Ken!
CC
I am the last one that gave feedback so I am not sure what we are waiting for. Maybe I forgot to remove the waiting for.
Last checkin was mine reverting a change and I believe configure has been improved also in this respect since. In another bug item configure was changed so that you do not see other settings than the basic the first time you run configure. That should fix the problem that people accidently set the work area to a wrong value because it is wrongly flagged as a an error. So my proposal is to close this bug item with no further actions.
Can you agree on this Crawford? It was originally your bug item. I am closing now. Reopen if you disagree.
--
TWiki:Main.KennethLavrsen - 23 Apr 2007
Cleaned "WaitingFor" field.
--
TWiki:Main.GilmarSantosJr - 10 Aug 2008