• Do not register here on develop.twiki.org, login with your twiki.org account.
• Use View topic Item7848 for generic doc work for TWiki-6.1.1. Use View topic Item7851 for doc work on extensions that are not part of a release. More... Close
• Anything you create or change in standard webs (Main, TWiki, Sandbox etc) will be automatically reverted on every SVN update.
Does this site look broken?. Use the LitterTray web for test cases.

Item3538: Unhelpful error message when _work_areas doesn't exist

Item Form Data

AppliesTo: Component: Priority: CurrentState: WaitingFor: TargetRelease ReleasedIn
Engine   Low Closed   patch 4.1.2

Edit Form Data

Reported By:
Applies To:
Current State:
Waiting For:
Target Release:
Released In:


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.


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.


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!


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

Summary Unhelpful error message when _work_areas doesn't exist
ReportedBy TWiki:Main.CrawfordCurrie
Codebase 4.1.0
SVN Range TWiki-4.1.1, Tue, 30 Jan 2007, build 12650
AppliesTo Engine

Priority Low
CurrentState Closed

Checkins 12683 12687 12700 12752
TargetRelease patch
ReleasedIn 4.1.2
Edit | Attach | Watch | Print version | History: r17 < r16 < r15 < r14 < r13 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r17 - 2008-08-10 - GilmarSantosJr
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2020 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback