GetLastWriteTimeUtc Win98

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

We're writing a routine to synchronize files between clients in various
locations and a central server and have run into a problem with win98
clients. Is there a bug with System.IO.File.GetLastWriteTimeUTC under Win98?
For a given file, shouldn't this return the same date/time no matter what
the timezone or whether daylight savings is in effect? It works that way
under WinXP and Win2K. Is there another way to do this?

Thanks
 
Hi

So far I am researching the issue, I will get back here and update you ASAP.
Thanks for your understanding!

Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.
 
Hi

Based on my research, this is by design.
FAT: (file allocation table)

FAT on 9x has to be compatible with DOS. It does not store UTC time on
disk; it stores local time. So when 9x FAT gives the UTC time back to
Windows, it must first convert Local->UTC.

FAT on NT did not need this compatibility, so they did the "right" thing.
NT FAT stores UTC on disk and always gives Windows the straight UTC time.

So even if you change the machine time zone, NT will always display the
same UTC time. But if you change the time zone on 9x, the Local->UTC
conversion will give you a different time zone.

This is not a problem in our product; this is intentional behavior that
results from the different operating system design requirements.

There really is no workaround. After the time zone is changed, there is no
way to know what the old time zone was. This means that there is no way to
know what time zone is referenced by the "localtime" stored on disk.

Solution: Stop using an operating system that was designed to be
compatible with a 1970's operating system (DOS). Use an operating system
designed for the future (NT/2000/XP/2003/etc).

Note that 9x machines are also designed to be "home" machines. Changing
time zones is not something that should happen very often.


Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.
 
Hi Peter,

I do appriciate you looking into this. However, your solution was not
particularly professional or helpful.

"Stop using an operating system that was designed to be compatible with a
1970's operating system (DOS). Use an operating system designed for the
future (NT/2000/XP/2003/etc)."

Some of us actually work in the real world where we don't have control over
which operating systems our customers use.

--Wayde
 
Hi Wayde,

I am sorry if I have any offence.

Since I have also tried the Windows API that get the file timestamp which
will give the localtime on win9x.
The Windows APIs do not define *any* file time behavior; they only provides
access to the file times as exposed by individual file systems.

BOOL GetLastWriteTime(HANDLE hFile, LPTSTR lpszString)
{
FILETIME ftCreate, ftAccess, ftWrite;
SYSTEMTIME stUTC;

// Retrieve the file times for the file.
if (!GetFileTime(hFile, &ftCreate, &ftAccess, &ftWrite))
return FALSE;

// Convert the last-write time to local time.
FileTimeToSystemTime(&ftWrite, &stUTC);
//SystemTimeToTzSpecificLocalTime(NULL, &stUTC, &stLocal);
cout<<stUTC.wHour<<endl<<stUTC.wMinute<<endl;
// Build a string showing the date and time.
sprintf(lpszString, "%02d/%02d/%d %02d:%02d",
stUTC.wMonth, stUTC.wDay, stUTC.wYear,
stUTC.wHour, stUTC.wMinute);

return TRUE;
}
int _tmain(int argc, _TCHAR* argv[])
{
HANDLE hFile;

hFile = CreateFile(TEXT("C:\\test.txt"), // file to create
GENERIC_WRITE, // open for writing
0, // do not share
NULL, // default security
OPEN_EXISTING, // overwrite existing
FILE_ATTRIBUTE_NORMAL | // normal file
FILE_FLAG_OVERLAPPED, // asynchronous I/O
NULL);
char str[1024];
GetLastWriteTime(hFile,str);
cout<<str<<endl;
return 0;
}

Microsoft only defines 2 file systems: FAT and NTFS. However, it is very
possible that a developer might encounter other 3rd party file systems,
especially when using non-Windows servers. So you may need to be very
careful about what time stamp dependencies they design into their
applications.

Since my test is all based on NTFS or FAT, because the Win9x did not use
NTFS due to its design, we only test it on FAT.
So if you are using a total different FS, e.g. you are reading a file on a
third party file systems. So I think the file behavior, is almost always
file system specific. Here I assume you are testing on win9x, which is
working on FAT filesystem and the test file is also on the FAT FS.

If I have any misunderstanding, please feel free to post here.
I understand that it is hard to replace all the win9x system with NT ones,
but as we state before, it is rarely that the Win9x will change its
timezone frequently. Also based on my test, if we create a file share which
pointed to a foder on a NTFS FS, the GetLastWriteTimeUtc will return the
same UTC time.

If you still have any concern, please feel free to post here.


Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.
 
Hello Peter,

Thank you for providing the backround details on this issue. We have now
come to a similar conclusion that there is no reliable way to include the
file time in our synchronizing process. In addition to the issue with Win
9X customers, some of our customers will be obtaining their initial set of
files from a CD install. We have found that the UTC information is also lost
in this process. So, we will be using only the file date from this point on.

Thank You,

Wayde
 
Back
Top