Forum » .NET assembly / COM library »

Post a reply

Options
Add an Attachment

If you do not want to add an Attachment to your Post, please leave the Fields blank.

(maximum 10 MB; please compress large files; only common media, archive, text and programming file formats are allowed)

Options

Topic review

martin

Re: Timezone offset determination logic for FTP?

All can be seen here: 
. 2024-12-02 13:31:04.078 Timezone difference of -6 detected using file [redacted]/20241202.564_20241202073053816 (Listing: 2024-12-02T06:30:00.000Z, UTC: 2024-12-02T12:30:00.000Z)

It's a difference between timestamp in LIST command (for which the FTP standard does define any specific meaning of the time) and the MDTM command (for which the FTP standard mandates use of UTC timezone). This help WinSCP determine how to interpret the LIST timestamps correctly.

If you need further help, please post comparable logs from session that works and session that does not. And specify a file we should look for, and what time did you expect and what did you get instead.
notedop

I forgot to mention that after I noticed the wrong offset, I had restarted the service again and that immediately fixed the issue. For new files the offset was determined correct.
notedop

Timezone offset determination logic for FTP?

How is the timezone offset being determined? From what I understand for FTP when using the LIST to list directory content, it will use one of the files within the folder to determine the offset. This is also visible from the logs.

Initially it gives a warning: 
. 2024-12-02 13:28:23.420 Detecting timezone difference...
. 2024-12-02 13:28:23.420 Found no file to use for detecting timezone difference
. 2024-12-02 13:28:23.420 Warning: Timezone difference was not detected yet, timestamps may be incorrect

and then once a file is found it will use that to determine the offset: 
. 2024-12-02 13:31:03.347 Detecting timezone difference...
. 2024-12-02 13:31:03.347 Retrieving file information...
> 2024-12-02 13:31:03.348 PWD
< 2024-12-02 13:31:03.493 257 "[redacted]" is current directory.
> 2024-12-02 13:31:03.493 CWD [redacted]/20241202.564_20241202073053816
< 2024-12-02 13:31:03.640 550 The filename, directory name, or volume label syntax is incorrect. 
> 2024-12-02 13:31:03.640 TYPE I
< 2024-12-02 13:31:03.785 200 Type set to I.
> 2024-12-02 13:31:03.786 SIZE /[redacted]/20241202.564_20241202073053816
< 2024-12-02 13:31:03.931 213 6384
> 2024-12-02 13:31:03.931 MDTM [redacted]/20241202.564_20241202073053816
< 2024-12-02 13:31:04.078 213 20241202123054
. 2024-12-02 13:31:04.078 Retrieving file information successful
. 2024-12-02 13:31:04.078 Timezone difference of -6 detected using file [redacted]/20241202.564_20241202073053816 (Listing: 2024-12-02T06:30:00.000Z, UTC: 2024-12-02T12:30:00.000Z)

I am using the .NET WinSCP library to monitor certain folders on a FTP. One of the criteria I am monitoring is the file age. Usually the file timestamp is correct, however over the weekend I suddenly had a time difference of 5 hours.

During the weekend the monitoring service is shutdown during a specific time window. Then at some point it is started again. It seems that after the restart of the service, the monitored folder contained some files which were there for a few hours, waiting to be picked up.

I am wondering, when WinSCP accesses a folder for the first time of the lifecycle of a session and it contains files which are aging, if there could be a disconnect in the determination of the time zone offset. Unfortunately I don't have session logs to confirm that this is what actually happened. I will see if I can do some tests to proof this.

Documentation

Support

Associations

Follow Us