RFC: Comparing filename case feedback

[Seeker]

Yes but that's a manual process. Plus, how are we supposed to know which foldernames don't have matching case if BC doesn't show them to us in the first place? IMO syncing foldername case is just as important as syncing filename case. Why have one without the other? I hope you're planning on implementing it.

Yay Pete! I don't understand why 'everyone' wants to ignore case differences (I'm also dealing with this with the package SyncbackSE) - except it must be 'hard to do'.

That's no excuse IMHO, Case is a big deal - it IS different. No one seems to mind options for attributes, mod dates, all sorts of stuff - but case? Why does that matter? - seems to be the overall opinion.

Oh - and to be clear - I'm talking foldername case - though filename case is just as important.

[Zoë]

The most obvious issue is that BC doesn't compare anything about a folder. We don't compare/sync the last modified time, attributes, or permissions either, so yes, layering case syncing behavior on top is "hard to do". There's certainly room for improvement, but I think we're doing well so far, and I'm not aware of anyone else doing better.

With that said, we can look into some specific changes:

During a "Mirror" update, if "Compare Filename Case" is checked we can rename target folders to match case. Changing a folder's name doesn't update its timestamp, so I'm inclined to leave the "Update" syncs alone. I could be convinced that "Update Left/Right" should give precedence to the source side. "Update Both" definitely won't change until we start keeping track of the previous sync state.

I'm more on the fence about the regular "Copy" commands. I can see making the same change there, but copying folders now only copies the files that match the display filter, so it generally won't affect everything. Anyone have a preference one way or the other?

[Michael Bulgrien]

IMHO - Automatically renaming target folders to match case during a Sync is sufficient.

Since BC has always operated on file-based comparisons, I would not want folders renamed automatically on a copy operation... However, being able to "manually" touch folder names from the context menu before or after a regular "Copy" operation would be great!

[Seeker]

During a "Mirror" update, if "Compare Filename Case" is checked we can rename target folders to match case.

I think this is appropriate, since you are 'mirroring' and if the folder case stays different with compare filename case checked, you are not fully mirroring ---- as I consider the full pathname as part of the filename (at least to me) - and in this case you are specifically comparing case in the filenames.


Changing a folder's name doesn't update its timestamp, so I'm inclined to leave the "Update" syncs alone. I could be convinced that "Update Left/Right" should give precedence to the source side.

"Update Both" definitely won't change until we start keeping track of the previous sync state.

I'm more on the fence about the regular "Copy" commands. I can see making the same change there, but copying folders now only copies the files that match the display filter, so it generally won't affect everything. Anyone have a preference one way or the other?

I think here it partially depends on if there is a "Compare Filename Case" checkbox for these options. If there is and it is checked, you would obviously check filename case in all the situations, but folder case - that should probably trigger in these situations only if all files are selected for the folder (i.e. no filter).

Oh - and if I'm not clear, I agree with Michael's comment - the most important time to rename folder to match case is during a sync (mirror) - you are explicitly trying to make the left and right to be the "same".

[Pete]

FWIW, my only request is that BC shows a folder with mismatched case as a mismatch during the *compare* phase.

I'm indifferent what BC does during copies/syncs, although I agree it would be more efficient if BC renamed target folders & files instead of copying them all over again.

[Aaron]

Thanks for the feedback. I've created a tracker entry to track this discussion. If anyone has anymore feedback on dealing with Filenames and Foldernames, please let us know.

[Seeker]

Just checking back after a little over two months, wondering if anything is planned in this area, or already done...

[Seeker]

Still interested in this topic, but no responses, I see.

[Aaron]

This is still an open entry and something we are looking into. If there are any other ideas about the subject, please post them here or email us at [email protected]

[pdegregorio]

File name case unimportance continues to be a problem

Hello, this issue has been kicking around for years and I just don't see why something can't be done with options so people who like how BC works currently regarding file name case can continue to use it that way and people, like me, who need file name case to be more than just a quick check that later gets nullified by a full content check, can have their solution. I use BC to maintain a web application and the app server, despite the host file system being rather case insensitive (OS X) considers myfile.png and MyFile.png to be different and the application fails if its looking for MyFile.png when the file that's there is myfile.png. The content of myfile.png and MyFile.png is identical so the quick test is reset. It is not a good solution for me to uncheck "override quick tests" because other quick tests, such as file time stamp do need to be overridden. Need to have an option to have file name case not be overridden while continuing to allow date/time differences to be overridden.
Peter

[Aaron]

Hello,

Thanks for the suggestion. Reorganizing these tools is still something we are looking into. In your case, are you currently using the Sync tools and need to compare timestamp and size? Or would it work to disable Timestamp, Size, and Override Quick Tests, and leave the Content compare and Filename Case enabled?

[pdegregorio]

Thanks for the reply. Leaving the content compare and filename case enable would work. However, I don't want to disable Override Quick Tests. I don't ever use the timestamp except for quicktest ... the dates of my files move around it is the content I care about and of course, the exact name, case included.

[Aaron]

Ok, but if you do not ever use the timestamp for part of the comparison or syncing, why would you need to compare it? The Comparison tab only controls the aspects of the files that are compared. The timestamp will still be displayed in the main view, it just won't be one the criteria used to determine if files should be equal or different.

If you have only the content scan (Binary) and File name case enable, and disable timestamp, size, and quick test, then your files will only be marked as equal if File name case and Binary scan are equal. They will be different if either Binary scan *or* file name case is different.

If override is enabled, then the Binary scan overrides the quick test results (file name case).