search

ChatTheatre / SkotOS

Open Source version of the SkotOS narrative prose library, using the DGD driver.
https://www.ChatTheatre.com
Other
24 stars 6 forks source link

Still having problems with upper/lowercase in file names #46

Closed noahgibbs closed 3 years ago

noahgibbs commented 3 years ago

Some filenames are indistinguishable without distinguishing between uppercase and lowercase (e.g. s7 vs S7 in the vault data.) Git does a weird mapping here, and I think there may have been problems before that too. Basically, some of the filename case seems borked.

This is causing problems with WOE objects in some cases because WOE tracks WOEnames directly from filenames. So Data/DB/Spawn.xml became Data/DB/spawn.xml and couldn't be found. I suspect the hunting birds (e.g. the saker-terciel) problem came from the same thing with the S7 WOE subtree in the vault.

At some point I need to clone the repo on Linux, get the list of files that Mac Git complains about, and sort out all the case in the filenames.

shentino commented 3 years ago

What I'd like to know is what's corrupting the names in the first place, this honestly sounds like a bug.

shentino commented 3 years ago

For example I know that in the repo a directory listing that maps filenames to other objects is called a tree and it, just like a blob, is identified by its hash. Filenames flopping around would cause the hash to change so I know that filenames as stored in the tree object are case sensitive.

shentino commented 3 years ago

Bottom line is that git itself should be treating filenames as case sensitive and shouldn't be messing with them this way in the first place. Though that said it would also be helpless to not accept any such issues imposed at the OS level, like if for example you were running git under Windows.

Are filenames in mac case sensitive?

shentino commented 3 years ago

Yeah honestly I think the issue here is more with OSes with case insensitive filenames

I just had a chat on freenode in #git:

[14:09:07] Does the mac version of git have a tendency to choke on case sensitivity for filenames? [14:09:32] a friend of mine using mac git is having some trouble with it [14:09:39] Shentino, if your filesystem is case insensitive, yes [14:10:05] this is not specific to the mac version, but case insensitive file systems are more common on macOS than on Linux and *BSD

If this is the case I'd advise not using mac to work on this

noahgibbs commented 3 years ago

The Mac file system is case insensitive, yes. And that seems to be what's causing the difficulty. One option would be "convert all developers off Mac," yes. Windows is also currently unsupported, so that only leaves Linux, which isn't terribly common as people's daily driver in the wild.

But there's also pretty clearly some filename corruption that has occurred in the past. To take an example that's causing trouble: https://github.com/ChatTheatre/SkotOS/blob/master/skoot/data/vault/Data/DB/spawn.xml

It's referred to quite clearly as "Data:DB:Spawn" many times in the code. WOE takes its names, including case, from the filesystem. But in that link, on GitHub, on Linux, it is very clearly spawn.xml and not Spawn.xml. So something got messed up in a way that "stop using Mac" won't fix. And it seems to be true for other files too (e.g. s7 vs S7.) We're mostly seeing the problem for WOE names, but that's because a case-insensitive filesystem actually fixes this problem in a lot of cases (on Mac if you open "S7" and there's only "s7" it works fine,) but doesn't fix it for WOE.

I don't know how it got corrupted. Looking through the Git history I am seeing it as Spawn.xml... sometimes. But I'm pretty sure we get the same error on the Linode-deployed versions of this code, and those aren't on Mac. I don't think that file hasn't been committed on a Mac at any point. You and Chris are the only ones to touch it in the Git history, him in 2018 and you in 2016.

To me this sounds like it got messed up before checkin at some point in the past. And then it's just a set of corrections to be made at this point - if we don't have the error in the Git history we can't just sort it out by fixing or reverting a single commit.

noahgibbs commented 3 years ago

Duplicate of https://github.com/ChatTheatre/SkotOS/issues/64