@uploader: So if you download one file only, the timestamp is preserved? And if you select the very same file and one more and download both, it is not preserved for neither of them?

Thanks for your reply.

I've since noticed that it happened when multiple files or a directory of files were downloaded. It preserved it when 1 file was downloaded.

Thanks in advance.

@uploader: Just to make sure: You download files, having Preserve timestamps turned on and still the downloaded files have modification timestamp set to the time of transfer, instead to the same time as the original remote file?

Hello.

I've read the docs and forum threads and I still don't understand:

I'm downloading a backup of files from the webserver, whether I created them then uploaded or webserver-created/modified.

Since they are just backups, I need the timestamps of the original file, regardless of the transfer direction, to stay in tact else it appears that a file has been revised when it hadn't.

How to set WinSCP to do this? I've tried checking and unchecking 'Preserve Presets' and I don't see a difference. It records the time of transfer which does me no good.

Thanks in advance.

I don't think the problem is related to ctime because only os can update it. Users, and WinSCP that is has same rights as the person using it, can change atime and mtime. In this case it seems that WinSCP changes them when it should not.

PS: I just spent last weekend in Prague. Great beer you have there! =)

I'll check the ctime in more detail. So far I haven't paid much attention to it.

The difference between modify (mtime) and change (ctime), in Unixes, is that the former is the time when the data on the file was modified and the latter is the time when any of the attributes of the inode were changed. ctime thus doesn't change only when the file is created but also when it's moved, its permissions are changed, and also if the data changes. User can change atime (access time) and mtime using 'touch' but ctime is only changed by the operating system itself (even root can't change it without playing with the system clock). This may be somewhat hard to understand but its pretty well and clearly explained in https://community.unix.com/t/mtime-ctime-and-atime/155071

To make things even more complicated, these times have different semantics on Windows. I don't know in detail how work there but perhaps someone else can explain briefly or give a link to more information.

In our case the original file was originally created on the remote machine and only edited with WinSCP. Thus it feels pretty weird and wrong that atime and mtime were set like they were. Could it be that when WinSCP is trying to overcome the Windows bug/feature it had itself got a bug?

peke wrote:

Before:
Access: 2006-09-27 21:10:35.000000000 +0300
Modify: 2006-09-27 21:10:35.000000000 +0300
Change: 2006-09-27 21:10:35.000000000 +0300

After:
Access: 2006-09-27 20:11:19.000000000 +0300
Modify: 2006-09-27 20:11:19.000000000 +0300
Change: 2006-09-27 21:11:24.000000000 +0300

As you can see the access and modify times have been set into one hour past. Local time was 21:11 both on the server and on my local machine when I edited the file.

What's a difference between "modify" and "change"? Shouldn't one of them be "create"? Which one? Were the previous version of the file created with WinSCP? If not, then the problem is most probably caused by the "unix vs. win" issue described on timestamps chapter (the one you reference).

1) Have I got the above page correctly and this problem is related to DST?

It is probable.

2) Could the problem be related to our configuration?

I do not think so.

3) Assuming that our configuration is correct, is the change in timestamps a WinSCP bug or a feature?

Feature of WinSCP to overcome bug (or "feature") of Windows.

4) Assuming that the timestamp change is a feature (i.e. configuration is correct and WinSCP behaving as designed), is the configuration I did (set 'Server adjusts DST' on) correct? With this configuration, will WinSCP work as I expect also when DST changes next time?

Depends on what your server is. If Unix, then it probably stops working once DST changes next time. See help for the option you've changed.

Hello,

It seems that WinSCP doesn't always set timestamps correctly when editing files on remote machine. As follows are timestamps reported by stat command before and after editing a file on a Linux server. I edited the file through WinSCP so that I just right clicked the file and selected 'Edit'.

Before:
Access: 2006-09-27 21:10:35.000000000 +0300
Modify: 2006-09-27 21:10:35.000000000 +0300
Change: 2006-09-27 21:10:35.000000000 +0300

After:
Access: 2006-09-27 20:11:19.000000000 +0300
Modify: 2006-09-27 20:11:19.000000000 +0300
Change: 2006-09-27 21:11:24.000000000 +0300

As you can see the access and modify times have been set into one hour past. Local time was 21:11 both on the server and on my local machine when I edited the file.

This change can be very problematic for example if some other other tool or program uses the modify time to check has the file changed or is it newer that some other file. In my case I've had problems with Jython not recompiling *.py files into *.class files – I sent a mail about that to Jython users mailing list a little time ago and it should be visible in archives soon.

I did some further investigating about this problem and noticed that timestamps issues have been discussed in these forums earlier and that there also is a separate page explaining the issue. More importantly, I also noticed that if I configure WinSCP so that from 'Environment' settings I set 'Daylight saving time' to 'Server adjusts DST' timestamps are set correctly when editing files.

I've thus basically found the solution for my problem but there are few things I wanted to make sure and that's why decided to write this post.

1. Have I got the above page correctly and this problem is related to DST?
   
   
2. Could the problem be related to our configuration? Both the local and remote machine ought to be correctly configured but I'm not 100% sure. What should I check to make it sure configuration is not the problem?
   
   
3. Assuming that our configuration is correct, is the change in timestamps a WinSCP bug or a feature?
   
   
4. Assuming that the timestamp change is a feature (i.e. configuration is correct and WinSCP behaving as designed), is the configuration I did (set 'Server adjusts DST' on) correct? With this configuration, will WinSCP work as I expect also when DST changes next time?