Time offset

Hi, just upgraded, current info below. Noticed the new version isn't respecting time offset. Example, local file date/time: 03/24/08 08:32, uploaded version 03/24/08 16:32. And yes, my offset is -8 (pacific). Pretty funny, as the file is uploaded, it *initially* shows 08:32, then flips to 16:32.

My current build:
+- System -----------------------------
Microsoft Windows Vista Ultimate Edition
(Build 6000)

CPU Speed : 2399 MHz
Total Memory : 2047 MB
Free Memory : 1132 MB

+- SmartFTP ---------------------------
Version : 3.0.1011.0
Time Stamp : 2008-03-24 09:34:32
Platform : x86

+- Application DLL --------------------
sfFTPLib.dll : 1.5.12.32
sfFavorites.dll : 1.0.7.0
sfFavoritesShellExtension.dll : 1.0.1.9
sfTransferQueue.dll : 1.0.4.0
sfFTPShellExtension.dll : 1.0.2.0

+- Language ---------------------------
SmartFTP.exe : 3.0.1011.0

+- Internet Explorer ------------------
Version : 7.0.6000.16609

+- Winsock ----------------------------
Winsock : 2.2

Did you set a time offset in the favorite settings?

Can you post the log of your FTP session? Does your server support MLSD or just LIST?

Regards,
Mat

Couple more pieces of info for you...

1. this was an upgrade of a working 2.5 install
2. server is unix, centos 4.5 , tell me how to get what info you want below, would be happy to do it.
3. have not set an offset in favorite settings, this anomoly came in with the 3.0 upgrade.
4. ended up here in the forums after searching KB to no avail, looking for setting for offset, time, etc.....
5. after finding another bug was fixed (overwrite warn window) by upgrading (initial was 3.0.1010.19), thought this was another bug

If you can point me to this offset setting, would be happy to check, either I am blind, or need another cup of coffee this am, not finding it.
Thanks!


Did you set a time offset in the favorite settings?

Can you post the log of your FTP session? Does your server support MLSD or just LIST?

Regards,
Mat

Hello ..

The reason you see this behavior as as following. Your server returns the time in local time in the directory listing (bad). But when SmartFTP updates the view it uses another command (MDTM) to get the UTC time of one file (better). Therefore after the update the time is in UTC and converted to the local time of your computer (correct).

You can set the time zone of your server in the favorite setting. To do this go to the menu: Favorites->Edit Favorites. Find your favorite (look in the Quick Connect folder). Then right click on the favorite and select Properties. In the General dialog set the timezone.

Regards,
Mat
SmartFTP

Ahhh....

Again, keep in mind, this *did* just come in with 3.0.....

found the setting (have never set this in the past), changed it
shut down
restarted smartFTP
file time local: 08:32
Remote: 16:32
uploaded file
smartFTP remote window file time flipped to 08:32 then bounced back to 16:32

?
Hello ..

The reason you see this behavior as as following. Your server returns the time in local time in the directory listing (bad). But when SmartFTP updates the view it uses another command (MDTM) to get the UTC time of one file (better). Therefore after the update the time is in UTC and converted to the local time of your computer (correct).

You can set the time zone of your server in the favorite setting. To do this go to the menu: Favorites->Edit Favorites. Find your favorite (look in the Quick Connect folder). Then right click on the favorite and select Properties. In the General dialog set the timezone.

Regards,
Mat
SmartFTP

Could you please post the log of your FTP session?
https://www.smartftp.com/support/kb/how- ... f2564.html

Please include the raw directory listing as well (right click on the folder then show raw listing).

Regards,
Mat

There is a actually a bug in v3.0 that the timezone settings in the favorite settings is ingored. Fix on the way.

Regards,
Mat

Matt,

Sorry, I must have been speed reading your note on the "how to print log files...." just put me in the "this guy is multitasking, needs another pot of coffee" file..........

Glad to hear I am not seeing things regarding the timezone issue.....will wait for the patch
Thanks!
Dave
There is a actually a bug in v3.0 that the timezone settings in the favorite settings is ingored. Fix on the way.

Regards,
Mat

Hm actually the bug is only if the server doesn't support MLSD. But from the raw listing you posted I can see that your server supports MLSD. It means the time you see in the listing is in UTC. SmartFTP then converts it to your local time.

Can you post the log from your FTP session. It should include a MLST command which is sent after the transfer.
https://www.smartftp.com/support/kb/how- ... f2564.html

Also please post the raw directory listing right after the transfer completes. This way we can compare the time in the listing and the time from the MLST command.

What is the correct time btw? 8:32 I assume. Right?

Regards,
Mat

Sorry, hit save before answering last question, in this case, 11:23 IS LOCAL TIME (and remote time as well)
Dave
Mat,

Did a couple uploads then did the log, last one was after making an edit to the file, results:
local: 11:23
remote:19:23
Forgot to mention earlier, but server is in same timezone as me.
============
[11:18:50] SmartFTP v3.0.1011.0
[11:18:52] Resolving host name "38.113.114.179"
[11:18:52] Connecting to 38.113.114.179 Port: 21
[11:18:52] Connected to 38.113.114.179.
[11:18:52] 220---------- Welcome to Pure-FTPd [TLS] ----------
[11:18:52] 220-You are user number 2 of 50 allowed.
[11:18:52] 220-Local time is now 11:13. Server port: 21.
[11:18:52] 220-This is a private system - No anonymous login
[11:18:52] 220-IPv6 connections are also welcome on this server.
[11:18:52] 220 You will be disconnected after 15 minutes of inactivity.
[11:18:52] USER jerkynet
[11:18:53] 331 User jerkynet OK. Password required
[11:18:53] PASS (hidden)
[11:18:53] 230-User jerkynet has group access to: jerkynet
[11:18:53] 230 OK. Current restricted directory is /
[11:18:53] SYST
[11:18:53] 215 UNIX Type: L8
[11:18:53] Detected Server Type: UNIX
[11:18:53] FEAT
[11:18:53] 211-Extensions supported:
[11:18:53] EPRT
[11:18:53] IDLE
[11:18:53] MDTM
[11:18:53] SIZE
[11:18:53] REST STREAM
[11:18:53] MLST type*;size*;sizd*;modify*;UNIX.mode*;UNIX.uid*;UNIX.gid*;unique*;
[11:18:53] MLSD
[11:18:53] ESTP
[11:18:53] PASV
[11:18:53] EPSV
[11:18:53] SPSV
[11:18:53] ESTA
[11:18:53] AUTH TLS
[11:18:53] PBSZ
[11:18:53] PROT
[11:18:53] 211 End.
[11:18:53] Detected Server Software: PureFTPd
[11:18:53] PWD
[11:18:53] 257 "/" is your current location
[11:18:53] CWD /www/store/includes/templates/template_default/sideboxes
[11:18:53] 250 OK. Current directory is /www/store/includes/templates/template_default/sideboxes
[11:18:53] PWD
[11:18:53] 257 "/www/store/includes/templates/template_default/sideboxes" is your current location
[11:18:53] TYPE A
[11:18:53] 200 TYPE is now ASCII
[11:18:53] PASV
[11:18:53] 227 Entering Passive Mode (38,113,114,179,232,177)
[11:18:53] Opening data connection to 38.113.114.179 Port: 59569
[11:18:53] MLSD
[11:18:54] 150 Accepted data connection
[11:18:54] 226-Options: -a -l
[11:18:54] 226 39 matches total
[11:18:54] 5037 bytes transferred. (24.4 KB/s) (201 ms)
[11:22:00] MLST tpl_ccards_sidebox.php
[11:22:00] 250-Begin
[11:22:00] type=file;size=1698;modify=20080325004127;UNIX.mode=0644;UNIX.uid=32009;UNIX.gid
=32011;unique=808g1969073; tpl_ccards_sidebox.php
[11:22:00] 250 End.
[11:22:00] TYPE I
[11:22:00] 200 TYPE is now 8-bit binary
[11:22:00] SIZE tpl_ccards_sidebox.php
[11:22:00] 213 1698
[11:22:00] MDTM tpl_ccards_sidebox.php
[11:22:00] 213 20080325004127
[11:22:01] The operation has been added to the Transfer Queue. Check the Transfer Queue for the status.
[11:22:02] MLST tpl_ccards_sidebox.php
[11:22:02] 250-Begin
[11:22:02] type=file;size=1698;modify=20080324181700;UNIX.mode=0644;UNIX.uid=32009;UNIX.gid
=32011;unique=808g1969073; tpl_ccards_sidebox.php
[11:22:02] 250 End.
[11:22:02] SIZE tpl_ccards_sidebox.php
[11:22:03] 213 1698
[11:22:03] MDTM tpl_ccards_sidebox.php
[11:22:03] 213 20080325004127

The server has 2 bugs:
1. Wrong MLST reply. 2nd line is not prefixed.
2. Wrong MDTM reply. The time is wrong. It should be the same as in the MLST reply.

I think the PureFTPd dev has fixed these problems already. So I recommend you to contact the server administrator to request a FTP server software upgrade.

We can implement a workaround for the wrong MLST reply which should as a side effect make the the time display correctly as it doesn't need the broken MDTM command.

Another question. In log you posted the MLST reply line is broken. Is this because you have the Wordwrap in the log enabled?

Regards,
Mat

Mat,

While I am not going to argue wiht you, as it would seem you know what you are talking about, a simple test here, provides more finger pointing at smartftp

open cmd window
ftp to same site
binary
put file

ssh window on the server:
-rw-r--r-- 1 jerkynet jerkynet 2083 Mar 24 11:33 download.zip (file uploaded from cmd window)
file just uploaded to same dir with smartFTP
-rw-r--r-- 1 jerkynet jerkynet 1690 Mar 24 2008 tpl_ccards_sidebox_mat

Does this help?

still (to me, not completely understanding your statement re; MLST) seems pinned to smartftp?

wouldn't you expect smart and cmd ftp to produce same problem? if this MLST or MDTM (server side is wrong) was the issue?

Dave
The server has 2 bugs:
1. Wrong MLST reply. 2nd line is not prefixed.
2. Wrong MDTM reply. The time is wrong. It should be the same as in the MLST reply.

I think the PureFTPd dev has fixed these problems already. So I recommend you to contact the server administrator to request a FTP server software upgrade.

We can implement a workaround for the wrong MLST reply which should as a side effect make the the time display correctly as it doesn't need the broken MDTM command.

Another question. In log you posted the MLST reply line is broken. Is this because you have the Wordwrap in the log enabled?

Regards,
Mat

Again, applogies for the speed read....re; ml line broken in the log I sent, how bout this one?
===========
[11:33:13] SmartFTP v3.0.1011.0
[11:33:15] Resolving host name "38.113.114.179"
[11:33:15] Connecting to 38.113.114.179 Port: 21
[11:33:15] Connected to 38.113.114.179.
[11:33:15] 220---------- Welcome to Pure-FTPd [TLS] ----------
[11:33:15] 220-You are user number 1 of 50 allowed.
[11:33:15] 220-Local time is now 11:28. Server port: 21.
[11:33:15] 220-This is a private system - No anonymous login
[11:33:15] 220-IPv6 connections are also welcome on this server.
[11:33:15] 220 You will be disconnected after 15 minutes of inactivity.
[11:33:15] USER jerkynet
[11:33:15] 331 User jerkynet OK. Password required
[11:33:15] PASS (hidden)
[11:33:15] 230-User jerkynet has group access to: jerkynet
[11:33:15] 230 OK. Current restricted directory is /
[11:33:15] SYST
[11:33:15] 215 UNIX Type: L8
[11:33:15] Detected Server Type: UNIX
[11:33:15] FEAT
[11:33:15] 211-Extensions supported:
[11:33:15] EPRT
[11:33:15] IDLE
[11:33:15] MDTM
[11:33:15] SIZE
[11:33:15] REST STREAM
[11:33:15] MLST type*;size*;sizd*;modify*;UNIX.mode*;UNIX.uid*;UNIX.gid*;unique*;
[11:33:15] MLSD
[11:33:15] ESTP
[11:33:15] PASV
[11:33:15] EPSV
[11:33:15] SPSV
[11:33:16] ESTA
[11:33:16] AUTH TLS
[11:33:16] PBSZ
[11:33:16] PROT
[11:33:16] 211 End.
[11:33:16] Detected Server Software: PureFTPd
[11:33:16] PWD
[11:33:16] 257 "/" is your current location
[11:33:16] CWD /www/store/includes/templates/template_default/sideboxes
[11:33:16] 250 OK. Current directory is /www/store/includes/templates/template_default/sideboxes
[11:33:16] PWD
[11:33:16] 257 "/www/store/includes/templates/template_default/sideboxes" is your current location
[11:33:16] TYPE A
[11:33:16] 200 TYPE is now ASCII
[11:33:16] PASV
[11:33:16] 227 Entering Passive Mode (38,113,114,179,206,41)
[11:33:16] Opening data connection to 38.113.114.179 Port: 52777
[11:33:16] MLSD
[11:33:16] 150 Accepted data connection
[11:33:16] 226-Options: -a -l
[11:33:16] 226 39 matches total
[11:33:16] 5037 bytes transferred. (23.7 KB/s) (207 ms)
[11:33:31] MLST tpl_ccards_sidebox.php
[11:33:31] 250-Begin
[11:33:31] type=file;size=1690;modify=20080325022352;UNIX.mode=0644;UNIX.uid=32009;UNIX.gid
=32011;unique=808g1969073; tpl_ccards_sidebox.php
[11:33:31] 250 End.
[11:33:31] TYPE I
[11:33:31] 200 TYPE is now 8-bit binary
[11:33:31] SIZE tpl_ccards_sidebox.php
[11:33:31] 213 1690
[11:33:31] MDTM tpl_ccards_sidebox.php
[11:33:32] 213 20080325022352
[11:33:33] The operation has been added to the Transfer Queue. Check the Transfer Queue for the status.
[11:33:34] MLST tpl_ccards_sidebox.php
[11:33:35] 250-Begin
[11:33:35] type=file;size=1690;modify=20080324182832;UNIX.mode=0644;UNIX.uid=32009;UNIX.gid
=32011;unique=808g1969073; tpl_ccards_sidebox.php
[11:33:35] 250 End.
[11:33:35] SIZE tpl_ccards_sidebox.php
[11:33:35] 213 1690
[11:33:35] MDTM tpl_ccards_sidebox.php
[11:33:35] 213 20080325022352
[11:34:40] MLST tpl_ccards_sidebox.php
[11:34:40] 250-Begin
[11:34:40] type=file;size=1690;modify=20080325022352;UNIX.mode=0644;UNIX.uid=32009;UNIX.gid
=32011;unique=808g1969073; tpl_ccards_sidebox.php
[11:34:40] 250 End.
[11:34:40] SIZE tpl_ccards_sidebox.php
[11:34:40] 213 1690
[11:34:40] MDTM tpl_ccards_sidebox.php
[11:34:40] 213 20080325022352
[11:34:41] The operation has been added to the Transfer Queue. Check the Transfer Queue for the status.
[11:34:43] MLST tpl_ccards_sidebox.php
[11:34:44] 250-Begin
[11:34:44] type=file;size=1690;modify=20080324182941;UNIX.mode=0644;UNIX.uid=32009;UNIX.gid
=32011;unique=808g1969073; tpl_ccards_sidebox.php
[11:34:44] 250 End.
[11:34:44] SIZE tpl_ccards_sidebox.php
[11:34:44] 213 1690
[11:34:44] MDTM tpl_ccards_sidebox.php
[11:34:44] 213 20080325022352
[11:35:12] MLST tpl_ccards_sidebox_mat
[11:35:12] 550 Can't check for file existence
[11:35:12] The operation has been added to the Transfer Queue. Check the Transfer Queue for the status.
[11:35:14] MLST tpl_ccards_sidebox_mat
[11:35:14] 250-Begin
[11:35:14] type=file;size=1690;modify=20080324183011;UNIX.mode=0644;UNIX.uid=32009;UNIX.gid
=32011;unique=808g196908f; tpl_ccards_sidebox_mat
[11:35:14] 250 End.
[11:35:14] SIZE tpl_ccards_sidebox_mat
[11:35:14] 213 1690
[11:35:14] MDTM tpl_ccards_sidebox_mat
[11:35:14] 213 20080325023502
[11:35:28] DELE tpl_ccards_sidebox_mat
[11:35:28] 250 Deleted tpl_ccards_sidebox_mat
[11:36:41] Server closed connection
[11:38:28] Resolving host name "38.113.114.179"
[11:38:28] Connecting to 38.113.114.179 Port: 21
[11:38:28] Connected to 38.113.114.179.
[11:38:28] 220---------- Welcome to Pure-FTPd [TLS] ----------
[11:38:28] 220-You are user number 2 of 50 allowed.
[11:38:28] 220-Local time is now 11:33. Server port: 21.
[11:38:28] 220-This is a private system - No anonymous login
[11:38:28] 220-IPv6 connections are also welcome on this server.
[11:38:28] 220 You will be disconnected after 15 minutes of inactivity.
[11:38:28] USER jerkynet
[11:38:28] 331 User jerkynet OK. Password required
[11:38:28] PASS (hidden)
[11:38:28] 230-User jerkynet has group access to: jerkynet
[11:38:28] 230 OK. Current restricted directory is /
[11:38:28] SYST
[11:38:28] 215 UNIX Type: L8
[11:38:28] Detected Server Type: UNIX
[11:38:28] FEAT
[11:38:29] 211-Extensions supported:
[11:38:29] EPRT
[11:38:29] IDLE
[11:38:29] MDTM
[11:38:29] SIZE
[11:38:29] REST STREAM
[11:38:29] MLST type*;size*;sizd*;modify*;UNIX.mode*;UNIX.uid*;UNIX.gid*;unique*;
[11:38:29] MLSD
[11:38:29] ESTP
[11:38:29] PASV
[11:38:29] EPSV
[11:38:29] SPSV
[11:38:29] ESTA
[11:38:29] AUTH TLS
[11:38:29] PBSZ
[11:38:29] PROT
[11:38:29] 211 End.
[11:38:29] Detected Server Software: PureFTPd
[11:38:29] PWD
[11:38:29] 257 "/" is your current location
[11:38:29] TYPE A
[11:38:29] 200 TYPE is now ASCII
[11:38:29] PASV
[11:38:29] 227 Entering Passive Mode (38,113,114,179,134,53)
[11:38:29] Opening data connection to 38.113.114.179 Port: 34357
[11:38:29] MLSD
[11:38:29] 150 Accepted data connection
[11:38:29] 3461 bytes transferred. (27.4 KB/s) (123 ms)
[11:38:29] 226-Options: -a -l
[11:38:29] 226 30 matches total
[11:38:45] MLST tpl_ccards_sidebox_mat
[11:38:45] 550 Can't check for file existence
[11:38:45] The operation has been added to the Transfer Queue. Check the Transfer Queue for the status.
[11:38:46] MLST tpl_ccards_sidebox_mat
[11:38:46] 250-Begin
[11:38:46] type=file;size=1690;modify=20080324183343;UNIX.mode=0644;UNIX.uid=32009;UNIX.gid
=32011;unique=808g19591fd; tpl_ccards_sidebox_mat
[11:38:46] 250 End.
[11:38:46] TYPE I
[11:38:46] 200 TYPE is now 8-bit binary
[11:38:46] SIZE tpl_ccards_sidebox_mat
[11:38:46] 213 1690
[11:38:46] MDTM tpl_ccards_sidebox_mat
[11:38:46] 213 20080325023502
Mat,

While I am not going to argue wiht you, as it would seem you know what you are talking about, a simple test here, provides more finger pointing at smartftp

open cmd window
ftp to same site
binary
put file

ssh window on the server:
-rw-r--r-- 1 jerkynet jerkynet 2083 Mar 24 11:33 download.zip (file uploaded from cmd window)
file just uploaded to same dir with smartFTP
-rw-r--r-- 1 jerkynet jerkynet 1690 Mar 24 2008 tpl_ccards_sidebox_mat

Does this help?

still (to me, not completely understanding your statement re; MLST) seems pinned to smartftp?

wouldn't you expect smart and cmd ftp to produce same problem? if this MLST or MDTM (server side is wrong) was the issue?

Dave

The workaround for the FTP server is coming.

Referring to your tests:
>ssh window on the server:
>-rw-r--r-- 1 jerkynet jerkynet 2083 Mar 24 11:33 download.zip (file uploaded from cmd window)
>file just uploaded to same dir with smartFTP
>-rw-r--r-- 1 jerkynet jerkynet 1690 Mar 24 2008 tpl_ccards_sidebox_mat

SmartFTP sets the time of the remote file after the transfer (to the time of the source file) if you have the "keep file time" option enabled in the favorite settings. By default this is on and should be kept like that. The command ftp client doesn't set the time of the remote file to the one from source. That is why the time is different.
However this behavior didn't change between version 2.5 and 3.0.

Couple points of interest for your developers.....

2.5 (on this note) was different, not a problem
your explaination of how the time is set on the file actually I can see it happen "before my eyes..."

smart uploads file, server side sees proper time
I then see smart change the file date
done

The other interesting point to bring to thier attention.....assuming we were going in this direction, I changed my smartftp favorite time zone to +8 (from -8), saved, exited smartftp
restarted smart ftp
edited a file
pushed it over
same **exact** file date ie; assuming this was a bug of sorts, pushing back to GMT or +8 wouldn't you have expected the date to move around on the server side with the new upload?

Dave
The workaround for the FTP server is coming.

Referring to your tests:
>ssh window on the server:
>-rw-r--r-- 1 jerkynet jerkynet 2083 Mar 24 11:33 download.zip (file uploaded from cmd window)
>file just uploaded to same dir with smartFTP
>-rw-r--r-- 1 jerkynet jerkynet 1690 Mar 24 2008 tpl_ccards_sidebox_mat

SmartFTP sets the time of the remote file after the transfer (to the time of the source file) if you have the "keep file time" option enabled in the favorite settings. By default this is on and should be kept like that. The command ftp client doesn't set the time of the remote file to the one from source. That is why the time is different.
However this behavior didn't change between version 2.5 and 3.0.

Try the latest version:
https://www.smartftp.com/download

Regardless whether the problem persits please post the log from the Remote Browser after the transfer.

Thank you
Regards,
Mat

Hm. The Remote Browser should display the same time format as the Local Browser and the Windows Explorer.

Would you mind to post a screenshot showing the different format?
https://www.smartftp.com/support/kb/how- ... f2598.html

Regards,
Mat

Please post the logs and a screenshot.

Thank you.

The log from the Transfer Queue is missing. To you can get it by stopping the Transfer Queue. Then add the upload. Then double click the item in the Transfer Queue to get the log window. Then start the Transfer Queue.

However I'm pretty sure it's the same bug as before: the server returns the wrong time in the MLST reply. It worked once because SmartFTP did ignore the wrong MLST reply (as it's also not correctly formatted). However we have since written a workaround for servers returning wrong MLST replies and therefore we use the information from the reply.

My best advice is to contact the server administrator and ask him to upgrade the PureFTPD server software that is running on the server.

Regards,
Mat

Currently running Pure-FTP vers: 1.0.21 latest version, been on this for sometime........
Also, please don't forget, this all started with vers 3.x smart
Dave


Thank you.

The log from the Transfer Queue is missing. To you can get it by stopping the Transfer Queue. Then add the upload. Then double click the item in the Transfer Queue to get the log window. Then start the Transfer Queue.

However I'm pretty sure it's the same bug as before: the server returns the wrong time in the MLST reply. It worked once because SmartFTP did ignore the wrong MLST reply (as it's also not correctly formatted). However we have since written a workaround for servers returning wrong MLST replies and therefore we use the information from the reply.

My best advice is to contact the server administrator and ask him to upgrade the PureFTPD server software that is running on the server.

Regards,
Mat

Well if you would post the log I can tell you for sure where the problem is. I need to see the corresponding logs from the Remote Browser and the Transfer Queue.

Regards,
Mat

Matt,
Sorry for being a bit slow this am, but I am not understanding what you need....., didn't understand your instructions above.........?
Dave
Well if you would post the log I can tell you for sure where the problem is. I need to see the corresponding logs from the Remote Browser and the Transfer Queue.

Regards,
Mat

Please try the newest version (.4):
https://www.smartftp.com/download

I have fixed a timing issue. The final notify message from the Transfer Queue is now always sent after the remote file time has been set.

Thank you for your time :-)
Regards,
Mat

Hello ...

Could you please provide the following:
1. Log from Remote Browser
2. Log from Transfer Queue: You can get it by stopping the Transfer Queue. Then add the upload. Then double click the item in the Transfer Queue to get the log window. Then start the Transfer Queue.
3. Screenshot showing the Remote Browser before the upload and after the upload
4. Time of the file you are uploading on your local computer (in local time as it is displayed in Windows Explorer/Local Browser)

Thank you
Mat

Thanks. One question. Is your local drive D: formatted with NTFS or FAT32? To figure this out right click on the drive letter D: in Windows Explorer or in the Local Browser and select Properties from the context menu. The File system is displayed in the General dialog.

Hello ...

You can see from the Transfer Queue log:

[12:09:00] 226-File successfully transferred
[12:09:00] 226 0.083 seconds (measured here), 0.68 Kbytes per second
-- cut
[12:09:00] SITE UTIME test.txt 20080401190806 20080401190806 20080401190806 UTC
[12:09:00] 250 UTIME OK
[12:09:00] MLST test.txt
[12:09:00] 250-Begin
[12:09:00] type=file;size=58;modify=20080402030806;UNIX.mode=0644;UNIX.uid=32009;UNIX.gid=3
2011;unique=808g19ac4ea; test.txt
[12:09:00] 250 End.

That the MLST time returned by the server is incorrect. SITE UTIME sets the time of the remote file which is 20080401190806. Then right after that MLST returns the time of the file as: 20080402030806
Both time values for the SITE UTIME and the MLST should be same and in UTC. However it seems that PureFTPd returns the time in local time in the MLST reply.
That's the reason you see the wrong time in the Remote Browser.

I have now contacted the pureftpd developer regarding this issue. I will let you konw if there are any news.

Regards,
Mat

Thanks mat, standing by..........
Dave
Hello ...

You can see from the Transfer Queue log:

[12:09:00] 226-File successfully transferred
[12:09:00] 226 0.083 seconds (measured here), 0.68 Kbytes per second
-- cut
[12:09:00] SITE UTIME test.txt 20080401190806 20080401190806 20080401190806 UTC
[12:09:00] 250 UTIME OK
[12:09:00] MLST test.txt
[12:09:00] 250-Begin
[12:09:00] type=file;size=58;modify=20080402030806;UNIX.mode=0644;UNIX.uid=32009;UNIX.gid=3
2011;unique=808g19ac4ea; test.txt
[12:09:00] 250 End.

That the MLST time returned by the server is incorrect. SITE UTIME sets the time of the remote file which is 20080401190806. Then right after that MLST returns the time of the file as: 20080402030806
Both time values for the SITE UTIME and the MLST should be same and in UTC. However it seems that PureFTPd returns the time in local time in the MLST reply.
That's the reason you see the wrong time in the Remote Browser.

I have now contacted the pureftpd developer regarding this issue. I will let you konw if there are any news.

Regards,
Mat

I have contacted the pureftpd developer 3 times in the last 2 weeks and I haven't received a reply yet. But I'm not that suprised.

Every attempt SmartFTP makes to set the file time on a ProFTP server fails.

[00:43:31] MDTM 20070316170331 cache_trim.sh

[00:43:31] 550 20070316170331 cache_trim.sh: No such file or directory

[00:43:31] MFMT 20070316170331 cache_trim.sh

[00:43:31] 500 MFMT not understood

[00:43:31] SITE UTIME cache_trim.sh 20070316170331 20070316170331 20070316170331 UTC

[00:43:31] 500 'SITE UTIME' not understood

[00:43:31] SITE UTIME 20070316170331 cache_trim.sh

[00:43:31] 500 'SITE UTIME' not understood

But I see no advantage in synchronising the file times so I happily turn this feature off to save a few fractions of a second. I don't really see why "Keep File Time" is on by default.