[Samba] wrong file size
Marco Berizzi
pupilla at hotmail.com
Mon May 17 16:40:40 GMT 2004
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
More information about the samba
mailing list