Community
Participate
Working Groups
The following was discovered using an NT server Serv-U FTP-Server v2.5k for WinSock. With the FTPTargetProvider, after a file is PUT, a LIST is performed to get its remote timestamp. For new files, this LIST sometimes (always?) comes back empty (perhaps the LIST happens too quickly after the PUT) which we use as an indication that the resource doesn't exist. Also, againts the above server, the list seems to return different timestamps for the same file at different times. This may be related to the above problem. The action for this problem is to 1. Investigate if there is anything we can do to avoid throwing an exception when a LIST comes back empty. 2. Document FTP client behavior when used with this server type.
Don't know what's wrong with Part 1 of the problem. Check the raw output from the server. Could be a bad parse case. Part 2 of this behaviour is explained in the source code. FTP timestamps are highly unreliable since they are parsed out from plain text LS-format strings. Don't expect a timestamp to be any more precise than +/- 24h, particularly for old files. There is no general consensus on what timezone to use either, so some servers will print out dates using the local time, but most (should) use GMT. The problem is that the output of the "LIST" command was never intended to be machine- readable. On different platforms, the output will differ. Nowadays, most servers use the 'ls -l' command, but some have their own formats: eg. Windows/DOS, Novell. One possible workaround is to try passing options to the LIST command. In some servers, arguments to LIST will be passed on straight to the LS command so you can tweak the output slightly... or maybe not. All FTP clients that I have seen cope with these problems in one way or another. Try playing around with CuteFTP or the Windows FTP browser (in Explorer, not the command-line). You will notice the same timestamp granulatity issues there (all old files show up as having been last modified at midnight!). Worse, you will encounter various problems dealing with symlinks. CuteFTP guesses that symlinks containing a '.' point to files and those without to directories. IIRC, Explorer filters symlinks right out! That is the reason behind the definition of hasDirectorySemantics() and company in FTPDirectoryEntry. That said, we can make better assumptions about timestamps. For instance, it might be worthwhile adding a "getTimestampGranularity()" method to FTPDirectoryEntry, and to populate the underlying field pessimistically based on how precisely the FTP server specified the date. ie. If we don't get seconds, set it to +/- 60 secs, if we don't get hours or minutes, then +/- 86400 secs.
This bug has not been touched in 2 years. Closing as WONTFIX. If you feel this bug is important, feel free to reopen it.
