The Server on which the pcbugfixer and 0 0 UpdateCheckerFiles folder is located does preserve the time.
There is however a main discrepancy regarding the size of files in that, E.G.
The text files i.e. files ending with the .txt extension are always different on the server in that they are lower in their number of bytes to that on our local HDD.
For example, the "ReadMeAdobeFlashPlayer.txt" file on our local Workstation is, Size: 1.62 KB (1,666 bytes) / Size on disk: 4.00 KB (4,096 bytes) and the same file on the server is, 1.59KB (1632bytes)
Obviously the Server is a Linux and we here are on a Microsoft OS.
After many tests and almost a stuff up with running the sync the wrong way. i.e. from server to our system, we established that the only thing that resembles a sync of any kind that is correct in some ways, is the "Compare: Size" which however still wants to re-upload all the text files (files with .txt extension)
Other folders and files with .exe and .doc extensions mostly will always be different in size so there is no issue if the file is not newer and obviously does not differ in its original existing file size. so some joy is attained here when it only uploads the .exe, .doc, and other files that have in fact changed.
Synchronizing from my KVM/VPS Server in the UK running Windows 2008 R2 and sync with the Linux Server in the USA so far is working both ways with the "date (different) or size" setting.
I tend to think that there is an issue with a 32bit OS like win XP Pro SP3 and the Linux server -V- the way Directory Opus handles the sync operation.
You'll get that difference if you're transferring files in ASCII mode (the cr/lf line endings are converted to LF for the target server). Set the transfer mode to Binary to disable this.
Like I said before, "Silly I am from time to time - Stupid I am NOT!"
Using Binary as suggested, results are as follows in the following Compare setting;
Compare: size - want to copy all the 191 .txt files in the 176 folders,
Compare: date (newer) or size - want to copy all the 191 .txt files in the 176 folders,
Compare: date (newer) - works in that it wants to upload only the newer dated files and folders ! After upload and rerunning the sync again it comes up as no files , i.e. No changes detected or required,
Compare: date (different0 or size - want to upload ALL of the 735 Files in the 233 folders,
Compare: date (different) - want to upload ALL of the 735 Files in the 233 folders,
Compare: byte comparison - TAKES TOO LONG TO PERFORM !! Might be OK for a single folder containing only a few files, however for my tasks it is no good as mentioned, "Takes too long to perform"
Changing the Binary back to ASCII and using Compare: date (newer) - Takes a long time to perform, however does work in that it wants to upload only the newer dated files and folders ! After upload and rerunning the sync again it comes up as no files , i.e. No changes detected or required,
Changing the Setting for Binary / ASCII back to Automatic, also works in that it wants to upload only the newer dated files and folders ! After upload and rerunning the sync again it comes up as no files , i.e. No changes detected or required.
So after all that I found a method that I may be able to use, i.e. the "Compare: date (newer)" setting.
This in view of the method I use to update the local folder whereas at the time of performing the updating and reloading tasks, the MSOS (MicroSoft Operating System) dates the files and folders at the time they are altered or created. The logic therefor in using "Compare: date (newer)" now becomes reasonable in the applied logic.
Considering all the facts, I am saying that there is work to be done in the Directory Opus and the Synchronization methods. The made me say that.
Obviously, if the server or the upload process are changing the sizes of text files when they are uploaded then you cannot use filesize as a criteria for synching.
Using binary mode should ensure the filesizes do not change when files are uploaded. (You have to re-upload all the files, of course. Binary mode affects how files are uploaded and downloaded. Binary mode does not affect how files are compared when synching based on date or filesize. When you sync, only the sizes AS THEY ARE NOW matter. Those sizes will be the result of whether or not binary mode was on WHEN YOU DID THE UPLOAD.)
If you tell Opus to sync based on date and size, Opus will look at the dates and sizes of the files on both sides and choose what to sync based on those. You can see the dates and sizes yourself, as Opus shows them to you. There's no magic going on.
And of course doing a sync by file contents is very slow over FTP. It has to download all the files to read their contents.
If you upload files using binary mode and then the sizes of the uploaded files on the server do not match what they are locally (you didn't say, but I assume that is what you meant), then something very wrong is happening. But that should be impossible.
End this ticket - I do not want a reply having wasted enough time on this matter
Look at the previous test results the only sync that works is the Compare: date (newer) works no matter which type is used. !!!
Now End this ticket - I do not want a reply having wasted enough time on this matter
But I haven't seen anything showing what's going wrong or where, as you're not showing us the file times and sizes on each side (after re-uploading in binary mode), so there is no real information for us to investigate or explain here.
I don't know, as I can't see the file dates/sizes.
Are the files the same dates and sizes now, on the local drive and FTP site, after you upload them?
If Opus is set to sync files with different sizes and dates, and in turn wants to sync files which have the same sizes and dates, then that does sound like a bug in the sync tool. But if the files don't actually have the same size and date then something else is happening.
made me say that.
!
