RFC: Comparing filename case feedback

[Zoë]

After discussing it internally we've come up with what we feel is a better way of handling differences in filename case. If you ever need to do this, please let us know whether this will work for you, and whether you think it's better or worse than BC2's behavior:

BC2's existing behavior:

• If "Case sensitive filenames" is checked files with differences in case are not aligned.
• You can not double-click a line to compare the file with the unaligned file to see differences.
• If you copy a file to a directory with an unaligned file with different case, that file will be overwritten, but the filename doesn't actually change, and it will show up twice in the directory listing until you do a refresh.
• Update syncs only perform copies, so like above, it won't actually change the case.
• Mirror syncs perform deletes before copies, so it will delete the unaligned file and then copy the original file, effectively changing the filename's case.

BC3 proposed behavior:

• Folders know whether they're case-sensitive or not. FTP sites can be configured in the FTP Profiles dialog. On Windows all drives and remote shares are considered case-insensitive. On Linux case-sensitivity is auto-detected based on the each folder's filesystem.
• If either folder is case-insensitive, files that differ in case are aligned. Priority would be given to files who's names match exactly, in case a case-sensitive folder is lined up with a case-insensitive one.
• We add a new "Compare filename case" option to the "Comparison" "Quick Tests" panel, so differences in filename case will trigger a difference just like differences in DOS attributes does.
• We add a new "Update filename case when copying" checkbox to the "Handling" "File handling" panel. When copying a file the destination's filename will be adjusted automatically to match the source's.
• Since the files are now aligned, double clicking on them will show a comparison.
• Changed names will show up as a difference instead of as a pair of orphans.

[Michael Bulgrien]

The proposed BC3 behavior is more inline with what I would expect case-sensitive handling to look like. However, what seems to be missing is the ablility to sync file names (case differences) without syncing content.

[Michael Bulgrien]

One possible solution would be to touch the filename: when two folders or files are aligned (whether completely different names or case-only differences) offer a new option on the touch dialog to copy the filename from the other side. However it is implemented, one should be able to touch the filename without touching the date and time on the file.

[Tim]

The proposed design does not preclude having a "copy filename" function, which it still on our wishlist.

Thanks,

[Dave_L]

The BC3 proposed behavior sounds reasonable to me.

One question:

Priority would be given to files who's names match exactly, in case a case-sensitive folder is lined up with a case-insensitive one.

Does that means that in a situation like the following, "ABC" on the left side will be aligned with "ABC" on the right side?

left side:
ABC
Abc

right side:
ABC

[Tim]

Does that means that in a situation like the following, "ABC" on the left side will be aligned with "ABC" on the right side?

Yes, that's correct.

[Michael Kujawa]

Would there still be a way to forcibly choose the folder's sensitivity setting? The FTP server may be win32, or the win32 directory may be a copy of a linux folder where it matters. (We use a linux perforce server, so folders that came from perforce are case sensitive.)

[Zoë]

As I mentioned in the original post, FTP profiles would keep their current case sensitivity setting. I don't want to make drives/shares configurable. I see now that Windows does have a function that's supposed to indicate whether a volume is case sensitive or not, so hopefully Perforce sets that correctly.

As for a Win32 copy of a Linux directory, you'll be able to tell it to compare case, but you won't be able to tell it to act as if the directory is actually case sensitive. In that case, if you have a file "ABC", and you tell it to copy a file "abc", it's going to overwrite it.

[Michael Kujawa]

I see... I didn't get the distinction between comparing case and the directory being case sensitive. There's nothing going to make an NTFS drive have abc and ABC, so I can understand wanting to leave the volume case insensitive.

We've had problems where the case is different on the win32 client than on the perforce server, and fixing those problems usually entails finding which files are affected. I was thinking of the problem from that perspective. It sounds like the proposed behavior suits my needs.

[JohnFLand]

Is there an ETA for case-sensitive compares? It's a bit of a pain to have to run BC2 at the end of many of my compare sessions just to fix case problems.

[StasD]

The proposed solution does make sense. Please implement it faster! . This is one of the features from v.2 (maybe the only one, actually) I miss badly. And I'm glad to know it's going to work even better. Thanks!

[JohnFLand]

Is there an ETA for case-sensitive compares? It's a bit of a pain to have to run BC2 at the end of many of my compare sessions just to fix case problems.

Bump; particularly since this missed the 3.0.11 release

[Pete]

NTFS isn't case sensitive but I am

Please implement this as soon as possible.

My current problem is that I often manually change the case of filenames, for example "downloaded.ZIP" to "downloaded.zip", or "pete's file.txt" to "Pete's file.txt".

If nothing else about these files changes, then they aren't synced. In the future when I do a clean install of Windows and restore the files from my backup drive, I will have lost all of my manual case changes.

[Zoë]

The filename case changes made it into 3.0.14. Let me know what you guys think.

[Zoë]

Oh, and the two options "Compare filename case" and "Update filename case when copying" are just a single "Compare filename case" option, with the assumption being that if you're comparing them you want to copy them, and if you aren't, you don't. I think it's cleaner to just have the single UI item, but if someone has a reason why they personally want them split up we're open to changing it.