[EMAIL PROTECTED] 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 -- To unsubscribe from this list go to the following URL and read the instructions: http://lists.samba.org/mailman/listinfo/samba
