Directory Comparison Not Reporting Properly For File Size

[Current User]

I have been using Cute FTP for a long time, but wanted to try FileZilla. Cute FTP also has a directory comparison feature. When comparing files by file size, I have no problem with Cute FTP. However FileZilla marks all my files as different. This might be because of the way the file is stored in Linux compared to Windows.

For example, 788KB size file on my local Windows machine is 763KB on the Linux server. But the files have identical content. Cute FTP reports the files as the same ( as it should ), but FileZilla reports them as different, which may be technically correct, but is also useless.

So I suspect that Cute FTP is taking into account the way the files are stored in its comparison algorithm, while FileZilla is not. Cute FTP also has a checkbox for "Ignore Letter Case". Perhaps that has something to do with it.

I'm not sure how to classify this issue. Maybe a bug or patch request. Either way, no matter how it is done, it would be nice if FileZilla would compare the files in a manner that determined if the file content is different or not ( because that is the point of the exercise ).

Date comparisons are not sufficient for this. File size works well, but there may also be other ways.

I can duplicate this issue all day and send screen shots of both CUTE FTP and FileZilla doing exactly the same task, where FileZilla is all salmon red ( indicating different ) and Cute FTP is normal, indicating no differences ( as it should ). Screen shots are attached.

Also, when Cute FTP identifies different files, it pre-selects them so that you can simply drag them as a group over to the other side. That would be a really handy feature.

Apart from these issues, FileZilla seems excellent, and once these issues are resolved, I would be happy to send a donation and reccommend that others do the same, as well as post a link for it on my website.

Thanks

[Current User]

Content of files identical, but FileZilla doesn't think so.

[Current User]

Cute FTP sees files as identical ( as is correct ).

[Tim Kosse]

Unfortunately this cannot be fixed since it is technically impossible to know how the server stores ASCII files

What CuteFTP does is some crude heuristic which will likely result in false-negatives: Files that are really different but seen as identical. I have no plans to ever add such a risky heuristic.

[Patrick]

Another point of view of the same issue is that when you overwrite a file, it will systematically report a different file size even if the files are different. WS FTP does that properly too.

[Tim Kosse]

This is an inherent limitation of the the used data type (ASCII) and there's nothing you can do.

If you need exact sizes, transfer everything as binary.

[Current User]

Thanks To Those Who Have Tried ... But:

REGARDING: "... nothing you can do."

If someone else has figured it out, then so can FileZilla.

REGARDING: "crude heuristic"

Never once in 10 years of transferring files has my CUTE FTP made an incorrect transfer. So even if you can integrate something as "crude" as Cute FTPs heuristic, it would be a huge improvement.

REGARDING RISK:

There is no risk. Think of it logically. All that would happen is that a file would mistakenly be tagged as different and replaced by the same file with no harm done; and if the file was different, then FileZilla would be doing exactly what it is supposed to do. Not to mention that if this were a real concern, right now FileZilla is overwriting all kinds of files that don't need to be overwritten.

SUGGESTIONS:

A combination of file name and file size where the file size takes into account the way the files are stored in both locations, calculates the difference and applies it during comparison. There are ways to make the program aware of how to do this. I am no expert, but I can think of two ways right away. The first and most obvious is to have a manual selector. This may require the user to ask their server admin which one to use.

The other is to have the program figure it out logically. The first most obvious way is create an ASCI II transfer mode filter that either changes the relevant characters or takes them into consideration during transfers ( both directions ). This would be similar to creating a form validation script.

To go one further, there can only be so many variations. So you could use ( or create ) a library of test samples ( like they did with nmap-os-db ) that correspond to the unique patterns of each type of file system, then have FileZilla run comparison tests.