|
Brian:
I have had this problem only one time. The server ftp host was a unix system that forced all file names to lower-case. So the next sync would copy the files where the case did not match. I did the same thing as you to get around the "problem".
I don't think this is a bug, that's why this option is available.
Gary J. Piccoli
Colonial Computer Associates
 Home of MuSoft 2000-------Original Message-------
Date: 04/10/04 21:15:40
Subject: [WS_FTP Forum] Synchronization Utility requires "Perform case-insensitive comparison" to be checked.
I�ve discovered what appears to be a bug in the WS_FTP Pro Synchronize Utility version 8.03.
After running the synchronization utility to populate a server with a set of remote files, subsequent synchronization executions continue to move certain files (not all) from the local system to the remote system even though they have not been modified nor has their timestamp been modified.
Using the visual compare screen with �show files/folders that won�t be transferred� checked, I noticed that the files in question had two entries instead of one. In other words, instead of one entry with local size/time and remote size/time, there were separate entries � one with a local time/size and another with a remote time/size. So the utility thinks the files are new eg. non-existent on the remote system and moves them each time.
After noticing this, I checked the �Perform case-insensitive comparison� option on a hunch, and that fixed the problem. With this option checked, the utility only moves file that are newer than their remote counterparts.
I believe this is a bug because the filenames on the local and remote system are identical as they should be since the synchronization utility just moved them.
Has anyone else experienced this behavior? I�ve yet to discover something unique with the files that the utility insists on moving every time versus the ones with which it behaves normally.
Local system is Windows XP Pro; Remote system is Windows 2003 Server; WS_FTP Pro version 8.03.
Thanks,
Brian
| 
