Case sensitivity global option for better cross-platform support

[Travisyard]

Hello beets community,

My music library's files are synced to multiple systems with different operating systems and filesystem formats. My beets library is managed on Linux which is usually case-sensitive. Some platforms (namely Android and Windows) are usually case-insensitive, and this has caused me some headaches.

For example, one artist I have in my library has released albums as both "Diaf" and "DIAF". On most Linux systems, these two directory names can exist side-by-side. However, on Windows and Android they are generally considered the same directory. Another example of this occurred when I tried to replace a corrupted file in the same album. The original album folder was "Sound of Silver", but the replacement song imported into the folder "Sound Of Silver". This resulted in the same failure mode.

One workaround I have found is to use the %upper{}, %lower{}, or %title{} functions in the path formats, but this workaround is only bulletproof if every $template substitution is nested inside one of these functions. Also, I'd like to retain filenames that match the preferred stylization of the artists I listen to ("ABSRDST" and "LOOK MUM NO COMPUTER" should be all uppercase, "ev.exi" and "clipping." should be all lowercase).

I suggest adding a global configuration option like case_sensitivity: yes|no. The default for systems that are usually case-insensitive should be no, and the default for systems that are usually case-sensitive should be yes. Users who manage their beets library on a case-sensitive system and then copy/move/synchronize to a case-insensitive system would be able to change this option to prevent unexpected copy/move/synchronize errors.

Reference: Case Sensitivity on Wikipedia

[Serene-Arc]

Sorry, just need some clarification here. What is your preferred behaviour? What do you think that beets should do instead of what it is doing?

As far as beets as concerned, the artist is different if the case is different, unless, as you said, you put it in a template function that changes it. I'm a little confused as to what you think beets should be doing. You're saying that you want the preferred style of the artist but seems mutually incompatible with not having case sensitive names.

[RollingStar]

IDK the most performant way to do this, but you're suggesting checking if a case insensitive match exists for all parent folders, and only making new folders/subfolders where they don't. Pathlib appears to have an interface for this: https://docs.python.org/3/library/pathlib.html#pathlib.PurePath.match

There must be a cross platform project that has solved this problem, like FTP or rsync.

[Serene-Arc]

I'll have to take a look at the specific code in the modules as to whether this would be a difficult change to make. @Travisyard if you'd like to make a bug report, we can get the ball rolling on that.

I want to be clear though. Beets considers the albums 'gloria' and 'Gloria' to be different because they do not have the same name. By collapsing that, it is possible (however unlikely) that losing that information will lead to errors. Consider a band that releases two albums, one of which is a new edition that is signified by a different case e.g. 'first album' vs 'FIRST album'. Those directories would be merged and treated as the same on the file system.

[Travisyard]

@Serene-Arc I didn't file a bug report because it isn't really a bug. The unexpected behavior I have encountered occurred when I passed the files to a downstream process. With that in mind, do you still want me to file a bug report?

Also re: case disambiguation, that is a great point! With that said, perhaps a small modification to my original proposal will bring it inline with that limitation. I am not proposing any changes at all to how Beets catalogues things in its internal database. It can continue to be internally case-sensitive. The changes I am proposing only affect directory structure. Internally, "Gloria" and "gloria" can be different albums, but would then be disambiguated on the disk as something like "Artist/Gloria" and "Artist/gloria-1". Do you think this is more feasible than trying to automatically merge them as I had previously proposed?

[Serene-Arc]

Unexpected behaviour can still be a bug if we need to add it to the documentation explaining what it is. Unexpected behaviour, whether from a compiler or from the perspective of the user, is something that programs should avoid. Plus we also have feature requests. Having it under a bug report of feature request makes it far easier to track and assign work compared to a discussion.

That would be more conceptually feasible, though it might run counter to what the user expects it to do. I'm not overly familiar with that part of the code though.

I should note that this is concerning paths and I intend to overhaul the path code of beets soon ™️ . I keep saying that, but maybe this will be a reason to push forwards with that. As @RollingStar mentioned, pathlib can deal with this issue and once we switch the internal code to pathlib, it might be easier to implement this feature.

[Travisyard]

@Serene-Arc I have submitted this issue based on our discussion here. Thank you for your insight and help with this!