NULL filled corrupt files

[Peter J. Holzer]

On 1999-08-07 03:21:23 +1000, ai Aichmair Christian schneck wrote:
> In SAMBA Digest 2189 , Gregor Longariva <grlongar at office.softbaer.de> wrote
> > So the problem is, copying files from an NT Workstation (SP5 ) 
> > on a Samba server running under Linux (2.0.10) in some (rare) cases
> > results in files exactly of the right size but filled with NULL bytes.
[...]
> 
> To me, it seems that this is the same Promlem as I already reported some
> time ago I had with an older samba version which was not solved so far,
> seems we have to warm this up.
> 
> here is my old mail (PR#11563)):

> > I am running samba 1.9.18p10 on a HP-UX 9000/J210XC under HP-UX 10.20,
> > attached you find the output from testparm smb.conf (aha.param).

We also had a similar problem under HP-UX 10.10 (Samba 1.9.16), but it
turned out to be a bug HP's vxfs, which seemed to "optimize out" some
write requests for some combinations of writes and seeks (which was
sometimes generated by Excel and Word). The problem was solved by the
next cumulative FS patch. It is possible that the same bug also existed
in unpatched HP-UX 10.20, but I doubt that Linux or Solaris have the
same problem.

> > Now, by accident, I discovered a VERY strange symptom when the filesystems
> > gets full :
> > Assume I have a FS with a size of 115Mb, and only 8 1k-blocks
> > free ( 0% minfree FS-parameter, "bdf -i" shows 8Kb free)
> > and I want to copy a file from an NT-box ( NT4.0, SP3) to a
> > subdirectory in this filesystem (the whole filesystem is shared,
> > the UX-mountpoint is the share-point). Now, when copying a file (
> > C:\win\system\drivers\tape.sys, 16432 bytes) to this share-point,
> > the file-copy WORKS from the view of NT, i.e. no error, return-code
> > is 0, etc. !
> > The filesize on the server shows up as having 16432 bytes, (although
> > this could never happen !), and the file has ONLY a few NULLs in it.

Can you check what requests the NT box actually generates? 

If it is something like:

lseek(fd, 16431, SEEK_SET)
write 1 byte
lseek(fd, 0, SEEK_SET)
write whole file

it could be that the NT copy command assumes that if it can create a
file with some size, it can also fill it with data. This is true on a
FAT filesystem and may also be true on an NTFS, but is not true on any
Unix FS. So if copy doesn't check the return value after that first
write, you will get exactly this result.

> > The interesting thing here is that smbd seems to detect the problem
> > ( no space message in logfiles ...), but doesn't remove the file
> > after creating the Dir-entry.

Should it do this? IMHO this is something the client should do.

> > Although very insteresting is the fact, that this may happen EVEN
> > EARLIER on JFS-Filesystem (HP-UX OnlineJFS)if there are not enough
> > large extends in the FS.

Ah, that may explain some problems we are having. We have JFS file
systems with about 30 GB, and people are getting strange problems (they
either can't save or corrupt their files) when the filesystem gets more
than 99% full (even though there are still 300 MB available).

	hp

-- 
   _  | Peter J. Holzer             | Nobody should ever have to be
|_|_) | Sysadmin WSR / Obmann LUGA  | ashamed if they have a secret love
| |   | hjp at wsr.ac.at               | for writing computer programs that
__/   | http://wsrx.wsr.ac.at/~hjp/ | actually work.  -- Donald E. Knuth
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 371 bytes
Desc: not available
Url : http://lists.samba.org/archive/samba/attachments/19990809/9a59d812/attachment.bin