keep remote directory up to date is writing the date incorrectly

Hi,

If I sync a directory by syncronise remote, or by simply copying the files to the remote directory, the timestamps are correct.

If I then set keep remote directory up to date, and change a file locally, it is uploaded, but then that functionality stops, so I checked the file on the server, and keep remote directory up to date is not setting the changed timestamp correctly ie;

before;
-rw-r--r-- 1 user1 users 2537 Jun 30 12:50 functions.php

after;
-rw-r--r-- 1 user1 users 2538 Jun 30 2004 functions.php

ie the date is only got the year in it.

Any ideas? I would have guessed that winSCP3 would use the same function to upload in keep remote directories up to date is it does for synx and basic upload, but it seems something is different.

Cheers,

Tom H

I have no hint for you. "Keep remote directory up to date" uses the same function to upload the files as basic upload etc.

However in the next version (beta is going out in few days), the "Keep remote directory up to date" function is completely remade. It is more based on "Synchronize" function (among other it is recursive now). So I hope it will work for you.

Hi,

I've the same problem as describted above. After the first copying of the file via 'Keep remote directory up to date', the date has no timestamp. I use the new version 3.6.6. (Build 234).

If I change option 'Compare directory criterions' in the Norton Commander interface to 'compare by size' only, it didn't affect anyway.

In result the function didn't work in my case too :cry:

The remote server runs with an debian distribution, maybe this helps for finding the problem.

Bye Sven

Do you use SCP or SFTP? If SCP, try SFTP instead.

martin wrote:

Do you use SCP or SFTP? If SCP, try SFTP instead.

I'm also using 3.6.6 (Build 234) and I have the same problem with timestamps showing date but no time. I came across this problem when I noticed that synchronize directories wanted to reship the same files over and over. Also, it seems to happen to files whose times are within the 12:00 to 12:59 (start of day) range, and those from 2000. There may be more as well.

I tried using SFTP and SFTP with SCP fallback on my server but I get:
No such file or directory.
Error code: 2
Error message from server: No such file (*)
Request code: 11
so I can't use anything other than SCP.

Here is a link to a sample screen capture:

<invalid hyperlink removed by admin>

I'm also using 3.6.6 (Build 234) and I have the same problem with timestamps showing date but no time. I came across this problem when I noticed that synchronize directories wanted to reship the same files over and over. Also, it seems to happen to files whose times are within the 12:00 to 12:59 (start of day) range, and those from 2000. There may be more as well.

WinSCP in SCP mode does not know time when 'ls -la' does not show it. In such case, synchronisation of course does not work. That's why I recommend SFTP over SCP.

No such file or directory.
Error code: 2
Error message from server: No such file (*)
Request code: 11
so I can't use anything other than SCP.

When do you get this error?

Thanks for the response;

I updated the link to show new screens.

Guest wrote:

That's why I recommend SFTP over SCP.

That is where I get the connection problem.

No such file or directory.
Error code: 2
Error message from server: No such file (*)
Request code: 11
so I can't use anything other than SCP.

When do you get this error?

As soon as I attempt to connect.

You are correct that ls -la does not list the time of some files, however, ls -la is performing correctly; therefore ls -la is a poor choice to use. ls -la does not return the time for files modified in a year previous to the current. An alternative would be ls --full-time, which returns the time and year in all cases.

I updated the screen captures on the link to show the difference between the ls -la and the ls -full-time, plus additional information.

As soon as I attempt to connect.

Please post a log file.

You are correct that ls -la does not list the time of some files, however, ls -la is performing correctly; therefore ls -la is a poor choice to use. ls -la does not return the time for files modified in a year previous to the current. An alternative would be ls --full-time, which returns the time and year in all cases.

You are right. But I do not think that --full-time is portable switch working of all platforms and shells.

Thanks Martin;

I updated the screen captures on the link posted earlier to show more data and links: (<invalid hyperlink removed by admin>)

Please post a log file.

See below and the weblink.

You are right. But I do not think that --full-time is portable switch working of all platforms and shells.

My own research indicated that the command is implemented in systems that support the SUS standard, which comprises most of the modern implementations of Linux, at least those that are being used as serious operating systems or enterprise level hosting operating systems.

I have posted the question to LinuxQuestions.org to see which systems do not support the --full-time option. I waited a while to see if there were a lot of responses but so far none. Either that means none have been found or the forum is not read very much.

The ls-la command returns the year instead of the time for files modified as recent as 6 months prior. Surely you cannot consider the ls -la option as a serious method of getting the timestamp for performing synchronization. The objective of using the ls -la is command is to get the actual timestamp so that the times can be set correctly but for files not modified in the current year (or even recently) it is not reliable and makes the whole synchronization task pointless.

As an interim solution, please allow users the option to choose which command to use. That way, for the systems that do support the --full-time option, we can use the synchronization feature reliably.

As for the login process failing for SFTP, I am also posting a log here:

WinSCP Version 3.6.6 (Build 234) (OS 4.10.67766446 A)
Login time: Tuesday, July 27, 2004 9:55:10 PM
--------------------------------------------------------------------------
Session name: username@subdomain.onlinehome.us
Host name: subdomain.onlinehome.us (Port: 22)
User name: username (Password: Yes, Key file: No)
Transfer Protocol: SFTP (SCP)
SSH protocol version: 2; Compression: No
Agent forwarding: No; TIS/CryptoCard: No; KI: Yes; GSSAPI: No
Ciphers: aes,blowfish,3des,WARN,des; Ssh2DES: No
Ping type: -, Ping interval: 60 sec; Timeout: 15 sec
SSH Bugs: -,-,-,-,-,-,-,-,
Proxy: none
Return code variable: Autodetect; Lookup user groups: Yes
Shell: default, EOL: 0
Local directory: E:\pm200407xx\1and1, Remote directory: /homepages/29/directory/htdocs, Update: No, Cache: Yes
Cache directory changes: Yes, Permanent: Yes
Clear aliases: Yes, Unset nat.vars: Yes, Resolve symlinks: Yes
Alias LS: No, Ign LS warn: Yes, Scp1 Comp: No
--------------------------------------------------------------------------
Looking up host "subdomain.onlinehome.us"
Connecting to 217.160.226.83 port 22
Server version: SSH-1.99-OpenSSH_3.7.1p2 Debian 1:3.7.1p2-1.2
We claim version: SSH-2.0-WinSCP-release-3.6.6
Using SSH protocol version 2
Doing Diffie-Hellman group exchange
Doing Diffie-Hellman key exchange
Host key fingerprint is:
ssh-dss 1024 34:47:0f:e9:1a:c2:eb:56:eb:cc:58:59:3a:02:80:b6
Initialised AES-256 client->server encryption
Initialised AES-256 server->client encryption
Using username "username".
Session password prompt (username@subdomain.onlinehome.us's password: )
Using stored password.
Sent password
Access granted
Opened channel for session
Started a shell/command
--------------------------------------------------------------------------
Using SFTP protocol.
Doing startup conversation with host.
Type: SSH_FXP_INIT, Size: 5, Number: -1
Type: SSH_FXP_VERSION, Size: 5, Number: -1
SFTP version 3 negotiated.
Type: SSH_FXP_EXTENDED, Size: 38, Number: 200
Type: SSH_FXP_STATUS, Size: 38, Number: 200
Status/error code: 8
Server does not recognise WinSCP.
Cached directory change via "/homepages/29/directory/htdocs" to "/homepages/29/directory/htdocs".
Getting current directory name.
Listing directory "/homepages/29/directory/htdocs".
Type: SSH_FXP_OPENDIR, Size: 39, Number: 523
Type: SSH_FXP_STATUS, Size: 29, Number: 523
Status/error code: 2, Message: 523, Server: No such file, Language: *
(ECommand) Error listing directory '/homepages/29/directory/htdocs'.
No such file or directory.
Error code: 2
Error message from server: No such file (*)
Request code: 11
Startup conversation with host finished.

As an interim solution, please allow users the option to choose which command to use. That way, for the systems that do support the --full-time option, we can use the synchronization feature reliably.

I will think about it. However I consider SCP to be ugly and obsolete protocol and I hoped to spend no more time developing it :-(

As for the login process failing for SFTP, I am also posting a log here:
...

Unfortunately from the log I cannot see reason for your problem. What happens next, after the error message appears?

Unfortunately from the log I cannot see reason for your problem. What happens next, after the error message appears?

It appears that WinSCP does actually get logged in only that it can't display the contents of the directory (remote pane is blank). Any time I click on anything that would cause the remote directory listing to be displayed or changed, I get the same error (No such file or directory). I also captured a log file from version 3.6.7, which contains more information than 3.6.6. From the 3.6.8 version History notes, it does not look like version 3.6.8 (current version as of this posting) added any more data to the log so the data should be the same. Hopefully you can see what command(s) are not working as expected.

I added a page to my captured screens collection for version 3.6.7 to show what it looks like:
<invalid link removed>

As for your other comment,

I will think about it. However I consider SCP to be ugly and obsolete protocol and I hoped to spend no more time developing it :-(

Don't be so harsh on SCP; after all it is what put you on the map. The name of the program is WinSCP. Don't abandon it now when you are so close to making the synchronization feature work for WinSCP. Another 12 bytes of data but everything would be clean and straightforward. You have the potential for making significant contributions to the computer software field in the future. Abandoning SCP now would be good fodder for humor on human errors in judgment. You start WinSCP but drop support for the SCP protocol because you aren't impressed with its ugliness. I have been in this business for nearly 30 years; believe me, you haven't seen ugly. Be proud that you started something (WinSCP) that loads of people believe in, depend on, and all of us praise you for doing so. As you very well know, you get little (if any) help on your development efforts; you have traveled down a road where few others would go. Right now, you sit on a pedestal. That is partly because of what you have done, and partly because we expect that you will get the job done, and done well. Don't abandon the very protocol that made WinSCP so popular. Doing so means that you did not finish the job; you did not make it work when it came down to one of the most useful features of the program (synchronization). Look at the count of visitors that read the synchronization issues (164). The number is nearly a quarter of the number of registered users of the forum (872). They could be registered users reading or guest visitors, but obviously many have some interest in the synchronization issues.

I hope you do implement the --full-time option. You will please many, not just myself.

OK, you have almost conviced me. I can add the --full-time option. However note that it may not solve your problems. I believe that with ls command you cannot be sure if DST shift is already included in the timestamp or not. So the timestamp used for file comparison may be different from timestamp sent with file during transfer (which should should not include the shift). The result may be that all or none files will be synchronised every time. So the --full-time option may be only the first step towards victory. We'll see.

I would also like to solve your problem with SFTP. Unfortunatelly I do not understand why your server refuses to open the directory, which obviously exists. Can you try different SFTP client to see if it is problem on WinSCP-side or server-side? For example PSFTP.

Other issue: Other issue: WinSCP SFTP Retaining Options Problems
The "use same options next time" is not intended to affect the synchronisation direction switch. The suggested direction is based on current panel selected as with copying and other commands. So if you have selected local panel before starting synchronisation, the "remote" directory synchronisation will be selected and vice versa.
I may separate the direction switch from other options, so it is clear that the "use same options next time" does not affect it.

BTW: "ls" on SunOS does not support the --full-time

... I believe that with ls command you cannot be sure if DST shift is already included in the timestamp or not. So the timestamp used for file comparison may be different from timestamp sent with file during transfer (which should should not include the shift). The result may be that all or none files will be synchronised every time. So the --full-time option may be only the first step towards victory. We'll see.

That is a good point. I believe it can be solved by user's setup choices per session profile. A few simple tests will confirm how the server is responding. As an even easier alterative, WinSCP could perform the test for the user. WinSCP could create a tiny temporary file on the local system to use as a test file. WinSCP knows the timestamp of this temporary file. After transferring it to the server, WinSCP could query the server to see how the dates are returned. Since WinSCP knows the timestamp of the local file, it could pre-setup the correct choices to ensure the session would synchronize in the future. Of course, you would get rid of the temporary file on both ends after completion. This same test could help regardless of protocol, especially to set up the time offset when the server is in a different timezone.

User choices per session would allow users that can take advantage of --full-time to use it and for those that cannot, they could select the current method (most likely the default).

I would also like to solve your problem with SFTP. Unfortunatelly I do not understand why your server refuses to open the directory, which obviously exists. Can you try different SFTP client to see if it is problem on WinSCP-side or server-side? For example PSFTP.

I tried and PSFTP and also Tunnelier. Both PSFTP and Tunnelier displayed the directory properly. BTW, both are nice programs but I am more attached to WinSCP.

Other issue: WinSCP SFTP Retaining Options Problems
The "use same options next time" is not intended to affect the synchronisation direction switch. The suggested direction is based on current panel selected as with copying and other commands. So if you have selected local panel before starting synchronisation, the "remote" directory synchronisation will be selected and vice versa.
I may separate the direction switch from other options, so it is clear that the "use same options next time" does not affect it.

That explains some things. I checked to see where that is documented and could not locate anything so any direction you take cannot affect enormous numbers of users, however, I like how the option appears to be part of the "Keep same options" group. I would rather see it be included so that the user choice retains the setting for the next time regardless of pane selected when synchronization is started. I can see using the panes as deciding only for the first execution and only as a suggestion. I think in most cases users have a methodology of how they do things; be it edit locally and always ship to remote, or other method. In other words, once the choice is made, most users would stick with it and not need to change it except in unusual cases.

In your position, it is difficult to make choices because some will agree and others will not. You will find that adding more user configuration choices (with defaults for most) can cure some of these differences. I would accept that method of cure, as long as it would allow me to set it and forget it (always synchronize the remote with my local copy).

I updated my website link that is referenced earlier. It now explains this point of view in more detail.

Thank you so very much.


.

martin wrote:

BTW: "ls" on SunOS does not support the --full-time

That is good to know. Apparently no one using SunOS reads the LinuxQuestions forum, probably because they don't like to think of it as being Linux. So far no one has submitted an OS that does not support --full-time on LinuxQuestions (I was sure LQ would get me the data real fast). It doesn't surprise me that it would be something like the SunOS. I get the impression that most Linux systems use the SUS standard, which does include support for --full-time.

Incidently, couldn't WinSCP perform a test, again with a small sample file and see whether the system supports --full-time or not? Either you will get parsable text or a few lines having the word error in it. If the test required user help to diagnose the results, I am sure you will have the user support you need.

.

That is a good point. I believe it can be solved by user's setup choices per session profile. A few simple tests will confirm how the server is responding. As an even easier alterative, WinSCP could perform the test for the user.

It is not that easy, because some file were created in DST period and some out of it. Some will have the timestamp shifted and some not. The time the DST preriod starts and ends is as I believe country-specific. I do not see a solution here apart of making DST period also part of the session profile :?

User choices per session would allow users that can take advantage of --full-time to use it and for those that cannot, they could select the current method (most likely the default).

It believe that this is better subject for autodetection than the timestamp.

I tried and PSFTP and also Tunnelier. Both PSFTP and Tunnelier displayed the directory properly. BTW, both are nice programs but I am more attached to WinSCP.

Thanks for info. I'll check it.

That explains some things. I checked to see where that is documented and could not locate anything

I have added this to the documentation recently.

so any direction you take cannot affect enormous numbers of users, however, I like how the option appears to be part of the "Keep same options" group. I would rather see it be included so that the user choice retains the setting for the next time regardless of pane selected when synchronization is started. I can see using the panes as deciding only for the first execution and only as a suggestion. I think in most cases users have a methodology of how they do things; be it edit locally and always ship to remote, or other method. In other words, once the choice is made, most users would stick with it and not need to change it except in unusual cases.

It is about the interface concept. Take F5 key. Its functionality changes based on what panel is currently active.
When local panel is active, F5 means upload and Ctrl+S means synchronisation in the same direction (local->remote).
When remote panel is active, F5 means download and Ctrl+S means synchronisation in the same direction (remote->local).
The only difference is that for synchronisation you have second chance to change your mind using the switch. But the switch is there rather to allow you to select "both" synchronisation than to change direction from local to remote and vice versa.