WARNING!
If you use Windows-NT 3.5 on your server or workstation, please read this!


Microsoft Windows-NT 3.5 contains a VERY SERIOUS BUG, which can cause
zeros to be substituted for the data in files stored under the NTFS
file system.

This bug can destroy almost any file stored under the NTFS file system!

Microsoft has identified this bug, and they have a fix for it, which is
included in "Service Pack 2" for NT 3.5.  However, Microsoft has chosen
not to fix the bug in retail versions of Windows-NT, so you must
install SP2 to get the fix.  I strongly recommend that you do not use
Windows-NT's NTFS file system without first applying SP2 (or later).

These are excerpts from some email conversations about this problem:
----------------------------------------------------------------------------
 Subject: NTFS bug that causes nulls to appear in files, instead of data
 From: dburton@salzo.Cary.NC.US (David Burton)
 Date: Thu, 02 Mar 95 11:15:13 EST

 re: The Windows-NT bug that causes 0-bytes to appear instead of data.
     a/k/a Service Request Number SRG 950109-000-139 (service unit response 5)
     a/k/a Bugs #5300 & 5600.

 Gentlemen,

 I've heard from Microsoft that they have identified the bug, and
 they now have a fix for it.  The fix is part of the brand new
 "service pack 2" for NT 3.5, which should be available now.

 The bug was introduced in the original version of NT 3.5, and was
 not fixed by service pack 1.  The bug was not present in NT 3.1,
 and only affects the NTFS file system.  HPFS and FAT file systems
 should not have been be affected by it (my guess, Larry, is that
 the damaged file that you found on your HPFS partition was already
 damaged when you copied the files from your earlier NTFS partition).

 To obtain service pack 2 from Microsoft:

   On Compuserve, "go winntdl".

   On Internet, ftp to ftp.microsoft.com, and look in the directories
   below bussys/winnt/winnt-public/fixes/...

   Or, look for "SP2" on the Microsoft BBS, at 206-936-6735.

 The fix replaces NTOSKRNL.EXE (or NTKRNLMP.EXE on the SMP versions).

 I asked, and was told that Microsoft is not releasing a fixed retail
 version of Windows-NT 3.5.  The retail version will continue to have the
 bug; you must obtain and install the service pack to get the fix. :-(
----------------------------------------------------------------------------

----------------------------------------------------------------------------
 From: xxxxxxxxxxx <xxxxxx@microsoft.com>
 Date: Wed,  1 Mar 95 12:09:34 PST
 Subject: RE: SRG 950109-000-139  (NT server writes nulls instead of
 data to files)

 . . .
 We have, in fact, come out with a hotfix to Windows NT version 3.5 for
 this problem.

 Larry is not using the fix because he has shifted to HPFS as a
 temporary workaround. The relevant bug/hotfix number is 5300.

 This fix is encorporated in Service Pack 2 for Windows NT version 3.5.
 If it is not already there, it will soon be available at all the usual
 locations, including:

  Internet: ftp.microsoft.com (198.105.232.1)
      /bussys/winnt/winnt-public/fixes

    CompuServe: WINNTDL download area

    Microsoft OnLine: Software Library
    - search on file names or KBFile numbers

    Microsoft Download Service (206)936-6735
    - search on file names or KBFile numbers

 Please refer anyone who might be concerned by this issue to these
 distribution points.

 Since the fix developed only shortly before the service pack was
 assembled, there is no documentation about the problem in the readme or
 helpfile included with the service pack, but I am assured that the fix
 did make it in.

 In answer to your request for more details, the problem involves an
 optimization to cache management in Windows NT 3.5 that did not exist
 in version 3.1.  As such, the problem file was not ntfs.sys, but the
 operating system kernel.  This is "ntoskrnl.exe" or "ntkrnlmp.exe"
 depending on whether the system is uniprocessor or multiprocessor
 enabled.  The change resulted in rare instances where small writes on
 an NTFS volume would not properly update a field in the file record
 header used to track the valid data length of the file.  I was only
 able to reproduce the problem approximately once in ten to thirty
 thousand small write operations and only on certain machine
 configurations. The developer who fixed the problem was not able to
 reproduce the problem at all. Therefore I do not believe everyone using
 Windows NT version 3.5 will necessarily encounter the problem.  I know
 of no way to determine in advance whether a specific hardware or
 software environment will or will not encounter the problem.  I only
 know that the problem is rare and difficult to deliberately reproduce,
 and only affects NTFS in version 3.5.

 Regards,
 	-- xxxxxxxxxxxxxxxx
----------------------------------------------------------------------------