INF: Client Config. Util. Indicates Unusual DB-Library DateID: Q120605
|
When installing SQL Server on a Windows NT 3.5 FAT disk partition, or
upgrading from Windows NT version 3.1 to version 3.5 when SQL Server is
already installed on a FAT disk partition, under some circumstances the DB-
Library and Network Library (Net-Library) file dates indicated by the
Client Configuration Utility may be either 12/31/79, or the date SQL Server
was installed.
This is a side-effect of the enhanced Windows NT 3.5 FAT file system, which
includes support for long filenames and multiple file date/time fields.
There is no other adverse impact besides the unusual DB-Library date/time.
If desired it can be corrected by re-copying the Net-Library and DB-Library
files from the SQL Server distribution CD-ROM.
There are two sets of situations which can cause the Client Configuration
Utility to display unusual DB-Library and Net-Library file dates. The first
set will cause the dates to be 12/31/79, and the second set will cause the
file dates to be the date SQL Server was installed.
An example of the first set would be installing SQL Server from diskette to
a Windows NT 3.5 FAT partition. Another example would be upgrading the
operating system from Windows NT 3.1 to version 3.5, when SQL Server is
already installed on a FAT partition. This will not happen when installing
from CD-ROM or during a network installation from files copied from CD-ROM
to the NTFS partition of a Windows NT server.
An example of the second set would be doing a network-based installation to
a Windows NT 3.5 FAT partition from a FAT partition on a Windows NT 3.1
server. More specifics are given below.
The FAT file system of Windows NT 3.5 has been enhanced to use long
filenames and multiple date/time fields, generally referred to hereafter as
"time fields" for simplicity. Similar to NTFS, the Windows NT 3.5 FAT file
system will support three discrete time fields. These are time created,
time last accessed, and time last written (or modified). By contrast the
previous FAT file system which NT 3.1 shared with DOS and Windows 3.1x only
supported a single time field, which was time last written. These new
capabilities are achieved without altering the FAT file system structure,
so that no file system conversion or upgrade process is needed. This
differs from the FAT-to-NTFS upgrade process where a one-way conversion
takes place.
The enhanced time field capability of the Windows 3.5 FAT file system can
under some circumstances cause the SQL Server Client Configuration Utility,
NTWDBVER.EXE, to display an unusual date.
The Client Configuration Utility uses the C runtime call _fstat() to obtain
the file dates. Regardless of the file system used, this call returns a
memory structure containing three time fields, which are st_ctime (time
created), st_atime (time last accessed), and st_mtime (time last written or
modified). In the case of FAT prior to Windows NT 3.5 (subsequently
referred to as "old FAT"), there is only a single disk storage location for
file date/time. Yet for compatibility with other file system environments
such as UNIX, _fstat() returns all three fields. When called, _fstat()
obtains the st_mtime field from the single disk storage location, then the
st_ctime and st_atime are replicated at runtime from st_mtime. Note that
with old FAT, there is no true file create time, despite the term "create
time" being in common use. Rather old FAT only has "time last written, or
modified".
In order to take advantage of true file creation time of NTFS, the Client
Configuration Utility uses the st_ctime field returned from _fstat(). When
_fstat() is executed against a file on NTFS or new FAT, st_ctime is backed
by its own storage location and can store a discrete value independent from
st_mtime and st_atime. When an old FAT partition is upgraded to NTFS, a
conversion program rewrites the file structure. Part of this conversion
program copies the old FAT time field (on disk) to the "time created" and
"time last modified" disk storage fields of NTFS. Therefore if an
application using _fstat() was querying the st_ctime field when under old
FAT, the date returned immediately following upgrading to NTFS will be
unchanged, since the FAT-to-NTFS conversion process effectively replicates
on disk st_mtime to st_ctime.
By contrast, during the upgrade from Windows NT 3.1 old FAT to Windows NT
3.5 new FAT, no file system conversion takes place, only an enhanced FAT
file system driver is loaded. This is actually an advantage since it
enables new capabilities such as long filename support and multiple time
fields, without sacrificing backward compatibility with previous operating
systems using old FAT such as MS-DOS, OS/2 or prior versions of Windows NT.
However since there is no file system conversion program, there is no
facility for replicating the single old FAT time storage location to the
new FAT time fields.
In the case of the new time fields, previously unused FAT directory entry
locations are used to store these. The new fields have the initial value of
0, which _fstat() displays as 12/31/79. This is what causes the Client
Configuration Utility to display these dates. There is no adverse impact
from this other than the incorrect date. You can see the correct file date
by using the DIR command. (Incidentally there are DIR parameters which
allow inspection of all three date fields. Use DIR /s to see these.) The DB-
Library and Net-Library version numbers which the Client Configuration
Utility returns are correct.
The second situation in which the Client Configuration Utility may indicate
a strange date/time concerns when SQL Server is installed on a Windows NT
3.5 FAT partition from old FAT source media. Examples of this would be a
network-based installation from a Windows NT 3.1 server FAT partition
containing the SQL Server installation files to a Windows NT 3.5 FAT
partition. Installations from local or remote CD-ROM or NTFS sources are
unaffected. To see this phenomenon, the SQL Server installation files must
have been copied to an old FAT partition from diskette or from another old
FAT partition such as that on Windows NT 3.1. If any intermediate copy is
made to a partition other than old FAT (e.g. diskette to NT 3.1 NTFS to NT
3.1 FAT) then the creation date _fstat() returns will be 12/31/79, not the
current date. What causes the "current date" effect is this: When a file on
old FAT is copied to a new FAT partition, the destination file is created.
Hence the creation time field on disk is initialized to the current date.
By contrast, when copying a file from a non-old FAT partition to new FAT
partition, the file already has a true creation date so this is maintained
when the new file is created.
As in the case with the 12/31/79 date, if the Client Configuration Utility
returns the date SQL Server was installed, this can be corrected by re-
copying the DB-Library and Net-Library files from a source such as CD-ROM.
There is no other side-affect to the strange date/time display, and the
version number is unaffected, so re-copying the files is optional.
Additional query words: file date getfiletime fstat ntwdbver dblib
Keywords : kbprg SSrvDB_Lib SSrvWinNT
Version : 4.2
Platform : WINDOWS
Issue type : Last Reviewed: March 20, 1999