MusicBrainz Picard handling of case-insensitive file renames

picard-ci-file-handling.md

The following cases of renaming files on case insensitive file systems with changes only in casing (Test.mp3 -> test.mp3) have been tested:

Test case	Picard 2.5.2	Picard 2.5.1	Picard 2.5	Picard <= 2.4.4
Windows 10, NTFS	Ok	Ok	Ok (0)	Ok (0)
Windows 10, FAT32	Ok	No case-only rename (1)	No case-only rename (1)	No case-only rename (1)
Windows 10, exFAT	Ok	No case-only rename (1)	No case-only rename (1)	No case-only rename (1)
Windows 10, SMB share on Windows	Ok	Ok	Ok (0)	Ok (0)
Windows 10, SMB share on Linux	Ok	Ok	Ok (0)	Ok (0)
Windows 10, VirtualBox shared folder	Ok	Ok	Ok (0)	Ok (0)
Windows 7, NTFS	Ok	Ok	Ok (0)	Ok (0)
Windows 7, FAT32	Ok	Ok	Ok (0)	Ok (0)
Windows 7, SMB share on Windows	Ok	Ok	Ok (0)	Ok (0)
Windows 7, VirtualBox shared folder	Ok	Ok	Ok (0)	Ok (0)
Linux, ext4 case insensitive	Ok	No case-only rename (2)	No case-only rename (2)	Appends numbers (4)
Linux, FAT32	Ok	No case-only rename (2)	No case-only rename (2)	Appends numbers (4)
Linux, SMB share on Windows, mount.cifs	Ok	No case-only rename (2)	No case-only rename (2)	Appends numbers (4)
Linux, SMB share on Windows, GVFS	Appends numbers (3)	Appends numbers (3)	Appends numbers (3)	Appends numbers (4)
macOS, AFPS case insensitive	Ok	Ok	Ok	Appends numbers (4)
macOS, FAT32	Ok	Ok	Ok	Appends numbers (4)
macOS, SMB share on Windows	Ok	Ok	Ok	Appends numbers (4)

---

0. When using Python >= 3.8 on Windows case-only changes are not applied (does not affect official binaries, which are using Python 3.7). PICARD-1990
1. Works without numbers getting appended (paths are detected to be the same file) but renames changing only the casing are not applied. But this is also not possible with Explorer. PICARD-1992
2. Works without numbers getting appended (paths are detected to be the same file) but renames changing only the casing are not applied. This seems to be a general issue on Linux when dealing with case insensitive files. I also could not change the casing with Nautilus or on console with mv (the latter will actually fail as both paths refer to the same file). PICARD-1991
3. On Linux accessing a SMB share with GVFS differences in file name casing are considered separate files, even though they access the same file. os.stat reports different inodes for e.g. Test.mp3, TEST.mp3 and test.mp3 even if they all refer to the same file. Mounting the share using mount.cifs works. PICARD-1986
4. File names got numbers appended because they were not detected as being actually the same file. See PICARD-214.

I guess PICARD-1990 means that we will need to skip from 3.7 to 3.9 for Python versions as and when.

No, it just means we have early identified and fixed an issue with Python 3.8 and 3.9. Now we could upgrade our builds to 3.8 or 3.9 without regressing. But we stick with 3.7 for now because if PyInstaller.

Ah, ok. Appologies.

Another fun fact is that WIndows 7 actually does the right thing also on FAT32, so this regressed in a later Windows version. Windows 10 definitely cannot handle that.