RFC: Comparing filename case feedback

[Michael Bulgrien]

Thanks for your effort with filename handling.

The part that is still missing is the ability to update or touch filenames based on the filename case from the other side of the compare without changing the content. This is something that I would find very useful.

Perhaps it would be as simple as adding a "Touch filename" context menu item to the folder compare session that automatically copies filenames from the other side and rename the files on the current side.

Optionally, the menu item could open a dialog to set the touch direction if files on both sides of the compare are selected.

[Michael Bulgrien]

One example of why I would like to touch filenames:

FILENAME.TXT exists on two systems

The content of FILENAME.TXT is updated on one system
The name of an older FILENAME.TXT is changed on another system to FileName.txt

If I have "Compare filename case" enabled, I cannot copy the content of the newer file(s) on one side of the compare withouth throwing away the camel casing on the older file(s) on the other side. Likewise, I cannot easily change the casing of the newer file(s) without discarding the newer content.

I realize that there are work-arounds... but the ability to touch filenames would make it much simpler...and it doesn't seem like it should be difficult to implement.

[JohnFLand]

Thank you, thank you, thank you!!

[Dave_L]

[3.0.14 on MEPIS 7]

I had the occasion to make use of this feature today, when comparing two folders from GNU/Linux, one on an NTFS partition and one on a FAT32 partition. It worked great.

[Pete]

The filename case changes made it into 3.0.14.

Thank you. I found a bunch of files with mismatched case.

[dwight]

content equality vs filename case

One issue I have with the implementation is that an unequal case comparison is overridden by content comparison, if "override quick test results" is set.

I want "override quick test results" set, because it's not unusual for me to get a set of files that are (mostly) identical to an existing set, except for timestamps. Running a "compare contents" is a quick way to see the 'real' changes. Now, doing that loses the information that the filename case changed.

I see that something like timestamp is not significant compared to content, and equal file sizes are overridden by unequal contents. But if i indicate that filenames are case sensitive, and they're not equal, then content equality should not override that.

[Aaron]

Hello,

What are your specific settings and workflow you are following?

If you do not have a Content Comparison set in the Session Settings, and you are manually comparing contents, you could fix the filename differences first before scanning the contents. If you do have a Conent Comparison set, you can uncheck the Override box and turn off Timestamp and Size Comparisons. This would show differences if the Content is different, or if the filename case is different.

[dwight]

If you do not have a Content Comparison set in the Session Settings, and you are manually comparing contents, you could fix the filename differences first before scanning the contents.

That is my situation. But if there's a hundred files marked different due to timestamps, it's hard to spot the one that's different due to filename case. Then i do the manual compare, and they all go away (showing unequal only).

I guess having a session with settings as you described (Content Comparison set, uncheck the Override box and turn off Timestamp and Size Comparisons) would be a workaround.

I think the issue is that saying "filename case is important" is different that saying "use filename case as a quick check". Whereas timestamp and file size are typically unimportant compared to content, if you have a case-sensitive app, then filename case is just as important as content -- maybe more so!

[Michael Bulgrien]

Instead of overriding quick tests, why not remove the timestamp compare from the quick tests and let quick tests override the content compare:

Quick tests
[√] Compare file size [√] Compare filename case
[ ] Compare timestamps (unchecked)

Requires opening files
○ CRC comparison
● Binary Comparison
○ Rules-based comparison
[√] Skip if quick tests indicate files are the same
[ ] Override quick tests (unchecked)

[dwight]

An interesting idea, but in my situation i wouldn't assume equal size files are identical if they have different timestamps. There's too much chance a real change would be missed.

[Michael Bulgrien]

Sorry, should have thought of that... Drop the file size, too. It should work.

[Seeker]

I'll keep looking for something that fits my question exactly, but I have a feeling BC3 can't do it, if, as this indicates, it is just now handling filename case.

Is there anyway to synchronize folder case? I understand that technically windows folders are case insensitive, but they DO allow you to USE case to create folder names.

Thus, I end up with a Folder on one side called

This Folder Is Case Adjusted

whereas the backup's folder name is

This folder is case adjusted

Just as with filename case - a synchronization doesn't catch this nor adjust the backup's folder name to the new case structure. And, as someone above pointed out, if I restore from backup, I lose all the folder case adjustments.

Is there any way to adjust folder case?

[Zoë]

Hi Seeker,

No, BC can't handle this case right now. Michael Bulgrien has been asking for a "Touch filenames" command that would basically copy filename case changes from one side to the other, and we are considering that as a new command.

[Seeker]

Hi Seeker,

No, BC can't handle this case right now. Michael Bulgrien has been asking for a "Touch filenames" command that would basically copy filename case changes from one side to the other, and we are considering that as a new command.

As you consider 'touch filenames' - hopefully you can also consider 'touch foldernames'?

[Pete]

Michael Bulgrien has been asking for a "Touch filenames" command that would basically copy filename case changes from one side to the other, and we are considering that as a new command.

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.