Mar 25, 2013 at 10:39 PM
Edited Mar 25, 2013 at 10:52 PM
Upon retrieving list of files from FTP site, I am getting strange values for FtpListItem.Modified property:
When there actually is 2013-03-07 10:02:00, FtpListItem.Modified gives 2003.07.13. 10:02:00
When there actually is 2013-03-08 11:10:00, FtpListItem.Modified gives 2003.08.13. 10:02:00
However, these dates are retrieved correctly:
Seems that the FTPClient likes to
- read the date from what actually is a year,
- read the month from what actually is a date,
- read the year from what actually is a month
That is, this strange behaviour is active unless the date (ie, actual date of the file on FTP server) goes beyond 12, in which case the date is parsed correctly.
Mar 26, 2013 at 1:51 AM
If you're not already, use the debug build or pull in the source and build a debug version. Add a
and log the FTP transaction. Post the file listing back here so that I can read over it and look at adding a parser. What server software are you connecting to as well?
Here it is. The dates in the listing are formatted MM-dd-yy. I don't know what is the server software, this is an outsourced service beyond my reach.
I am using Nautilus (on Ubuntu) as GUI client to this FTP server, and it shows the dates correctly. I never knew that this is not standardized in the FTP protocol - the date formats to be used in file listings, that's quite a bummer. Does the FtpClient library
have the flexibility of specifying the date parsing method?
220 Microsoft FTP Service
331 Password required for MyUserName.
230 User logged in.
211-Extended features supported:
OPTS UTF8 ON
200 OPTS UTF8 command successful - UTF8 encoding now ON.
13.03.26 11:42:30 Connected.
250 CWD command successful.
257 "/MyWorkingDirectory" is current directory.
200 Type set to I.
229 Entering Extended Passive Mode (|||5787|)
125 Data connection already open; Transfer starting.
03-07-13 10:02AM 901 File01.xml
03-07-13 10:03AM 921 File02.xml
03-07-13 10:04AM 904 File03.xml
03-07-13 10:04AM 912 File04.xml
03-08-13 11:10AM 912 File05.xml
03-15-13 02:38PM 912 File06.xml
03-07-13 10:16AM 909 File07.xml
03-07-13 10:16AM 899 File08.xml
03-08-13 10:22AM 904 File09.xml
03-25-13 07:27AM 895 File10.xml
03-08-13 10:22AM 6199 File11.txt
03-25-13 07:22AM 31444 File12.txt
03-25-13 07:24AM 24537 File13.txt
226 Transfer complete.
Mar 26, 2013 at 1:02 PM
This is a regression in the IIS file listing parser, I did some work on UTC dates not that long ago and must have introduced this bug. I'll look into getting it fixed today. To answer your question, it's possible to add your own parsers to System.Net.FtpClient.
There's an example project that shows how to do this. There are multiple ways to get a file listing. On servers that support machine listings, the MLSD command is used which does give a standard format listing. MLSD is the most reliable and the fastest however
not all servers, such as IIS, implement it. The second way is to use LIST which is the most problematic and least reliable. LIST listings are formatted at the discretion of the server software developers. There is no standard or one size fits all solution,
that's why I added a way to add custom parsers. The last way is to use NLST + MDTM + SIZE which is by far the slowest but much more reliable than LIST. In scenarios where reliability and accuracy of date/time values matters, my suggestion is to check the server
capabilities flags for MLSD and if it's not available use FtpListOption.NameList | FtpListOption.SizeModify flags with GetListing() instead.
Anyway, in this particular case you have uncovered a bug and I'll look at getting it fixed.
Mar 26, 2013 at 1:31 PM
should address this issue. I've tested with the file listing sample above as well as against ftp.microsoft.com. One thing to keep in mind is that the dates are assumed to be UTC so your time zone is taken into account. I've compared System.Net.FtpClient's
date/time results against windows explorer's builtin ftp capabilities and they mirror each other. Some ftp clients may take the date/time values literally, no time zone adjustments.
Thanks, works like charm!
Regarding the UTC, are you storing the UTC value and letting the C# to handle the local time zone adjustment, or doing the time zone adjustment calculation yourself? I mean, next week my time zone will switch from GMT+2 to GMT+3 (summer time). Will the march
dates still be GMT +2, even when my current local time zone is GMT +3? That would be kind of confusing - suddenly the modified date changes for all the winter time files, perhaps triggering some "file updated" routines in somebodies code.
Mar 27, 2013 at 2:52 AM
The time zone adjustment is made by the .net runtime when DateTime.Parse() is called.