Handle filename "casing", "illegal" characters consistently across OS’es

Use case or problem

Files with perfectly legal characters and different “casing” aren’t handled consistently in Obsidian.

Example

We have two files, normally created within Obsidian:

  • Test links upper- and lowercase.md, and
  • Test Links upper- and lowercase.md.

We can create and access them just fine in Obsidian, but

  • all of the links below point to Test links upper- and lowercase.md,
  • and the graph view also shows just Test links upper- and lowercase.
[[Testing/Test links upper- and lowercase]]

[[Testing/Test Links upper- and lowercase]]

[Testing/Test links upper- and lowercase](<Testing/Test links upper- and lowercase.md>)

[Testing/Test Links upper- and lowercase](<Testing/Test Links upper- and lowercase.md>)

I regard this as a bug. Differently “cased” filenames are different, at least on real Operating Systems like Linux.

I know that MacOS as well as Windows put (rather flakey) file APIs on top, so it “looks like” case-insensitivity, even on the case-sensitive file systems they support, supposedly to make their OS’s compatible with older stuff.

Proposed solution

In my opinion Obsidian should

  • either reduce their file API to a “common set” that works on all supported OS’es (i.e., case-insensitive file names, restrict common “illegal” characters)
  • or allow users the full capacity of their respective OS’es (like file name case-sensitivity and all otherwise “restricted” characters in file names).

Thinking of syncing vaults around machines with different OS’es, the former might be a better general solution, but I’d still prefer the latter, maybe with a little caution regarding the machinery being synced to.

Current workaround (optional)

Be aware of what I’m doing, generally trying to avoid filenames with “conflict potential”. (Though it’s hard on Linux if one is used to be able to do everything. For syncing with Windows, I tend to forget they don’t want :, ? and different casing.)

Related feature requests (optional)

1 Like

Agree, except that I think it should be a user controlled toggle.

I’m long used to doing the first, but most people aren’t aware of restrictions on OSs they have never used. Until they hit a problem when they do. Or use a program that imposes those limits.

1 Like

I do agree that some solution would be good to be found to the file name casing problem. But just out of curiosity, I’d like to ask, in which kind of practical situation would you end up having two notes that have the same name but different casing? :slight_smile:

Such things happen. From my experience, mainly

  • by mistake (i.e., creating the same note manually again with different casing, say “Human” and “human”)
  • by importing/automatic data processing—this can create a lot of similar notes with different casing
  • by creating a note in Linux (which allows almost anything in a filename), and having that later processed on a filesystem with different filename casing (FAT, for instamce)
  • by using “illegal” (for other OS/filesystem) characters and having these automatically removed on save (ok, not casing, but “illegal character” problem) one might end up with a dup.

Just some examples that have happened.

I still say I could live with a consistent system to be used across OSes and file systems, since normally you’d avoid such kind of duplicates.

Obsi should already be doing this for characters:

So maybe this topic is specific to casing?

Regarding the characters, we are OS specific now (and some people don’t like that either now that we switched, but that’s what most people wanted!).

Regarding casing, if you are within obsidian, the link creation tool will help reuse a filename you already have.
If you create a file with a different casing outside obsidian, What can/should we do about it? It’s your files, you can see it and merge them as you see fit.

Maybe we can add a popup warning and invite you to take action.

2 Likes

It’s always difficult when more than one OS or filesystem comes into play.

I must say, I quite like @Dor’s idea of making it a setting (probably defaulting to an OS-agnostic style). In my opinion, this should handle both situations we can get: casing and special characters.

I realize this might be some programming effort, since it would require an extra layer in between Obsidian and the filesystem routines that needed to respect the setting. But anchoring it there might also solve follow-up problems, like finding if a link or a file name is “the same”.

As you can see above, one can create different case file names now within Obsidian. If such a hypothetical switch was set to “compatible mode”, I’d expect Obsidian to see “this file already exists”. With the other setting, I’d expect these two files to be legal, and the links and graph respect that they are different files.

And yes, I see the problem should a user start out with the “everything allowed” setting, later buy Sync, use a machine with another OS/filesystem and decide to “flip” the setting. Who or what would then go and do a sanity check (i.e., find all files that are now considered “the same” because of casing, and weren’t before)?

How? you can do it if purposely ignore link suggestion and write a file with a different case.

The solution to all problems cannot be implement both and add a toggle. We have 13 toggles for Sync, 13!!!

Which is, by chance, my workflow: I create files first, jot down my notes, and link them later. So it can happen that one (accidentally) creates the same file with different casing.