Archived Forum Post

Index of archived forum posts


FTP/SFTP timestamps

Apr 09 '13 at 10:25

Some time ago, while debugging my program, I noticed a message in the chilkatlog or lasterrortext saying something like

"because the ftp server doesn't support the xxxx command, timestamps are not changed for downloaded files"

It was a different message, but something like that. An indication that Chilkat by default is manipulating the last-modified/creation timestamps of the FTP files.

Is there a setting I can use (or can you implement such a setting for 9.4.1) so chilkat will never "touch" any timestamps? Especially when listing ftp directories I need the timestamps exactly as they are reported by the FTP server.



FTP and SSH/SFTP are entirely different protocols, and therefore different answers apply to each. I'll assume you are only asking about FTP (and FTPS, which is not SSH/SFTP).

The last-modified date/time information available to an FTP client is highly dependent on the FTP server, and can also be dependent on the age of the file in question (with older files possibly lacking time-of-day information). The intent is to always try to maintain the same last-modified date/time.

When an individual file is downloaded, Chilkat will attempt to use the MDTM command to get the date/time information so that it can be set for the local file after download. If MDTM is not supported, then it won't be able to set the date/time. This is probably the message you see.

There's another case though: If the directory listing that contains the file being downloaded was previously downloaded, then the Chilkat FTP2 object will have this information cached. It will automatically use that information (if present) for setting the last-modified date/time of a file being downloaded. However, Chilkat will not automatically attempt to download a directory listing for the sole purpose of obtaining the last-modified date/time. Imagine if you wish to download a small file, but it's located in a directory on the server that contains many files. In these cases, the time to download the directory listing itself would dwarf the time required to download the file. This is the reason Chilkat doesn't do it. If you wish to cache the directory listing, call ChangeRemoteDir to the directory where the file is located, and then access the NumFilesAndDirs property (which triggers a fetch of the directory listing, and caches it in memory).


If we forget about downloading and applying timestamps to the downloaded files, just talking about reporting (the results of a directory listing of the server), for CkSftp I use these calls:


and for CkFtp2 I use

_ftp.GetCreateFTime(i, fTime);
FileTimeToSystemTime(&fTime, &sysTime);
_ftp.GetLastModifiedFTime(i, fTime);
FileTimeToSystemTime(&fTime, &sysTime);

So for both, the dir listing is already cached, I am looping over all directory items.

I would like a consistent reporting of those times. I understand (I have seen it in FileZilla) older files sometimes do not have the hhmmss part reported and I don't mind if CkFtp2 tries to get a better timestamp (using MDTM I guess), that's no problem. If I understand you correctly, the MDTM is only used for FTP(S) and only for downloads (GetFile), not for those directory listings. Is that correct?

What I am worried about is that CK is doing things to those timestamps to "correct for" daylight saving time in some way. With the last switch to DST I got some reports of my program reporting a lot of changed files (timestamps changed). But perhaps those reports were for servers which didnt support MDTM.

Perhaps I should ignore changed files if their (last modified) timestamp is more than XX days old?