Weird behavior of remote timestamps

Advertisement

thor61
Joined:
Posts:
8

Weird behavior of remote timestamps

Dear WinSCP experts,

i have some trouble with timestamps.

My setup ist winscp 5.11.3 build 7995 on windows server 2016 build 1607 and corresponding FTP Server ist vsftpd 3.0.2 on CentOS7, both in Germany, so timezone is GMT+1, and i use FTPS protocol in this context.

WinSCP shows files in the GUI which are already on the FTP Server and which have last modification time (LMT) in december (for example) with correct timestamps (the LMT in WinSCP in the right pane is the same time as with "ls -al" in the linux shell). But files on the FTP Server with LMT in summer 2017 are shown in WinSCP with an offset of -1 hour compared to linux shell.
My origin was using default session properties (MLSD=AUTO), then, because vsftpd has no MLSD feature, i fiddled with MLSD=off and some timezonedifferences, but got only a time shift for all files and on top the same -1h offset for files last modified while DST.
In contrast, FileZilla shows all timestamps consistent as with "ls -al".
I do *not* set vsftpd config option use_localtime=yes, so vsftpd uses UTC timestamps internally, which is the preferred setup. use_localtime=yes is no choice because it would break other dependencies.

I thoroughly read the FAQ about timestamps but i found no reason for this behavior.

Many thanks for a useful explanation.

Roman

Reply with quote

Advertisement

martin
Site Admin
martin avatar
Joined:
Posts:
29,476
Location:
Prague, Czechia

Re: Weird behavior of remote timestamps

Please attach a full session log file showing the problem (using the latest version of WinSCP).

To generate the session log file, enable logging, log in to your server and do the operation and only the operation that causes the error. Submit the log with your post as an attachment. Note that passwords and passphrases not stored in the log. You may want to remove other data you consider sensitive though, such as host names, IP addresses, account names or file names (unless they are relevant to the problem). If you do not want to post the log publicly, you can mark the attachment as private.

Reply with quote

thor61
Joined:
Posts:
8

Hi Martin,

see attached logfile an screenshots.
Thank You for your assistance.

Roman
  • Bildschirmfoto vom 2018-02-24 02-04-36.png (304.27 KB, Private file)
  • Bildschirmfoto vom 2018-02-24 02-08-02.png (23.96 KB, Private file)
  • WinSCP_Session.log (7.8 KB, Private file)

Reply with quote

thor61
Joined:
Posts:
8

Hi Martin,
some words to make things easier ...
The file "Neues Textdokument.txt" was created some days ago in this week and shows the correct date and time (beside the missing seconds) in the right WinSCP pane. The other two files are from september, which was DST. They both have correct date but wrong time (IMHO), shifted one hour in the past, as you can compare with the screenshot from the linux shell.
All remote files were previously uploaded by WinSCP from the local system. The source files are shown in the left pane. As you can see "Neues Textdokument.txt" has the same date and time as the remote copy, but timestamps of the other both files differs.

Reply with quote

thor61
Joined:
Posts:
8

New session log from WinSCP Version 5.13 (Build 8172) attached, same results with this version.
  • WinSCP_Session.log (8.34 KB, Private file)

Reply with quote

Advertisement

thor61
Joined:
Posts:
8

Hi Martin,
seems you are back from vacation.
Do we have any chance to handle the the time offset described in my previous posts?
Thank you
Roman

Reply with quote

martin
Site Admin
martin avatar
Joined:
Posts:
29,476
Location:
Prague, Czechia

As you can see yourself in the log, it's the FTP server that adjusts timestamps of files created in DST by one hour:

Feb 22 12:33 NeuesTextdokument.txt
Sep 29 09:11 TeamViewerQS_de.exe
Sep 22 14:26 allsystem_vor_upd_auf_R5269_2017-09-20-17-57-37.bin

Compare with the timestamps you can see in the shell.

As you seem to have a shell access, I wonder why don't you use SFTP, instead of FTP?

Reply with quote

thor61
Joined:
Posts:
8

Hi Martin,
thank you for your response, i needed some days to think about.
Maybe we have different point of view, but the logfile shows timestamps in UTC, which are absolutely correct. My expectation was either timestamps were represented in realtime (localtime) in the client (WinSCP) or completely in UTC, which would be nice too. But what WinSCP does is simply to add one hour offset to all files, which is wrong in my opinion. To show realtime (localtime) times, WinSCP has to add one hour to "winter"-files and two hours to DST-files, if we refer to my local timezone. FileZilla in contrast makes the correct calculation as you can see in the screenshot i attached for illustration.
Thx, Roman
  • WinSCP_FileZilla.png (723.5 KB, Private file)

Reply with quote

martin
Site Admin
martin avatar
Joined:
Posts:
29,476
Location:
Prague, Czechia

Times as shown by LIST are usually shown in a local time of the server. So usually they are already adjusted for DST in server's timezone. So WinSCP displays them as they are, just adjusted for (detected) timezone difference.
That works for most servers. It may not work for all (such as yours).
FileZilla has a different logic, which happens to work for your server, but will fail for others (unless it has some smart logic to autodetect what logic to use, what I do not think it has).
There would have to be a configuration option to switch between the approaches. Actually WinSCP has that ("Daylight saving time" section), but it's currently implemented for SFTP protocol only.
The primary problem is that your FTP server is obsolete. Modern FTP servers support MLSD command, which is required to return times in UTC. Then, there are no such problems. Your server does not support MLSD.

Reply with quote

Advertisement

thor61
Joined:
Posts:
8

martin wrote:


The primary problem is that your FTP server is obsolete. Modern FTP servers support MLSD command, which is required to return times in UTC. Then, there are no such problems. Your server does not support MLSD.

vsftp does not supprt MLSD, that is a well-known an often criticized fact. But it is not obsolete. vsftp is very popular and it is the default FTP Server in current RHEL7 distribution.

I think a solution for this situation isn't really difficult. Wouldn't it be possible to treat the LIST result the same way like MLSD? Everything would be fine.
Do i have a chance that you will find a simple solution or a workaround? :-)
Thanks in advance,
Roman

Reply with quote

thor61
Joined:
Posts:
8

An other question:

martin wrote:

Times as shown by LIST are usually shown in a local time of the server. So usually they are already adjusted for DST in server's timezone. So WinSCP displays them as they are, just adjusted for (detected) timezone difference.

If WinSCP treats LIST result as local time, why does it add one hour to all this timestamps?

If theoretical my vsftp server delivers already to local time adjusted values by LIST command, it makes much more confusion to add any offset at all.

Reply with quote

martin
Site Admin
martin avatar
Joined:
Posts:
29,476
Location:
Prague, Czechia

Because WinSCP detected 1 hour difference between the server and the client:
. 2018-02-25 13:29:42.815 Timezone difference of -1 detected using file /mnt/FTPPOOL/praxislorenz/backup/ftptest/NeuesTextdokument.txt (Listing: 2018-02-22T11:33:00.000Z, UTF: 2018-02-22T12:33:00.000Z)
You can turn off the detection in session settings.

Reply with quote

Advertisement

You can post new topics in this forum