Prev: TrackPopupMenuEx() problem
Next: i want function to know the active language in windows
From: Friedel Jantzen on 10 Nov 2009 01:59
Hi,
I had this problem, too, and afaik there is no real solution for this.
I decided to use log files, where I store the original UTC filetimes.

There are several problems:

1. GetFileTime returns UTC, but FtpFindFirstFile returns the *local*
filetime, not UTC. And rounded down.
I cannot convert this to UTC without information about the servers
timezone bias.

2. FtpFindFirstFile and InternetFindNextFile May Return Incorrect Date:
http://support.microsoft.com/?scid=kb%3Ben-us%3B306587&x=15&y=9
"
When you are using the WinInet API to access File Transfer Protocol (FTP)
servers, the FtpFindFirstFile and InternetFindNextFile functions may return
file dates that are in the future.
CAUSE
Some UNIX FTP servers (or Microsoft Internet Information Services FTP
servers that are configured to run in UNIX folder listing style mode) omit
the year part of the date that is sent along with a directory listing if
the date is recent. In such cases, WinInet assumes the missing year is the
current year and this is reflected in the WIN32_FIND_DATA structure that is
returned. However, depending on how the FTP server was configured, in early
months of the year WinInet may incorrectly assume the current year for a
previous year's date. For example, if the file on the FTP server was
created December 15, 2000, and an application that uses WinInet is executed
on January 15, 2001, the WIN32_FIND_DATA information will contain a file
creation date for the file of December 15, 2001.
RESOLUTION
One way to work around this problem would be to check if the returned date
is in the future. If so, subtract "1" from the year, but keep in mind
situations where the date could actually be in the future such as could
arise from differences in time zones.
"

Incredible!

3. If more users have access to the files, they could create them locally,
but upload them later. In the meantime another user creates a newer version
and uploads it before...
Studying RFC959, I could not find a command to change the filetime stamp on
the ftp server, so that I cannot set it to the original local filetime.

Regards,
Friedel

*******************

Am Mon, 9 Nov 2009 18:50:34 -0800 (PST) schrieb flyingco:

> I'm reading some unexpected file timestamps when I use the WinINet
> FtpFindFirstFile function to examine a file on a remote server. I'm
> using vc6.0 on
> XP Pro SP1 and Win2K SP3. After finding the remote file, I read its
> timestamp
> from the ftLastWriteTime field of the TWin32FindData passed to
> FtpFindFirstFile.
>
> I can create a file when the Now function returns 19/05/2004
> 22:32:39 (UK
> date format) and read its timestamp with FindFirst and TSearchRec's
> FindData.
> ftLastWriteTime. The timestamp is 19/05/2004 21:32:39, i.e. one hour
> older,
> which presumably represents correction from daylight saving time to
> GMT.
>
>
> If I put that file on a remote server, I am told its last write stamp
> is 19
> /05/2003 22:28:00. The month and day are correct, but the year is out
> by one.
> The hour is correct (at least, under daylight saving), and there is a
> three and
> a half minute discrepancy that presumably just means the remote
> server's clock
> isn't set exactly as mine is.
>
> in short ,the ftLastWriteTime is wrong when the following conditions
> match.
>
> if ( local system time < (ftp server file time +8
> hour) )
> {
> The time got by ftLastWriteTime is one year less than the
> correct time.
> }
>
> who can tell me how to resolve or avoid the MICROSOFT bug?
 | 
Pages: 1
Prev: TrackPopupMenuEx() problem
Next: i want function to know the active language in windows