[Samba] wrong file size

[Marco Berizzi]

john.nelson at teradyne.com wrote:

> >I'm having a problem coping a 5GB file from
> >Windows NT 4 TSE to samba 3.0.4

> Your message is a little unclear.  It isn't obvious at all from your
> message what you think is the problem, or how Samba is involved at
all.

Sorry. My problem is simple. Md5sum is different
between a file on a NT4TSE file system and a copy
to a samba share on a linux box. If I transfer this
file from this NT4TSE system to the linux box by ftp
md5sum are the same. So IMHO samba is involved.
Isn't it?

> You seem to be having a problem with the way Linux works - your
examples
> don't involve any networking (or Samba) at all.  The way you phrased
the
> question, it would be better asked on a Linux mailing list, not a
Samba
> list!

> >  File: `priv.edb'
> >  Size: 5393883136 Blocks: 8388728    IO Block: 4096   regular file
> > ...
> > Size field shows the correct size, but blocks aren't
> > correct.

> >  File: `catted'
> >  Size: 5393883136 Blocks: 10534928   IO Block: 4096   regular file
> > ...
> > Here file size and blocks are correct.

> I'm not sure why you think this indicates a problem.  Here is my
guess:
> this is perfectly normal behavior because priv.edb is a "sparse file".

> The original file, "priv.edb", appears to have "holes" - blocks that
have
> never been explicitly written to the file.  Actually, this is fairly
> common in Unix database files.  The unix filesystem does not actually
> allocate disk space when a program seeks past the previous end-of-file
> marker and writes a block of data - the intervening blocks are simply
> marked as unallocated space, and if a program should try to read from
> them, the filesystem will return blocks of null bytes (bytes with the
> value 0).  Disk space for these blocks will be written the first time
time
> a program explicitly writes data to those blocks.

> Now, when you use a "dumb" program like "cat" to copy the file, it is
> unaware that some of the blocks of the original file were
unallocated - it
> simply reads the entire file in a sequential manner, and writes every
> block to the output file.  So the copy does not have any "holes" -
because
> every block was explicitly written.

> Actually, NTFS supports "sparse files" as well, but you must
explicitly
> request this file mode when you use CreateFile in your program.

> I hope that answers your question.

  - john nelson