I display a folder on an ftp server with x2 (0.0.0.59), then copy a new file to the folder using Filezilla, then use Ctrl-R to refresh the folder in x2, the new file does not shows up. In x2, navigate to a different folder and back, the file is still not there. Close x2 and reopen, now the file is there.
If I do the same experiment using Explorer, the new file shows up after hitting F5 to refresh.
BTW I am running Win2K.
Refresh on ftp folder doesn't work consistently
Moderators: fgagnon, nikos, Site Mods
Yes, ftp with x2 is not always consistent with refresh (or with timestamp translation to/from GMT)
I am also in eastern daylight time zone (currently GMT-4) and have seen both behaviors/behaviours (see below & parallel posting [EDIT: (where I probably should have put this reply) ])
To see for myself how it was working today, I copied two new files to a local ftp-site [& noticed refreshing was very erratic, but chalked it up to network congestion]; but found even more confusion with timestampings: one of the first one's date got translated to current GMT, (as reported by both x2 and WSFTP) and on copy back to local hard drive, it kept the apparent GMT-time as local time (Off by +4hrs).
A second new file had its date apparently shifted (as reported by WSFTP, but kept correct local time when observed with x2. (even after close, then re-open x2. On copyback, its modified date was correct per local time. Also the first file now mysteriously had correct local time on ftp-site via x2!
Then I re-copied back the second file to another local folder, and that copy was now timestamped with its GMT time modified (off by +4 hours).
OS for the above erratic behavour is also w2k.
My bottom-line "take" from this & earlier ftp experiences is that x2 is not designed to be a full-fledged ftp-engine (read: this feature really is in "alpha" status), but still it is a convenience that often works well enough to avoid running a full-fledged ftp-engine. It uses IE to make the connections, and passes the results along; but doesn't yet have all the bugs worked out.
& 
I am also in eastern daylight time zone (currently GMT-4) and have seen both behaviors/behaviours (see below & parallel posting [EDIT: (where I probably should have put this reply) ])
To see for myself how it was working today, I copied two new files to a local ftp-site [& noticed refreshing was very erratic, but chalked it up to network congestion]; but found even more confusion with timestampings: one of the first one's date got translated to current GMT, (as reported by both x2 and WSFTP) and on copy back to local hard drive, it kept the apparent GMT-time as local time (Off by +4hrs).
A second new file had its date apparently shifted (as reported by WSFTP, but kept correct local time when observed with x2. (even after close, then re-open x2. On copyback, its modified date was correct per local time. Also the first file now mysteriously had correct local time on ftp-site via x2!
Then I re-copied back the second file to another local folder, and that copy was now timestamped with its GMT time modified (off by +4 hours).
OS for the above erratic behavour is also w2k.
My bottom-line "take" from this & earlier ftp experiences is that x2 is not designed to be a full-fledged ftp-engine (read: this feature really is in "alpha" status), but still it is a convenience that often works well enough to avoid running a full-fledged ftp-engine. It uses IE to make the connections, and passes the results along; but doesn't yet have all the bugs worked out.
& 