If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

"Compare file name case" only works on aligned pairs of files, and if the case is different it will mark it as a difference. Alignment is controlled by the filesystem of each base folder. On Linux, file name case is important so a difference in case wouldn't align. Is at least one side of your comparison file case insensitive?

Comment

For your screenshot, the behavior makes sense since one side is insensitive. For your bold example text, what base folder paths are you using? What type of device is your NAS? Are you comparing two directories on the same NAS for this Linux to Linux comparison?

Windows explorer and 2 other windows applications can properly display the architecture of the windows shares unless the two folders with different case are in the same path. In that case, windows displays the folders distinctly but seems to merge their contents.

Beyond compare cannot manage a comparaison in this situation even if the two folders with different case are in different subdirectories.

See attached pictures: In windows explorer, the outcome is excpected and predictable. In BC, it isn't.

But I am not sure if there is any possible workaround for this technically under windows. I just was expecting BC to handle the comparison differently, if ever possible.

Comment

Here's the situation that windows seems to handle better, at least when displaying folder contents:

In this example, windows displays properly "tesT.txt" and "Test.txt" files (image in background) while BC only lists "tesT.txt" file.

The right side in BC comparaison doesn't cause any interférence as it contains only a folder with different name

I expected BC to list both files on left side, just like windows does.

However, BC shouldn't allow editing of both files as if they were the same. Actually, if I edit one of the text files in windows, it will always edit the same file "tesT.txt", and that's the actual file that BC shows.

Anyway, I just want to understand how BC handles these scenarios so that I am aware of it and I can avoid messing by mistake with my linux shares...

(note: I don't control all the contents of the shares since many users are implied... so, such a scenario can happen)

Comment

Thanks for the follow-up. We'll look into this a bit, but there are Windows OS limitations in place here. File Names are generally handled poorly, and will serve up the incorrect file name case or content when attempting to interact with the file. Folders have been a little better in my testing, but I wouldn't say with confidence yet that Windows Explorer always works.

Comment

Yes, basically, at least on my Windows 7, folders and files names that differ only by case are served correctly even if they are under the same path.

However, if they are under the same path, folders and files seem to be linked to one occurrence of the file/folder name.

What I'll expect BC is to check if there is no conflict (+2 files / folders of same name, with different case, under same path). If such a conflict is excluded, BC shouldn't consider folder pairs of different case as the same. Since windows seems to manage it, maybe BC could also.

Many thanks. I would be nice if you put a feedback here once you are done investigating it.

Comment

Windows itself does not expect to handle case sensitive names in the same path, which can cause various problems in Windows itself or other applications. Windows can handle a Samba source like this in limited scenarios, but it's not a good situation to trust as reliable. Part of the problem is checking the listing only reveals one entry or can't select which entry to pick between multiple. The workaround I'd suggest is to connect via FTP or SFTP, which can be marked as case sensitive sources.