STABLE14-windows-notes-20050404

final updates before 1.3.81


(cherry picked from commit 54d6578ae68f8a093661a69fa763499f10457623)
This commit is contained in:
Jeffrey Altman 2005-04-04 12:51:53 +00:00
parent 926fba3b86
commit 5870535124
2 changed files with 26 additions and 0 deletions

View File

@ -6,6 +6,13 @@ Since 1.3.80:
* Replaced time conversion code (UnixTime <-> FILETIME) to
be completely arithmetic instead of relying on a bizarre
algorithm involving a variety of C RTL time functions.
This has the side effect that UnixTime and FILETIME which
are both stored in UTC are interpretted as UTC throughout
the year. Windows will apply the same localization to AFS
as it does to NTFS. Applications which rely on the ability
to sync files between the two file systems will no longer
see the timestamps of files in AFS change an hour relative
to the files stored in NTFS or Windows based backup devices.
* Fixed a invalid memory access under a bizarre circumstance.
Windows will allow a physical mass media device to be

View File

@ -555,6 +555,25 @@ values using registry keys. This is useful for managed machines in a
Windows domain which are centrally located (e.g., in a computing
lab.) See registry.txt for details on the "Server Preferences" keys.
39. As of 1.3.81, timestamps on file stored in AFS are reported to
Windows in UTC all year round. Previously, in locales with daylight
savings time, the time reported by AFS to Windows when DST is active
was UTC+1. This was done to preserve the relative local time for the
user. A file stored at 11:00am EST in January would be reported as
having been stored at 11:00am EDT in June. Unfortunately, this has
the negative side effect of changing the reported timestamp from 16:00UTC
to 15:00UTC. Since Windows treats all file times in UTC, data
synchronization applications which rely on the timestamp would believe
that all files stored in AFS had changed. This will no longer be the
case.
It should be noted that Unix based operating systems (such as Solaris)
do not appear to report file times to applications in UTC. They do
preserve the relative local time. This may confuse some users who are
used to being able to compare the timestamp in an Unix shell with the
timestamp from the Windows explorer. During DST, these two times will
no longer agree even though they are in fact describing the same time.
------------------------------------------------------------------------
Reporting Bugs: