Folder compare problem

[somebody]

Hi everybody!

There is a little problem in folder compare in BC3. It is not quite a problem, but this can be very easy solved. Maybe the problem has been discussed, but it is not solved in the latest BC3.

Here is the scenario:

When one compares 2 folders with a lot of files/folders in, there are some files/folders which are not the same. Let's suppose on the left we have some files which we want to copy on the right, either because they are not there, or because they are newer. While still comparing, we copy the files/folders from left to right. It is obvious that once a file was copied from left to right, it is the same in both panels. But this is not marked immediately as being the same by BC3 (after the copy is finished). It takes a while (usually BC3 needs to make a second compare to do this) and it becomes annoying when you need to make a binary compare on large files and slow connection (over a network).

I suggest that once a file is copied from one panel to the other to mark the file as identical on both sides, as soon as the copy is finished. This will improve a lot the speed of folder compare.

[Chris]

Thanks for the suggestion. You can't assume that files will always be identical after a copy.

As an example, copy a text file by FTP from Windows to Linux in ASCII mode. This will convert the line endings of the file, changing the file size after the copy. If you have your computer set to compare size, then the files will show as different.

[somebody]

Chris >> What you say is correct, but in such a case you have to ignore the difference between Unix/Windows regarding text files, because they will not be the same as binary files.

I refer to Windows only. By slow connection I mean either a network HDD (a HDD connected directly to the network) or another Windows machine, where I have many files and I perform a complex compare which takes over 1 hour. For such situations it is very helpful to suppose that once the file is copied from one place to the other, it is the same in both places, such that no further check should be done.

[Michael Bulgrien]

And what if the file happens to get corrupted during the copy? Then you want BC3 to incorrectly report that the files are identical? This may not be a likely scenario, but it is not out of the realm of possibility. As Chris said in his first post, "You can't assume that files will always be identical after a copy."

[somebody]

As Chris said in his first post, "You can't assume that files will always be identical after a copy."

Following your logic, it results the following: you can't assume that the files will be identical even after a second compare done by BC3, because after comparing one file can get corrupted, right? And from here it follows that why one uses BC3 at all, because some files might get corrupted while running BC3, right? I don't want to write the next logical step, but I guess you already know it.

I hope you know that if, during a copy operation, something goes wrong, there is an error code generated by the operating system. And I assume that BC3 captures this error and it will not report the files as being identical.

[Michael Bulgrien]

Following your logic...

Nice try... but you're just making your own argument sound stupid. Please try to refrain from bashing and personal attacks on this forum. It's not professional.

[Zoë]

Obviously not everybody supports this particular suggestion, but I have considered adding it as an option. The original poster is correct that for many copies, if it doesn't fail out, it's reasonably safe to assume that they match. Even in the case of an ASCII transfer, we could show it as a text-based match, rather than a binary one.

The only way to work around it right now is to manually do a "Compare Contents" instead of using the background content compare, or turning off the background compare before the copy

[Michael Bulgrien]

I've had windows copies and file downloads that have failed on numerous occasions. The date, time, and size attributes have already been set to that of the source file, but if you try to access the file, it is corrupted and can't be read. So long as that doesn't start happening with BC3, then I would agree that a faster declaration of equality would be nice. I've even suggested it in the past, but the Scooter team gave me the same answer as the original poster of this thread was given. It is interesting to see a softening in that answer.

If you are going to go as far as declare a text-based match (I assume you mean an equal sign without the binary digits next to it), then I would have to agree with somebody's second post in this thread that, if the copy is occuring on the same platform (where line endings is not a factor), why stop with a text-based match? And if you declare a text-based match for text files, it only makes sense that you would alos declare a binary match for binary files (which don't have line-endings at all).

[somebody]

Nice try... but you're just making your own argument sound stupid. Please try to refrain from bashing and personal attacks on this forum. It's not professional.

My answer was not a personal attack, it was just THE answer to your professional reply in the first post "And what if the file happens to get corrupted during the copy?"

Craig >> Thank you, this is the best way to do it, add as an option, such that anyone who is afraid of getting files corrupted during a copy doesn't need to use it. Thank you.

[Mike2D2]

Thanks for the suggestion. You can't assume that files will always be identical after a copy.

As an example, copy a text file by FTP from Windows to Linux in ASCII mode. This will convert the line endings of the file, changing the file size after the copy. If you have your computer set to compare size, then the files will show as different.

I'm having a problem where text files copied over SFTP from Windows to Windows (via Cygwin's ssh server) are doing the same thing. The file size is different after copying.

I agree with others on this thread that it'd be nice if BC had a fast-path where it marked a copied file as the same, but that won't solve the real problem for me when I return to the session later.. when I return to the session later (if I don't use Compare Contents), BC will show everything as different when it really is the same as far as I'm concerned.

What I really need here is an option to BC to tell it to always do a binary copy for all files. I can resolve text file line ending differences myself if they come up, but I really want BC to give me a visual confirmation that stuff I've synced with BC is the same, and I want that to last through time so I'm not faced with a choice between:

- Using Compare Contents with gigabytes of files
- Delving down into the trees manually every time I run the session to check which files really are different as BC is reporting

[Aaron]

Go to your Tools menu -> FTP Profiles, select your Profile. In the Transfer tab, you can force Binary. Does that help solve the issue for you?