Client-Side Caching Truncates Files During Creation (319509)
The information in this article applies to:
- Microsoft Windows 2000 Server SP1
- Microsoft Windows 2000 Server SP2
- Microsoft Windows 2000 Advanced Server SP1
- Microsoft Windows 2000 Advanced Server SP2
- Microsoft Windows 2000 Professional SP1
- Microsoft Windows 2000 Professional SP2
This article was previously published under Q319509 SYMPTOMS
When you install a program that is configured to use a network share for program data and use client-side caching, some files may be damaged or truncated. If the program writes data files to the cached network share by using the method that is described later in this article, some files may be damaged or truncated.
CAUSE
This problem may occur with any program that installs data into a cached network share.
The program calls CreateFile and sets the file size. The program then writes some data to the file, and this write results in a FastIO write.
The cache manager then issues paging IO writes to actually write the data to the server. At the end of these writes, client-side caching writes the data to the local copy of the file.
The program sends another CreateFile for the same file, and at the end of the processing of the second create, client-side caching finds that the file is stale (the timestamp is less than that of the file on the server). Because of this, the file is truncated. Client-side caching then sets the file status to SPARSE. This is done to make sure that the future reads and writes go to the server.
The program does a Close on this file. During the Close, the SPARSE flag is removed for SPARSE files that are not damaged (if the original file size matches the current file size). This means that the file is truncated, but it is no longer SPARSE.
The program sends another write at an offset into the file, and during the end of this write, client-side caching checks too see if the file is SPARSE or not. If the file is not SPARSE, the data is written to the local
copy.
In this case, the file that has been created has all zeroes up to the last offset to which was written, and valid data after that. Now the file is not consistent with the file on the server, even though client-side caching interprets that it is.
he program reads some data, and because client-side caching interprets that the local copy is consistent with the server, it satisfies the read from the local copy, but the data that is returned is not correct. In a test program, the program quit.
RESOLUTIONTo resolve this problem, obtain the latest service pack for Windows 2000. For additional information, click the following article number to view the article in the
Microsoft Knowledge Base:
260910 How to Obtain the Latest Windows 2000 Service Pack
The English version of this fix should have the following file attributes or later:
Date Time Version Size File name
---------------------------------------------------------
21-Mar-2002 14:21 5.00.2195.5232 370,480 Mrxsmb.sys
20-Mar-2002 05:14 5.00.2195.5200 131,920 Rdbss.sys
WORKAROUND
To work around this problem, disable caching. You may need to do so at the client level. However, if the share exists on a Windows 2000-based computer, disable caching on the network share until installation/writing of files is complete, and then re-enable caching and allow the files that were created to synchronize.
STATUSMicrosoft has confirmed that this is a problem in the Microsoft products that are listed at the beginning of this article. This problem was first corrected in Windows 2000 Service Pack 3.
Modification Type: | Minor | Last Reviewed: | 9/27/2005 |
---|
Keywords: | kbHotfixServer kbQFE kbbug kbenv kbfix kbshell kbui kbWin2000PreSP3Fix kbWin2000sp3fix KB319509 |
---|
|