Thanks very much for your reply.
It looks like we now have the solution, Marianne (thanks again) pointed
out the cause as a bug in Solaris.
The file is not a sparse file. I will look out for them in the future :) 
Another way to check for sparse files is to compare an ls -l and du -k.

For the benefit of anyone searching the list archives in the future I'll
paste some of the reply I received from Marianne:
> We received this info from Veritas support:
> *****************************************************
> This issue is related to problems with Asynchronous IO on Solaris 8 - 64
> bit, Sun's posix4 aio implementation. Sun has provided a patch -
> customers needing a copy of the fix before full patch release would need
> to go through their normal Sun support channels raising an escalation
> and reference the Sun bugid #4502769. The problem is due to a bug in
> libaio binary in Solaris which can, for example in the case of NetBackup
> 3.4, cause the application to think Solaris has finished reading data
> when in fact it has not.
> 
> Current work around is to disable Asynchronous IO for NetBackup.
> To do this on the client create the file:
> /usr/openv/netbackup/AIO_READS_MAX
> Place a value of 1 in the file to turn off async I/O.
> 
> This can impact the speed of the backups and may require tuning until
> the Sun patch can be applied.
> ******************************************************

Kind regards, Justin
-- 
[-] Justin
[+] Network Services, University of Brighton


On Fri, 12 Jul 2002 07:57:54 -0600
"Donaldson, Mark" <Mark.Donaldson AT experianems DOT com> wrote:

> It could also be a "sparse" file - a file that has a reported size of 2G
> but an actual block-count size of less.  We've been bitten by a few of
> these used by Oracle.
> 
> Add up your file sizes and compare to "df".  If you've got sparse files,
> then the sum of the files will be greater than "df" since df gets its
> information from the superblock.