Getting the file creation time on a remote file without dl'g

I've asked this before but have not gotten it to work. I want to be able to connect to a remote ftp host and check to see if there are any files that are more than 2 weeks old. If there is, then download the file.

This seems simple enough. I can use wininet to connect to the remote ftp host but having problem listing the creation time.

I have used "GetFileTime", which requires "OpenFile", but this only works with files that are local. Can anyone help with this. Maybe I'm going about this the wrong way or using the wrong dll.

I've tried "FileTimeToLocalFileTime" and "FileTimeToSystemTime" but both seem to relate to local files and not remote files.
I don't want to have to download the file first and then check the creation date. If the file is hugh, this could take some time.

Been working on this for a week.

Check out the InternetFindFirstFile and InternetFindNextFile API functions... they return a structure which has the info you need.

DJ

Tried that. the information I need is a FILETIME data type and I need to convert it to SystemTime. When I tried the function "FileTimeToSystemTime" to convert the FILETIME to SYSTEMTIME, it would not work. I've tried the ones that comes with the API Guide applicaiton (http://www.allapi.net/).

private Type FILETIME
dwLowDateTime as Long
dwHighDateTime as Long
End Type

private Type SYSTEMTIME
wYear as Integer
wMonth as Integer
wDayOfWeek as Integer
wDay as Integer
wHour as Integer
wMinute as Integer
wSecond as Integer
wMilliseconds as Integer
End Type

private Type WIN32_FIND_DATA
dwFileAttributes as Long
ftCreationTime as FILETIME
ftLastAccessTime as FILETIME
ftLastWriteTime as FILETIME
nFileSizeHigh as Long
nFileSizeLow as Long
dwReserved0 as Long
dwReserved1 as Long
cFileName as string * MAX_PATH
cAlternate as string * 14
End Type

Declare Function InternetFindNextFile Lib "wininet.dll" Alias "InternetFindNextFileA" (byval hFind as Long, lpvFindData as WIN32_FIND_DATA) as Long

Declare Function FileTimeToSystemTime Lib "kernel32" Alias "FileTimeToSystemTime" (lpFileTime as FILETIME, lpSystemTime as SYSTEMTIME) as Long



Any samples would help.

I'm using the same example you are (from allapi.net)... instead of passing the ftCreationTime member to FileTimeToSystemTime, try the ftLastWriteTime and see if it works. For some reason it's not filling in the ftCreationTime, but IS the ftLastWritetime. This may have something to do with file access on the server or ???? I have read/write, etc. access, but don't have administrator rights.

That was my problem the whole time. If I could give you a higher rating, I would. I have administrator rights on that machine and it was giving me year = 1601, month = 1, day = 1. When I changed it to FileTimeToSystemTime(pData.ftLastWriteTime, SysTime), it worked.

Thanks alot
Mike

I also just noticed in the MSDN Docs it DOES state that if the file sytems doesn't support the CreateTime, LastAccess, or LastWrite times that they will be set to Zero, so this may also apply. (partial copy below)!



ftCreationTime
Specifies a FILETIME structure containing the time the file was created. FindFirstFile and FindNextFile report file times in Coordinated Universal Time (UTC) format. These functions set the FILETIME members to zero if the file system containing the file does not support this time member. You can use the FileTimeToLocalFileTime function to convert from UTC to local time, and then use the FileTimeToSystemTime function to convert the local time to a SYSTEMTIME structure containing individual members for the month, day, year, weekday, hour, minute, second, and millisecond.
ftLastAccessTime
Specifies a FILETIME structure containing the time that the file was last accessed. The time is in UTC format; the FILETIME members are zero if the file system does not support this time member.
ftLastWriteTime
Specifies a FILETIME structure containing the time that the file was last written to. The time is in UTC format; the FILETIME members are zero if the file system does not support this time member.

Later!!