Getting file time of remote file

Question

My customers asked us to assign the time of the remote file to the local file after downloading so they know the last modification time of the remote file.

So in a TransferComplete event handler, we use the FTPFileTransferEventArgs LastWriteTime to set the last write time of the local file. This works well with one small problem. If the remote site and the local site are not in the same timezone, the LastWriteTime is "auto-corrected" with the timezone difference.

For example, remote file has timestamp of Nov 8 23:59. When retrieved from a location where the timezone is 2 hours ahead, LastWriteTime is Nov 9 02:59.

Using edtFTPnetPRO.dll in a C# .Net 4.0 framework. Examined the DateTime structure but found nothing that helped.

(Also tried GetLastWriteTime(remoteFile) but it returns the same value as LastWriteTime - go figure.)

Suggestions?

Andrew

Answer 1

Yes, the timestamp is returned in local time. Why's that a problem?

Answer 2

Yes, the timestamp is returned in local time. Why's that a problem?

On the remote site, in timezone A, certain files are created throughout the day and placed in a daily folder. When retrieved and placed in the same daily folder, it appears to certain users, that the files are going into the wrong folder due the the "corrected" time stamp.

My customers simply asked if it was possible to set the modified time on the local file to the same value as the modified time on the remote system. LastWriteTime seemed like a straightforward solution until the time showed up in local time.

As explained initially, a file last modified on Nov 8 at 23:59PM on the remote system shows up on the local system with a time of Nov 9 02:00AM. My customers would like both to read Nov 8 23:59PM.

Answer 3

The server actually supplies the timestamp in UTC, and we convert it to local time. So we don't actually get the local time on the server sent to us when a file is downloaded.

What you can do is work out the time difference and set the TimeDifference property. You should be able to do this by doing using GetFileInfos() which does return the server time, and comparing a file's timestamp to that returned by GetLastWriteTime.

Answer 4

The server actually supplies the timestamp in UTC, and we convert it to local time. So we don't actually get the local time on the server sent to us when a file is downloaded.

What you can do is work out the time difference and set the TimeDifference property. You should be able to do this by doing using GetFileInfos() which does return the server time, and comparing a file's timestamp to that returned by GetLastWriteTime.

Turns out my code uses GetFileInfos() to build the list of files to download. And the ModifiedTime inside the FTPFile class has the remote time in it exactly as I needed it. Wasn't necessary to calculate the TimeDifference at all. The "Kind" of the ModifiedTime datetime is Unspecified. See http://msdn.microsoft.com/en-us/library ... .kind.aspx

So right when myClient.DownloadFile() returns, I just create a FileInfo for the local file, check it exists and set the LastWriteTime to the ModifiedTime from FTPFile.

Works great. Hope I haven't overlooked something.

Thanks for pointing that out to me.

Answer 5

That sounds fine.

Answer 6

Well, after upgrading to the newest edtFTP Pro library, the "Kind" of the LastModifiedTime in the FileInfo is UTC as I was warned it should be. Or perhaps it was one of the Microsoft updates.

Back to the drawing board. :(

I think the answer is no but can I get the "date" of the remote system using an FTP command? Is there anything in transferring a file out or getting a directory listing? Maybe creating a new file on the remote system knowing my localtime and then looking at the FileInfo for the newly created file? Have to think my way through some of this. Again.

Answer 7

You can work out the time offset by exploiting an idiosyncrasy of the protocol. The GetLastWriteTime, which uses the MDTM command, returns the time in UTC, whereas the GetFileInfos() method returns timestamps in the local time. What you can therefore do is retrieve a directory listing using GetFileInfos() and then call GetLastWriteTime() for one of the files or directories in the listing. Then timezone offset is the difference between the two.

Please let me know how that goes.

- Hans (EnterpriseDT)

Answer 8

You can work out the time offset by exploiting an idiosyncrasy of the protocol. The GetLastWriteTime, which uses the MDTM command, returns the time in UTC, whereas the GetFileInfos() method returns timestamps in the local time. What you can therefore do is retrieve a directory listing using GetFileInfos() and then call GetLastWriteTime() for one of the files or directories in the listing. Then timezone offset is the difference between the two.

Please let me know how that goes.

- Hans (EnterpriseDT)

:? Ok...

What I want is the timestamp on the client file to be the same as the timestamp on the server file ignoring any timezone differences. As mentioned above, although maybe not clearly, it WAS working! I was using the timestamp from the FTPFile class returned by the GetFileInfos command and assigning it the client file timestamp.

This was working when I was testing in December. However, when I went to check with one of our user's, the timestamps of the files on the client machine weren't the timestamps from the server anymore, they were the timestamps with the difference between the server timezone and the client timezone applied.

When I looked at the FTPFile timestamp, it now showed the "Kind" as UTC where previously it showed as "Unspecified".

I'll look but I don't think I changed any code that would cause this. So I was thinking it was something in the latest edtFTPnetPRO.dll, 8.3.20 that I updated to in my project about the same time...