[TC 11.51rc5] PreserveDates=1 in wcx_ftp.ini causes attempt to preserve dates for uploads when using download list

[white]

Tested with wcx_ftp.ini with the following contents:

[General]
SpecialFlags=16
ConnectRetries=10
WaitDelay=5
transfermode=I
LogFile=%TEMP%\tcftp_rc5.log
FtpInBackground=0
ModeZ=1
AutoResume=30
[default]
PreserveDates=1
PreserveDatesUpload=0

Tested with a download list with the following contents (but username, password and server name are fake) :

Code: Select all

put:d:\test123.txt -> ftp://user:password@ftp.example.com/test123.txt

What the logfile shows:

...
BG:SYST
BG:215 UNIX Type: L8
BG:FEAT
BG:211-Features:
BG: AUTH TLS
BG: EPRT
BG: EPSV
BG: MDTM
BG: PASV
BG: PBSZ
BG: PROT
BG: REST STREAM
BG: SIZE
BG: TVFS
BG: UTF8
BG:211 End
BG:HELP SITE
BG:214-The following commands are recognized.
BG: ABOR ACCT ALLO APPE CDUP CWD DELE EPRT EPSV FEAT HELP LIST MDTM MKD
BG: MODE NLST NOOP OPTS PASS PASV PORT PWD QUIT REIN REST RETR RMD RNFR
BG: RNTO SITE SIZE SMNT STAT STOR STOU STRU SYST TYPE USER XCUP XCWD XMKD
BG: XPWD XRMD
BG:214 Help OK.
BG:OPTS UTF8 ON
BG:200 Always in UTF8 mode.
BG:Connect ok!
...
BG:STOR /test123.txt
BG:150 Ok to send data.
BG:Upload
BG:226 Transfer complete.
BG:MFMT 20250213130225 /test123.txt
BG:500 Unknown command.
BG:SITE UTIME 20250213130225 /test123.txt
BG:500 Unknown SITE command.
BG:SITE UTIME /test123.txt 20250213130225 20250213130225 20250213130225 UTC
BG:500 Unknown SITE command.
BG:SIZE /test123.txt
BG:213 7
BG:Copied (15-02-2025 12:59:06): d:\test123.txt -> ftp://ftp.example.com//test123.txt 7 bytes, 0 bytes/s
BG:QUIT
BG:221 Goodbye.

As you can see, TC attempts to preserve the timestamp of the uploaded file even though the setting "PreserveDatesUpload=0" says not to do so, and even though this server does not support the necessary commands.

This does not happen when uploading the file normally (without download list), even with "PreserveDatesUpload=1" in wcx_ftp.ini.

[ghisler(Author)]

There are two separate problems here, one of which I will fix, but the other is intentional:
1. Sending date change commands like MFMT although the server doesn't support it is not intententional. I will fix it.

2. Using PreserveDates instead of PreserveDatesUpload is intentional. Why? The function is called "FTP download from list". It therefore uses the settings from the last FTP download dialog. This is done because the main purpose of this function is to download files which were previously added to the list via "Download later" checkbox. There is no such checkbox for uploads.
Furthermore, the background transfer manager only maintains one flag for preserving timestamps. Why? You can for example first add some files for download via F5 - Download in background. Then later add some files for upload via "+" button. In this case, you can't choose options like preserve timestamps, so the option from the initial F5 function is used.
Splitting this up would require some extensive changes, e.g. adding files via "+" button would have to ask the user whether they want to preserve timestamps or not. Then the user could choose to add some files with preserving timestamps and some without, and afterwards the user may even change the sort order of the files in the queue.

[white]

2. Using PreserveDates instead of PreserveDatesUpload is intentional. Why? The function is called "FTP download from list". It therefore uses the settings from the last FTP download dialog. This is done because the main purpose of this function is to download files which were previously added to the list via "Download later" checkbox. There is no such checkbox for uploads.

When doing normal FTP transfers (not with download list), whether timestamps should be preserved is remembered separately for downloads and for uploads. Your explanation doesn't make it suddenly expected for the user that this is different for download lists.

Furthermore, it seems that when using download lists, timestamps are never preserved when downloading, but when uploading, timestamps are preserved depending on the last chosen option for downloading without a download list.

Furthermore, the background transfer manager only maintains one flag for preserving timestamps. Why? You can for example first add some files for download via F5 - Download in background. Then later add some files for upload via "+" button. In this case, you can't choose options like preserve timestamps, so the option from the initial F5 function is used.

So I assume the same applies the other way around, when first adding some files for uploading in the background, and then later add files to download via the "+" button?

What if you open the background transfer manager via the main menu and then add files to download or upload? When are timestamps preserved then?

Splitting this up would require some extensive changes, e.g. adding files via "+" button would have to ask the user whether they want to preserve timestamps or not. Then the user could choose to add some files with preserving timestamps and some without, and afterwards the user may even change the sort order of the files in the queue.

Separating the flag for preserving timestamps into 2 flags, one for downloading and one for uploading, does not require extensive changes. It does not necessarily mean that the user should be given the option to change it when using the "+" button. Currently, the user cannot change the flag indicating whether timestamps are preserved during a background transfer session. There is no reason why this must be different when there are 2 flags, one for downloads and one for uploads.

Can you provide me with a ftp test account which supports setting timestamps on the server, so I can test that functionality?

[ghisler(Author)]

Separating the flag for preserving timestamps into 2 flags, one for downloading and one for uploading, does not require extensive changes.

That's not the problem here. The problem is that the user doesn't even see the option. When you FTP download later, the user has the checkbox to preserve dates, therefore this is used. Splitting this up now so late in the beta test will break a LOT of things for users.

Postponed to later release.

[white]

16.02.25 Fixed: FTP download from list: For uploads, don't send the command to preserve timestamps if the server doesn't indicate to support it. Still uses PreserveDates flag for both downloads and uploads (32/64)

The commands to preserve timestamps are no longer sent on the server that doesn't support it. But I haven't been able to test it for a server that does support it, because I have no access to such server.

The text "Still uses PreserveDates flag for both downloads and uploads" is not true. It may hold true for uploads, but as mentioned before, it does not do so for downloads (at least not when I try it).

What the logfile shows:

BG:Copied (15-02-2025 12:59:06): d:\test123.txt -> ftp://ftp.example.com//test123.txt 7 bytes, 0 bytes/s

There is another bug here. When uploading using a download list, the log line like above contains one forward slash too much.
Also when uploading to a subfolder:

BG:Copied (19-02-2025 21:25:09): d:\test123.txt -> ftp://ftp.example.com//test/test123.txt 7 bytes, 0 bytes/s

[ghisler(Author)]

The commands to preserve timestamps are no longer sent on the server that doesn't support it. But I haven't been able to test it for a server that does support it, because I have no access to such server.

I have tried it with ghisler.com which supports it.

The text "Still uses PreserveDates flag for both downloads and uploads" is not true. It may hold true for uploads, but as mentioned before, it does not do so for downloads (at least not when I try it).

The timestamp is only preserved when downloading entire directories from list. Otherwise the timestamp isn't known because it's stored in the directory and not in the file. Getting the entire directory for each downloaded file would be very slow.

There is another bug here. When uploading using a download list, the log line like above contains one forward slash too much.
Also when uploading to a subfolder:

I will check it.

[white]

The timestamp is only preserved when downloading entire directories from list.

Confirmed/tested OK.