#132 Log rollover failes if 'logs' folder does not exist

[Phil]

Hi, we're using wrapper 3.2.0beta (built from CVS
source some months ago).
The following occurs under Mac OSX 10.4.x.

We distributed wrapper in a setup where the 'logs'
folder does not exist. Each system created their
wrapper.log file in the bin folder and have been
running quite happily for months. However when the
wrapper.log file filled and wrapper tried to 'roll it
over', wrapper fails because the 'logs' folder does not
exist.

Unfortunately the only logging you see (in the old log)
is something like:
STATUS | wrapper | 2006/07/31 11:17:05 | -->
Wrapper Started as Daemon
Then you see nothing further, i.e no indication as to
why wrapper is not working.

We only discovered wrapper was failing by trying to
start wrapper manually on OSX (within a console with
daemonize=false).
If we create the logs folder then wrapper rolls over
the logs correctly and starts up normally.

Has anyone noticed this? I can see the following as
possible solutions:
1) With the absence of the 'logs' folder, if the
wrapper program can fall back to creating the initial
log file in the 'bin' folder, then can it not also roll
over the logs in the bin folder?
2) If the wrapper fails to start because it cannot roll
over the log then it needs to log something saying that
in the old log (otherwise we only know about it by
starting it manually in a console).
3) Maybe the wrapper could automatically create the
'logs' folder if it doesn't exist? It already has the
ability to create new files, so hopefully it could also
create a folder if it needed to...

Lastly, we also have Windows sites using the
wrapper.exe. Unlike OSX, when you start wrapper (which
is installed as a service), if the 'logs' folder does
not exist wrapper seems to keep writing to the
bin\wrapper.log file indefinitely. Eg I have a 5M limit
to the log file and it is currently 12M. If I create
the logs folder and restart the wrapper service,
everything seems to be managed correctly; i.e the log
is rolled over immediately and a new one started.

Can anyone confirm whether this is an issue in the
current wrapper version (or whether we missed some
setting that avoids this situation!),
Thanks
Phil