Mailing List Archive

Varnish logging
Hi list,

The setting is: a lot of virtual hosts running on top of Zope. We
deliver statistics generated with server logfiles.

We are perfectly content with post-processing a big logfile with
entries for several domains - we had a script like that when we were
still using Squid.

Comparing the logfiles generated by Squid and Varnish we find that
those generated by Varnish lack any Host prefix in the relevant 'GET'
field so we are unable to process them as we did with Squid's.

As the manpage does not say anything about a configuration option to
alter this behaviour, we'd be thankful for hints in this case.
Filtering before logging was proposed in an earlier post- in our case
this does not seem to be a good solution as there are lots of
changing domains involved and so the configuration would be quite
tedious- it would be entirely sufficient to have the host logged by
default.

Appendix: Some lines of the logfiles, for comparison

Squid:

89.59.80.86 - - [06/Apr/2007:13:28:05 +0200] "GET http://
op.elseware.de:8080/content/logobao.gif HTTP/1.1" 200 17554 "http://
op.elseware.de/content/e3224/e10/e589/e594/e702/index_ger.html"
"Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR
2.0.50727)" TCP_REFRESH_MISS:DIRECT
89.59.80.86 - - [06/Apr/2007:13:28:05 +0200] "GET http://
op.elseware.de:8080/common/masses.jpg HTTP/1.1" 200 2681 "http://
op.elseware.de/content/e3224/e10/e589/e594/e702/index_ger.html"
"Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR
2.0.50727)" TCP_MEM_HIT:NONE
89.59.80.86 - - [06/Apr/2007:13:28:05 +0200] "GET http://
op.elseware.de:8080/favicon.ico HTTP/1.1" 200 1407 "-" "Mozilla/4.0
(compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 2.0.50727)"
TCP_MEM_HIT:NONE
87.160.144.136 - - [06/Apr/2007:13:28:08 +0200] "GET http://
www.csg.elseware.com:8080/content/e1756/index_html? HTTP/1.1" 200
14826 "http://www.csg.elseware.com/content/e1756" "Mozilla/5.0
(Windows; U; Windows NT 5.1; de; rv:1.8.0.11) Gecko/20070312 Firefox/
1.5.0.11" TCP_MISS:DIRECT


Varnish:

87.160.200.220 - - [10/Apr/2007:00:36:05 +0200] "GET /sites/nele-
elseware.de/myzms/content/imgb01_ger.jpg HTTP/1.1" 304 - "http://
www.nele-elseware.de/content/e531/index_ger.html" "Mozilla/4.0
(compatible; MSIE 6.0; Windows NT 5.1; SV1; HbTools 4.8.4)"
87.160.200.220 - - [10/Apr/2007:00:36:26 +0200] "GET /sites/nele-
elseware.de/myzms/content/e531/e706/milonga_del_serafin_ger.mp3 HTTP/
1.1" 304 - "http://www.nele-elseware.de/content/e531/index_ger.html"
"Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; HbTools 4.8.4)"
87.160.200.220 - - [10/Apr/2007:00:36:31 +0200] "GET /sites/nele-
elseware.de/myzms/content/e531/e706/milonga_del_serafin_ger.mp3 HTTP/
1.1" 304 - "-" "NSPlayer/9.0.0.3250 WMFSDK/9.0"
87.160.200.220 - - [10/Apr/2007:00:41:23 +0200] "GET /sites/nele-
elseware.de/myzms/content/e531/e686/el_choclo_ger.mp3 HTTP/1.1" 304 -
"http://www.nele-elseware.de/content/e531/index_ger.html" "Mozilla/
4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; HbTools 4.8.4)"
87.160.200.220 - - [10/Apr/2007:00:45:40 +0200] "GET /sites/nele-
elseware.de/myzms/content/e531/e543/a_los_paisanos_ger.pdf HTTP/1.1"
200 479110 "http://www.nele-elseware.de/content/e531/index_ger.html"
"Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; HbTools 4.8.4)"
87.160.200.220 - - [10/Apr/2007:00:46:29 +0200] "GET /common/logo.gif
HTTP/1.1" 304 - "http://www.nele-elseware.de/content/e531/
index_ger.html" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;
SV1; HbTools 4.8.4)"
87.160.200.220 - - [10/Apr/2007:00:46:29 +0200] "GET /sites/nele-
elseware.de/myzms/content/imga01_ger.jpg HTTP/1.1" 304 - "http://
www.nele-elseware.de/content/e531/index_ger.html" "Mozilla/4.0
(compatible; MSIE 6.0; Windows NT 5.1; SV1; HbTools 4.8.4)"
87.160.200.220 - - [10/Apr/2007:00:46:30 +0200] "GET /common/deu.jpg
HTTP/1.1" 304 - "http://www.nele-elseware.de/content/e531/
index_ger.html" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;
SV1; HbTools 4.8.4)"
87.160.200.220 - - [10/Apr/2007:00:46:30 +0200] "GET /common/eng.jpg
HTTP/1.1" 304 - "http://www.nele-elseware.de/content/e531/
index_ger.html" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;
SV1; HbTools 4.8.4)"
87.160.200.220 - - [10/Apr/2007:00:46:30 +0200] "GET /common/esp.jpg
HTTP/1.1" 304 - "http://www.nele-elseware.de/content/e531/
index_ger.html" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;
SV1; HbTools 4.8.4)"
87.160.200.220 - - [10/Apr/2007:00:46:30 +0200] "GET /sites/nele-
elseware.de/myzms/content/imgb01_ger.jpg HTTP/1.1" 304 - "http://
www.nele-elseware.de/content/e531/index_ger.html" "Mozilla/4.0
(compatible; MSIE 6.0; Windows NT 5.1; SV1; HbTools 4.8.4)"
87.160.200.220 - - [10/Apr/2007:00:46:30 +0200] "GET /misc_/zms/
mime_type.application_pdf.gif HTTP/1.1" 304 - "http://www.nele-
elseware.de/content/e531/index_ger.html" "Mozilla/4.0 (compatible;
MSIE 6.0; Windows NT 5.1; SV1; HbTools 4.8.4)"
87.160.200.220 - - [10/Apr/2007:00:46:30 +0200] "GET /misc_/zms/
mime_type.audio_basic.gif HTTP/1.1" 304 - "http://www.nele-
elseware.de/content/e531/index_ger.html" "Mozilla/4.0 (compatible;
MSIE 6.0; Windows NT 5.1; SV1; HbTools 4.8.4)"
87.160.200.220 - - [10/Apr/2007:00:46:41 +0200] "GET /sites/nele-
elseware.de/myzms/content/e531/e684/ahora_no_me_conoces-nele-
elseware_ger.mp3 HTTP/1.1" 304 - "http://www.nele-elseware.de/content/
e531/index_ger.html" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT
5.1; SV1; HbTools 4.8.4)"
87.160.200.220 - - [10/Apr/2007:00:49:59 +0200] "GET /sites/nele-
elseware.de/myzms/content/e531/e706/milonga_del_serafin_ger.mp3 HTTP/
1.1 HTTP/1.1" 304 - "-" "NSPlayer/9.0.0.3250 WMFSDK/9.0"
66.249.65.110 - - [10/Apr/2007:00:53:27 +0200] "GET /e43/e59/
sitemap_ger.html HTTP/1.1 HTTP/1.1" 304 - "-" "Mozilla/5.0
(compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
88.198.251.202 - - [10/Apr/2007:01:19:14 +0200] "" 304 - "-" "-"
85.25.129.88 - - [10/Apr/2007:01:24:26 +0200] "GET / HTTP/1.0 HTTP/
1.1" 304 - "-" "Mozilla"
88.198.251.202 - - [10/Apr/2007:03:50:50 +0200] "" 304 - "-" "-"
207.46.98.56 - - [10/Apr/2007:03:55:56 +0200] "GET /robots.txt HTTP/
1.0 HTTP/1.1" 304 - "-" "msnbot/1.0 (+http://search.msn.com/msnbot.htm)"
66.249.65.110 - - [10/Apr/2007:04:08:24 +0200] "GET /e31/e78/
sitemap_ger.html HTTP/1.1 HTTP/1.1" 304 - "-" "Mozilla/5.0
(compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
65.55.208.24 - - [10/Apr/2007:04:11:10 +0200] "GET /robots.txt HTTP/
1.0 HTTP/1.1" 304 - "-" "msnbot/1.0 (+http://search.msn.com/msnbot.htm)"
65.55.208.24 - - [10/Apr/2007:04:11:13 +0200] "GET /e53/
sitemap_ger.html HTTP/1.0 HTTP/1.1" 304 - "-" "msnbot/1.0 (+http://
search.msn.com/msnbot.htm)"
65.54.188.19 - - [10/Apr/2007:05:00:54 +0200] "GET /robots.txt HTTP/
1.0 HTTP/1.1" 304 - "-" "msnbot/1.0 (+http://search.msn.com/msnbot.htm)"
65.54.188.19 - - [10/Apr/2007:05:00:55 +0200] "GET /content/
index_ger.html HTTP/1.0 HTTP/1.1" 304 - "-" "msnbot/1.0 (+http://
search.msn.com/msnbot.htm)"
207.46.98.56 - - [10/Apr/2007:06:26:38 +0200] "GET /robots.txt HTTP/
1.0 HTTP/1.1" 304 - "-" "msnbot/1.0 (+http://search.msn.com/msnbot.htm)"
207.46.98.56 - - [10/Apr/2007:06:26:39 +0200] "GET /e61/
index_print_ger.html HTTP/1.0 HTTP/1.1" 304 - "-" "msnbot/1.0
(+http://search.msn.com/msnbot.htm)"

-- Dirk
Varnish logging [ In reply to ]
In message <C29516D8-DD73-4AA8-B60F-F16434640C16 at dirkgomez.de>, Dirk Gomez writ
es:
>Hi list,
>
>The setting is: a lot of virtual hosts running on top of Zope. We
>deliver statistics generated with server logfiles.

Basically, you want NCSA format logfiles split by the value of
the "Host:" header ?


--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
Varnish logging [ In reply to ]
"Poul-Henning Kamp" <phk at phk.freebsd.dk> writes:
> Dirk Gomez <lists at dirkgomez.de> writes:
> > The setting is: a lot of virtual hosts running on top of Zope. We
> > deliver statistics generated with server logfiles.
> Basically, you want NCSA format logfiles split by the value of
> the "Host:" header ?

No, he wants the Host: header prepended to the request URL in NCSA
logs. It's easy to do, I'll take care of it.

DES
--
Dag-Erling Sm?rgrav
Senior Software Developer
Linpro AS - www.linpro.no
Varnish logging [ In reply to ]
des at linpro.no (Dag-Erling Sm?rgrav) writes:
> "Poul-Henning Kamp" <phk at phk.freebsd.dk> writes:
> > Dirk Gomez <lists at dirkgomez.de> writes:
> > > The setting is: a lot of virtual hosts running on top of Zope. We
> > > deliver statistics generated with server logfiles.
> > Basically, you want NCSA format logfiles split by the value of
> > the "Host:" header ?
> No, he wants the Host: header prepended to the request URL in NCSA
> logs. It's easy to do, I'll take care of it.

Done in r1362.

Dirk, if you are comfortable building Varnish from sources, try
grabbing the following file:

http://varnish.projects.linpro.no/svn/trunk/varnish-cache/bin/varnishncsa/varnishncsa.c

Stick it in the obvious place in your source tree, rebuild and
reinstall. It will work fine in a 1.0 tree.

DES
--
Dag-Erling Sm?rgrav
Senior Software Developer
Linpro AS - www.linpro.no
Varnish logging [ In reply to ]
>>> The setting is: a lot of virtual hosts running on top of Zope. We
>>> deliver statistics generated with server logfiles.
>> Basically, you want NCSA format logfiles split by the value of
>> the "Host:" header ?
>
> No, he wants the Host: header prepended to the request URL in NCSA
> logs. It's easy to do, I'll take care of it.

Exactly. We have statistics processing on one logfile that has worked
for years and we would like to continue using it.
Varnish logging [ In reply to ]
> Done in r1362.
>
> Dirk, if you are comfortable building Varnish from sources, try
> grabbing the following file:
>
> http://varnish.projects.linpro.no/svn/trunk/varnish-cache/bin/
> varnishncsa/varnishncsa.c
>
> Stick it in the obvious place in your source tree, rebuild and
> reinstall. It will work fine in a 1.0 tree.

DES, I checked out varnishncsa from trunk head, compiled it and
replaced the binary that came with Debian (new)stable with the newly
built one - works fine.

Thanks a lot!

-- Dirk
Varnish logging [ In reply to ]
> Dirk, if you are comfortable building Varnish from sources, try
> grabbing the following file:
>
> http://varnish.projects.linpro.no/svn/trunk/varnish-cache/bin/
> varnishncsa/varnishncsa.c
>
> Stick it in the obvious place in your source tree, rebuild and
> reinstall. It will work fine in a 1.0 tree.

DES, here's what I did:

* Checked out the 1.0.3 tag.
* Checkout above file from trunk.
* Stuck it into the obvious place
* Compiled, created and installed a Debian varnish-103 package.

varnishncsa doesn't write to a log file anymore though.

execve("/usr/bin/varnishncsa", ["/usr/bin/varnishncsa", "-w", "foo"],
[/* 19 vars */]) = 0
uname({sys="Linux", node="test01.dirkgomez.de", ...}) = 0
brk(0) = 0x804b000
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or
directory)
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 0x40017000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or
directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=19929, ...}) = 0
mmap2(NULL, 19929, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40019000
close(3) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or
directory)
open("/usr/lib/libvarnish.so.0", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\20\21\0"...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=16468, ...}) = 0
mmap2(NULL, 19480, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3,
0) = 0x4001e000
mmap2(0x40022000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|
MAP_DENYWRITE, 3, 0x3) = 0x40022000
close(3) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or
directory)
open("/usr/lib/libvarnishapi.so.0", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\360\f\0"...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=11352, ...}) = 0
mmap2(NULL, 14600, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3,
0) = 0x40023000
mmap2(0x40026000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|
MAP_DENYWRITE, 3, 0x2) = 0x40026000
close(3) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or
directory)
open("/lib/tls/libpthread.so.0", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\360G\0"...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=85010, ...}) = 0
mmap2(NULL, 70104, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3,
0) = 0x40166000
mmap2(0x40174000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|
MAP_DENYWRITE, 3, 0xd) = 0x40174000
mmap2(0x40176000, 4568, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|
MAP_ANONYMOUS, -1, 0) = 0x40176000
close(3) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 0x40178000
mprotect(0x4015b000, 20480, PROT_READ) = 0
set_thread_area({entry_number:-1 -> 6, base_addr:0x401786c0, limit:
1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1,
seg_not_present:0, useable:1}) = 0
munmap(0x40019000, 19929) = 0
set_tid_address(0x40178708) = 8910
rt_sigaction(SIGRTMIN, {0x4016a450, [], SA_SIGINFO}, NULL, 8) = 0
rt_sigaction(SIGRT_1, {0x4016a3c0, [], SA_RESTART|SA_SIGINFO}, NULL,
8) = 0
rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY})
= 0
uname({sys="Linux", node="test01.dirkgomez.de", ...}) = 0
brk(0) = 0x804b000
brk(0x807c000) = 0x807c000
open("/tmp/_.vsl", O_RDONLY) = 3
read(3, "2\332y\371\214\1\0\0=\3501F\344\1\0\0\0\0\200\0+\362\1"...,
396) = 396
mmap2(NULL, 8389004, PROT_READ, MAP_SHARED, 3, 0) = 0x40179000
open("foo", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 4
rt_sigaction(SIGHUP, {0x8048b90, [HUP], SA_RESTART}, {SIG_DFL}, 8) = 0
nanosleep({0, 50000000}, NULL) = 0
nanosleep({0, 50000000}, NULL) = 0
nanosleep({0, 50000000}, NULL) = 0
...

and then it continues to nanosleep.

varnishlog though does show activity on the server.

-- Dirk
Varnish logging [ In reply to ]
Dirk Gomez <dirk at dirkgomez.de> writes:
> DES, here's what I did:
>
> * Checked out the 1.0.3 tag.
> * Checkout above file from trunk.
> * Stuck it into the obvious place
> * Compiled, created and installed a Debian varnish-103 package.
>
> varnishncsa doesn't write to a log file anymore though.

You mean -w is broken, or that it stops? Does it work if you do not
specify -w? What exact command line are you using?

DES
--
Dag-Erling Sm?rgrav
Senior Software Developer
Linpro AS - www.linpro.no
Varnish logging [ In reply to ]
> You mean -w is broken, or that it stops? Does it work if you do not
> specify -w? What exact command line are you using?

No output is written with this command:

varnishncsa -adw foo

(Just tried: it now segfaults)
Varnish logging [ In reply to ]
Dirk Gomez <lists at dirkgomez.de> writes:
> No output is written with this command:
>
> varnishncsa -adw foo
>
> (Just tried: it now segfaults)

I'm unable to reproduce this. Are you sure varnishd and varnishncsa
are using the same library versions? And do you have a backtrace for
the segfault?

DES
--
Dag-Erling Sm?rgrav
Senior Software Developer
Linpro AS - www.linpro.no
Varnish logging [ In reply to ]
>> No output is written with this command:
>>
>> varnishncsa -adw foo
>>
>> (Just tried: it now segfaults)
>
> I'm unable to reproduce this. Are you sure varnishd and varnishncsa
> are using the same library versions? And do you have a backtrace for
> the segfault?

Hmm, not able to reproduce twenty minutes later.

Here are the library versions:

anadyr:~# ldd /usr/bin/varnishncsa
linux-gate.so.1 => (0xffffe000)
libvarnish.so.0 => /usr/lib/libvarnish.so.0 (0x4001e000)
libvarnishapi.so.0 => /usr/lib/libvarnishapi.so.0 (0x40023000)
libdl.so.2 => /lib/tls/libdl.so.2 (0x40027000)
librt.so.1 => /lib/tls/librt.so.1 (0x4002b000)
libc.so.6 => /lib/tls/libc.so.6 (0x40033000)
/lib/ld-linux.so.2 (0x40000000)
libpthread.so.0 => /lib/tls/libpthread.so.0 (0x40166000)
anadyr:~# ldd /usr/sbin/varnishd
linux-gate.so.1 => (0xffffe000)
libvarnish.so.0 => /usr/lib/libvarnish.so.0 (0x4001e000)
libvcl.so.0 => /usr/lib/libvcl.so.0 (0x40023000)
libdl.so.2 => /lib/tls/libdl.so.2 (0x40030000)
librt.so.1 => /lib/tls/librt.so.1 (0x40034000)
libc.so.6 => /lib/tls/libc.so.6 (0x4003c000)
libpthread.so.0 => /lib/tls/libpthread.so.0 (0x4016f000)
/lib/ld-linux.so.2 (0x40000000)

(Debian Etch, self-built varnish-103 package with your "HOST" patch
from trunk for varnishncsa)

varnishncsa returns to its nanosleep routine.

Should I recompile with --enable-developer-warnings and --enable-
debugging-symbols set to yes and retry strace?
Varnish logging [ In reply to ]
Dirk Gomez <lists at dirkgomez.de> writes:
> (Debian Etch, self-built varnish-103 package with your "HOST" patch
> from trunk for varnishncsa)

I assume you rebuilt and reinstalled the entire package?

> varnishncsa returns to its nanosleep routine.

Does varnishlog behave normally?

> Should I recompile with --enable-developer-warnings and --enable-
> debugging-symbols set to yes and retry strace?

Those flags won't make any difference for strace, but they will make
it easier to get a backtrace if it segfaults again. Please remember
to 'make clean' before rebuilding with these flags, otherwise they
won't be applied.

DES
--
Dag-Erling Sm?rgrav
Senior Software Developer
Linpro AS - www.linpro.no
Varnish logging [ In reply to ]
>> (Debian Etch, self-built varnish-103 package with your "HOST" patch
>> from trunk for varnishncsa)
>
> I assume you rebuilt and reinstalled the entire package?

Yes (so that everything fits together).

>
>> varnishncsa returns to its nanosleep routine.
>
> Does varnishlog behave normally?

Yes.

>> Should I recompile with --enable-developer-warnings and --enable-
>> debugging-symbols set to yes and retry strace?
>
> Those flags won't make any difference for strace, but they will make
> it easier to get a backtrace if it segfaults again. Please remember
> to 'make clean' before rebuilding with these flags, otherwise they
> won't be applied.

No more segfaults.

varnishncsa -d outputs something now - just for one of our "virtual
hosts", none other makes it to varnishncsa's output. varnishlog works
fine tho: it outputs the other vhosts as well.
Varnish logging [ In reply to ]
Dirk Gomez <lists at dirkgomez.de> writes:
> varnishncsa -d outputs something now - just for one of our "virtual
> hosts", none other makes it to varnishncsa's output. varnishlog works
> fine tho: it outputs the other vhosts as well.

OK, I would like you to do the following:

- capture a few minutes of traffic to a file using 'varnishlog -w file'

- verify that 'varnishncsa -r file' exhibits the bug you experience
when running it "live"

- send me that file (directly, not to the list)

Hopefully, I will be able to find and correct the error quickly. I'm
very busy this week, though, so please be patient.

DES
--
Dag-Erling Sm?rgrav
Senior Software Developer
Linpro AS - www.linpro.no