Implementing case insensitivity

(Simon) #21

Ok right. New ambiguity with that schema - case conflict on two devices: Device A creates foo, device B Foo and these are totally different files (both case sensitive). Device C in insensitive and pulls both of them, and will just regard it as an update. And I wouldn’t be suprised if there were quite few more such problematic border cases. It just feels more complicated and thus more likely to create problems than some kind of inter-device solution/cluster wide setting. However it’s entirely possible that this is just bias, because I had that option in my head a lot longer and I still struggle wrapping my head around the conflict bit one.

(Jakob Borg) #22

Yeah… You don’t even need the case insensitive device in the middle. Given that they are all case insensitive by default the issue in this case will be triggered directly between two case sensitive devices as well.

Although, if the two files have different contents and and created simultaneously it will be a sync conflict so we’ll end up with foo and Foo.sync-conflict-blah. At that point the user can go “WTF?” and rename the conflict file to Foo, and the case conflict bit stuff kicks in. This should be the same with the case insensitive box in the middle, except the option to do the rename doesn’t exist at that point.

So I think it would be handled correctly-ish, even if the initial sync conflict will be surprising to a user expecting case sensitive defaults.

(Simon) #23

That means in this stage multiple files with the same name except case aren’t handled anymore on case-sensitive systems at all, right? Meaning device A scans foo and Foo, sets the case bit, sends to B which then errors on pulling - even though both are case-sensitive. That wouldn’t be nice in my opinion.

However even with defaulting to what the FS can do, my scenario should be fixed by your sync-conflict argument: The insensitive device C will wrongly consider Foo and foo to be the same file, but as they are conflicts, it will create a conflict copy. And that scenario (user having both case-sensitive and -insensitive devices connected and actively using filenames with case differences only) is unlikely enough to just accept these sync-conflicts - as you say, it probably creates a WTF moment, but data is safe.

So currently to me it seems like case-conflict bit, lower-case keys with list of folder infos in db and defaulting to the case-sensitivity of the FS seems like the least invasive change, both to the user-experience and implementation.

(Jakob Borg) #24

No, if the folder filesystem is case sensitive there is no reason to error out here. I imagine the behavior will differ based whether we detect a case insensitive filesystem or not at startup, by probing.

(Simon) #25

Then I am all good, because that’s what I meant by saying “defaulting to the case-sensitivity of the FS” (not db being case sensitive) :slight_smile:

(Avamander) #26

Just from my point of view, I will never sync something to case-insensitive systems, thus any work I have to do to make Syncthing behave sane (as all of my systems) is absolutely unnecessary and incredibly time consuming if it’s per-folder. Any case insensitivity related conflicts should be something syncthing warns about (possibly adds a file extension that the file would conflict on this system), it should never touch the case of my files when there’s nothing case-insensitive in my Syncthing mesh.


I have not contributed any intelligent thoughts, but it turned out, you all did. Thank you.

I think, by reading the initial post and its processing, my usecases are mentioned and handled well.

I especially support